对于大于100兆的大数据项目，选择哪种数据模型。项目

Question

我正在从事一个大数据项目，从不同的在线销售商收集大量的产品信息，比如价格、标题、卖家等等(每个项目的30+数据点)。

一般来说，该项目有两个用例：

1. 在web应用程序或小部件中显示特定产品的最新数据点
2. 分析历史数据，如价格历史、产品聚类、语义分析等。

我首先决定使用MongoDB来进行横向扩展，因为为项目存储的数据被假定在数百个GBs的范围内，并且可以在许多MongoDB实例中使用MongoDB动态地对数据进行共享。

不会立即收集每个产品的30+数据点，但是在不同的时间，例如一个爬虫收集价格，几天后另一个收集产品描述。然而，一些数据点可能会重叠，因为两个爬虫收集例如产品标题。例如，结果可能是：

Document 1:
{
'_id': 1,
'time': ISODate('01.05.2016'),
'price': 15.00,
'title': 'PlayStation4',
'description': 'Some description'
}

Document 2:
{
'_id': 1,
'time': ISODate('02.05.2016'),
'price': 16.99,
'title': 'PlayStation4',
'color': 'black'
}

因此，我最初想出了以下的想法(想法1)：

• 如上所述，在一个特定的爬行过程中找到的所有数据点都在一个文档中结束。为了获得最新的产品信息，我将分别查询每个数据点，并获得不超过某个阈值的最新条目，例如一周，以确保产品信息对于“用例1”来说没有过时，并且我们拥有所有的数据点(因为单个文档可能不包括所有数据点，而是只包含一个子集)。
• 然而，由于某些数据点(如产品标题)不定期变化，只需要随时保存所有数据(以便能够进行时间序列分析和高级分析)，就会导致数据库中的大量冗余，例如，即使没有变化，每天也会保存相同的产品描述。因此，我想我可以检查DB中的最新值，并且只在更改后保存该值。然而，这导致了许多额外的DB查询(每个数据点一次)，由于上述时间阈值，无论数据点没有更改还是被店主从网站上删除，我们都会丢失信息。

因此，我在考虑一种不同的解决方案(想法2)：

• 我想将不同文档中的所有数据点分开，例如价格和标题存储在单独的文档中，并带有自己的时间戳。如果数据点没有变化，则可以更新时间戳，以表明数据点没有变化，并且仍然可以在网站上使用。但是，这将导致小数据点(例如布尔值)的巨大开销，因为每个文档都需要自己的键、时间戳等，以便能够使用索引快速查找/筛选/排序它们。

例如：

{
'_id': 1,
'timestamp': ISODate('04.05.2016'),
'type': 'price',
'value': 15.00
}

因此，我很难为这个项目找到合适的模型和/或数据库。总括而言，以下是各项要求：

• 收集数以亿计的产品(数百GB，甚至TBs)
• 通过分布式爬虫在不同的时间点检索产品信息的重叠子集。
• 信息应存储在分布式、水平可伸缩的数据库中。
• 应将数据冗余降至最低。
• 应保留有关数据点的时间序列信息。

我将非常感谢任何想法(数据模型/架构，不同的数据库，.)。这也许能帮我推进这个项目。提前谢谢！

Answer 1

字段/数据点是否已经知道并指定了？也就是说，你有固定的模式吗？如果是这样，那么您也可以考虑关系数据库。

DB2有一个所谓的时态数据库。在“system”形式中，DB透明地处理版本控制。任何插入都会自动加盖时间戳，每当您更新一行时，就会自动将前一行迁移到历史表(保留旧的时间戳)。此后，您可以在任何给定的时间点运行SQL查询，DB2将按照指定的时间(或时间范围)返回数据。它们还有一个“应用程序”表单，在该表单中，您指定了行插入该行时的有效时间段(例如，如果价格在特定时间内有效)，但最终的SQL查询仍然以相同的方式工作。好的是，无论哪种方式，所有的时间复杂度都是由数据库管理的，您可以编写相对干净的SQL查询。

您可以在他们的DeveloperWorks站点上查看更多内容。

我知道其他关系数据库(如Oracle )也具有特殊的时间序列数据功能，可以为您管理版本控制/时间戳。

至于空间的效率和规模，我不确定，因为我没有运行那么大的数据库:-)

(OTOH，如果您没有固定的模式，或者您知道您将为不同的数据输入建立多个模式，并且不能使用稀疏表对其建模，那么像mongo这样的文档DB可能是最好的选择)