thk*_*ala 11 database time-series
对于我的一个项目,我必须将一个大型事件集合输入到数据库中以供以后处理,我正在尝试确定哪个DBMS最适合我的目的.
我有:
目前大约有400,000,000个离散事件
大约600 GB的数据将存储在DB中
这些事件有多种格式,但我估计个别属性的数量约为5,000.大多数事件仅包含每个约100个属性的值.属性值将被视为任意字符串,在某些情况下,还将被视为整数.
这些事件最终将合并为一个时间序列.虽然它们确实有一些内部结构,但是没有引用其他事件,我相信这意味着我不需要对象DB或某些ORM系统.
我的要求:
开源许可证 - 我可能需要稍微调整一下.
通过扩展到多个服务器可扩展性,尽管最初只使用一个系统.
快速查询 - 更新并不重要.
用于C/C++,Java和Python的成熟驱动程序/绑定.优先考虑与他人合作的许可证 - 由于技术决定,我宁愿不做任何事情.我认为大多数DB驱动程序在这里没有问题,但无论如何都应该提到它.
Linux的可用性.
如果它也适用于Windows,那将是很好的,但不是必需的
我理想的数据库允许我使用单个查询从指定的时间段检索所有事件.
到目前为止我发现/考虑的内容:
具有增加的页面大小的Postgresql显然在每个表中具有多达6,000列.如果我对属性计数的估计没有关闭,它可能会这样做.
MySQL似乎每个表限制为4,000列.我可以使用带有一点SQL-fu的多个表,但我宁愿不这样做.
MongoDB是我目前倾向于的.它允许我保留事件的内部结构,同时仍然能够查询它们.它的API似乎也很简单.我不知道它在性能方面表现如何 - 至少在一台服务器上.
OpenTSDB及其度量收集框架听起来很有趣.我可以为每个属性使用单个时间序列(这可能有助于我的一些处理),将属性值作为标记,并另外标记条目以将它们与特定事件相关联.从管理员和应用程序员的角度来看,它可能具有上述三个更陡峭的准备曲线.不知道它的表现.
直接使用HBase.这可能比OpenTSDB更符合我的要求,尽管 - 从我过去使用hadoop的经验来看 - 管理开销可能仍然高于前三个选项.
可能有其他数据库可以做到这一点,所以请随时让我知道 - 我将不胜感激任何可能对此有所帮助的建议或评论.
PS:我作为数据库管理员的经验很少,所以我为任何误解道歉.
使用包含数千列的表格是疯狂的.特别是当你说的大多数都是零时.
您应首先考虑从中转换数据结构:
table_1
-------
event_id
attribute_1
attribute_2
[...]
attribute_5000
进入这样的事情:
table_1 event_values attributes
-------- ------------ ----------
event_id event_id attribute_id
attribute_id attribute_type
attribute_value
它可以与任何RDMS一起使用(那么你的唯一约束就是数据库总大小和性能)