使用>为大数据项目选择哪种数据模型100 mio。项

时间:2016-05-04 13:31:43

标签: mongodb database-design bigdata nosql

我正在开展一个大数据项目,从不同的在线卖家那里收集大量的产品信息,例如价格,头衔,卖家等(每件商品超过30个数据点)。

一般来说,该项目有2个用例:

  1. 在网络应用或小部件中显示特定产品的最新数据点
  2. 分析历史数据,例如价格历史,产品聚类,语义分析等
  3. 我首先决定使用MongoDB能够水平扩展,因为假定项目存储的数据在数百GB的范围内,并且可以使用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"并且我们拥有所有数据点(因为单个文档可能不包括所有数据点但只包含子集)。
    • 但是,由于某些数据点(例如产品标题)不会定期更改,因此只需始终保存所有数据(以便能够进行时间序列分析和高级分析)将导致数据库中的大量冗余,例如:即使它没有改变,每天也会保存相同的产品描述。因此我想我可能会检查数据库中的最新值,只有在更改后才保存该值。但是,这导致了许多额外的数据库查询(每个数据点一个),并且由于上面提到的时间阈值,我们将丢失信息,无论数据点是否未发生变化或是否已被网站所有者从网站中删除商店。

    因此,我正在考虑另一种解决方案(理念2):

    • 我想拆分不同文档中的所有数据点,例如价格和标题存储在具有自己时间戳的单独文档中。如果数据点未更改,则可以更新时间戳以指示数据点未更改且仍可在网站上使用。但是,这会导致小数据点的巨大开销,例如布尔值,因为每个文档都需要自己的密钥,时间戳等,以便能够使用索引快速查找/过滤/排序它们。

    例如:

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

    因此,我正在努力寻找用于此项目的正确模型和/或数据库。总结一下,这些是要求:

    • 收集数以亿计的产品(数百GB甚至TB)
    • 分布式抓取工具在不同时间点检索重叠的产品信息子集
    • 信息应存储在分布式,水平可扩展的数据库中
    • 应将数据冗余降至最低
    • 应保留有关数据点的时间序列信息

    我会非常感谢任何可以帮助我推进项目的想法(数据模型/架构,不同的数据库......)。非常感谢提前!

1 个答案:

答案 0 :(得分:1)

字段/数据点是否已知并已指定?即,你有一个固定的架构吗?如果是这样,那么你也可以考虑关系数据库。

DB2有一个他们称之为时态数据库的东西。在“系统”表单中,DB透明地处理版本控制。任何插入都会自动加上时间戳,每当您更新行时,上一行会自动迁移到历史记录表(保留其旧时间戳)。此后,您可以在任何给定的时间点运行SQL查询,DB2将返回指定时间(或时间范围)的数据。它们还有一个“应用程序”表单,您可以在其中指定行插入行时有效的时间段(例如,如果价格在特定时间段内有效),但最终的SQL查询仍然有效办法。有什么好处,无论哪种方式,所有时间复杂性都由数据库管理,您可以编写相对干净的SQL查询。

您可以在DeveloperWorks site上查看更多内容。

我知道像Oracle这样的其他关系数据库也有时间序列数据的特殊功能,可以为你管理版本控制/时间戳。

就空间效率和规模而言,我不确定因为我没有运行任何大的数据库: - )

(OTOH,如果你没有固定的架构,或者你知道你有不同的数据输入的多个模式,你不能用稀疏表建模,那么像mongo这样的文档数据库可能是你的最好的选择)