mongodb - NoSQL(MongoDB/DynamoDB)架构

Question

我正在从网站上抓取一系列产品并将它们存储在数据库中。目前，我使用的是mysql，有两个表：

products (product_id, site, product_description, etc)
    e.g. (1234, "xyz.com", "nice product", etc)
product_history (product_id, scrape_timestamp)
    e.g. (1234, 2012-01-02 10:53:09)
         (1234, 2012-01-03 11:02:09)

这个模式意味着我可以获取过去任何时候列出的产品的快照。
我正在考虑迁移到nosql，因为（i）我经常从不同的站点获得不同的字段，并且（ii）数据量每年大约为500万到1000万个产品。我可以看到两种构造模式的方法
选项1：“嵌入列表”

product_id,  site,      product_description, scrape_timestamp
1234,        "xyz.com", "test product",      {2012-01-02 10:53:09, 2012-01-03 11:02:09}

选项2：“二级索引”

keep both tables as above with the relational schema

我认为选项1可以在MongoDB中工作，在MongoDB中允许二级索引，而选项2可以在MongoDB或DynamodB中工作。（我之所以考虑这两个，是因为我希望在云中托管一些东西，而不需要维护开销）。
我走这些路对吗？哪种效果最好？我对nosql完全不熟悉，所以任何建议都将不胜感激。

Answer 1

您说您正在尝试解决以下数据存储问题：
每年1000万左右的历史数据点
异构数据点
每年1000万左右的历史数据点
正如评论中指出的，每年1000万个数据点并不是一个大数据集。包括mysql在内的大多数数据库都能够支持这一点，只要您知道如何优化它们，所以不要仅仅为了解决这个问题而切换技术。如果您对如何优化mysql有特定的问题，那么我建议您单独提出一个问题。
对于基于MongoDB的历史数据问题的解决方案，您可能会有一个product_history数据的集合，您只需决定每个文档中要放入多少个条目。一些选项：每个产品一个；每个产品/时间戳一个；特定时间段内每个产品/时间戳一个，例如一天或一个月。更多细节：
The mongo docs建议将数据嵌入到数组中“对于某些用例”是有意义的。您的用例听起来像这样的用例，即我不会为每个产品/时间戳创建一个文档。
您也不希望每个产品都有一个文档，因为mongo不太擅长增长非常长的数组。
所以，剩下的选项是在特定时间段内每个产品/时间戳一个。跟这个走。不幸的是，您将不得不尝试一些事情，以确定如何确切地组织此文档。以下是一些尝试：
使用“period”属性指示所讨论期间的开始时间。在产品/期间上创建索引。
当您附加到此文档中的数据结构时，可以使用mongo的upsert功能简化代码。
根据新数据点进入的频率选择时段的持续时间（每小时、每天、每月等）。您可能需要根据负载测试调整此持续时间。
每个周期构造文档的最简单方法是使用一个数组保存数据。但是，mongo不擅长附加到很长的数组，因此有些人通过在文档中创建一个简单的树来提高性能。例如，如果您有一个每日文档，则可以在一天中每小时使用一个单独的数组：

{
  "0" : [ 123, 456 ],
  "1" : [ 789 ]
}

如果一台服务器上有大量的数据不适合存储，并且需要能够快速读取历史数据，那么mongodb对分片的支持可能会给您带来一些好处。基本上，您可以将数据拆分，这样就不必读取磁盘。但你的问题还不清楚阅读性能是否重要，以及你阅读的类型，所以如果你想了解更多信息，请发布一个新的问题。
异构数据点
关于RDBMS对您的问题的解决方案，以下是我见过的最常见的方法：
使数据非标准化。你说每个产品有85个属性？然后创建一个包含85列的表！你说另一种产品有20种不同的属性？然后再向表中添加20列！这个解决方案：
很简单。
性能良好，因为非规范化的所有通常好处都适用。
破坏了使用关系数据库的一些好处。例如，大多数列不能有“not null”约束。
规范化数据。创建一个表来捕获x类型的属性，创建另一个表来捕获y类型的属性，等等。如果您有一个新的产品类型，则添加一个新表。这个解决方案：
可能很复杂。例如，如何决定将某些公共属性放在哪个表中？
会表现不好。例如，如果必须联接10个表才能从数据库中获取任何有用的信息，则会出现问题。
会让数据库纯粹主义者高兴。
使用行而不是列。这个解决方案：
很复杂，很难维护。
表现很差。
破坏了使用关系数据库的一些好处。
（注意，还有其他基于rdbms的解决方案。例如，有些人喜欢 put XML documents into DB2。
你在尝试最后一种方法，所以难怪你不开心！如果您要坚持使用rdbms，那么我建议您切换到我列出的其他方法之一。
现在，回到你关于nosql的问题上来。基于文档的nosql数据库（如mongodb）是解决“异构数据点”问题的一个有吸引力的解决方案，因为它没有模式。你可以在一个文档中列出一个产品的规格，当你想添加新的属性时，你就这么做。MongoDB确实允许对属性进行索引，所以如果你想找到一个带有属性A的产品，那么你可以通过索引快速地找到。（不过，这里并没有什么魔力：对于任何数据库，索引的维护成本都很高，所以要谨慎地创建索引）。