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中工作，而选项2可以在MongoDB或DynamoDB中工作。(我正在考虑这两个，因为我想要一些托管在云中的东西，为我提供零维护开销)。

我使用这些方法是正确的吗？哪一种效果最好？我对nosql完全不熟悉，因此任何建议都将不胜感激。

Answer 1

您说您正在尝试解决以下数据存储问题：

每个year

• heterogeneous数据点

1. 1,000万个历史数据点

每年1000万左右的历史数据点

正如评论中指出的那样，每年1000万个数据点并不是一个大数据集。包括MySQL在内的大多数数据库都能够支持这一点，只要您知道如何调优它们，所以不要仅仅为了解决这个问题而切换技术。如果您有关于如何调优MySQL的具体问题，那么我建议您单独发布一个问题。

关于历史数据问题的基于MongoDB的解决方案，您可能有一个用于product_history数据的集合，您只需决定在每个文档中放入多少个条目。一些选项:每个产品一个；每个产品/时间戳一个；特定时间段内每个产品/时间戳一个。一天或一个月。更多细节：

• The mongo docs建议，将数据嵌入到数组中“对于某些用例”是有意义的。您的用例听起来像是这样的用例，即我不会为每个product/timestamp.
• You创建一个文档，也不希望每个产品有一个文档，因为mongo不太擅长增长非常长的数组。
• 所以，剩下的选项是在特定时间段内每个产品/时间戳一个文档。就用这个吧。不幸的是，您必须尝试一些方法才能准确地确定该文档的结构。下面是一些值得尝试的事情：
  • 使用" period“属性来指示相关周期的开始时间。在product/period.
  • When上创建一个索引，您可以通过使用mongo的upsert functionality.
  • Pick来简化代码(每小时、每天、每月等)。基于新数据点的出现频率。您可能需要根据负载测试调优此持续时间。
  • 按周期组织文档的最简单方法是使用一个数组来保存数据。然而，mongo不擅长附加到非常长的数组中，所以有些人通过在文档中创建一个简单的树来提高性能。例如，如果您有一个每日文档，则可以在day:

中使用每小时一个单独的数组

​

{ "0“：123,456，"1”：789 }

如果您有大量数据无法放入一台服务器的内存中，并且您需要能够真正快速地读取历史数据，那么您可能会从MongoDB对分片的支持中获得一些好处。基本上，你可以拆分你的数据，这样一次读操作就不必命中磁盘。但从你的问题中还不清楚阅读性能是否重要，以及你做什么类型的阅读，所以如果你想了解更多信息，请发一个新的问题。

异构数据点

关于你的问题的RDBMS解决方案，下面是我见过的最常见的方法：

• 对数据进行反规范化。你说每个产品有85个属性？然后创建一个包含85列的表！你说另一个产品有20种不同的属性？然后再向表中添加20列！这个解决方案:由于反规范化的所有常见好处以及使用关系数据库的一些好处，simple.
• Performs apply.
• Undermines
  • 是很好的。例如，大多数列都不能有"not null“constraint.

​

• 对数据进行标准化。创建一个表来捕获类型X的属性，创建另一个表来捕获类型Y的属性，依此类推。如果您有一个新的产品类型，则添加一个新表。这个解决方案：
  • 可能很复杂。例如，如何决定将某些公共属性放入哪个表中？
  • 的性能可能会很差。例如，如果您必须联接10个表以便从数据库中获取任何有用的信息，那么您就有了一个problem.
  • Will make database purists happy.

​

• 使用行而不是列。这个解决方案:对于使用关系database.

的一些好处，

• 很复杂，而且很难实现。

​

(请注意，还有其他基于RDBMS的解决方案。例如，有些人喜欢使用put XML documents into DB2。)

你在尝试最后一种方法，所以难怪你不开心！如果您打算坚持使用RDBMS，那么我建议您切换到我列出的其他方法之一。

现在，回到你关于NoSQL的问题上。对于“异构数据点”问题，基于文档的NoSQL数据库(如MongoDB )是一个有吸引力的解决方案，因为它是无模式的。您可以在一个文档中列出产品的规格，当您想要添加新属性时，您只需这样做即可。MongoDB确实允许您对属性进行索引，因此，如果您希望查找具有属性A的产品，则可以通过索引快速完成此操作。(不过这里没有什么神奇之处:与任何数据库一样，索引的维护成本可能很高，因此要谨慎地创建索引)。