关于时间序列事件的数据库建议

我有：

>目前约有400,000,000个离散事件
>将存储在DB中的大约600 GB的数据

这些事件有各种格式,但我估计个人属性的数量约为5000.大多数事件只包含大约100个属性的值.属性值被视为任意字符串,在某些情况下也被视为整数.

这些事件最终将被整合成一个单一的时间序列.虽然它们有一些内部结构,但是没有其他事件的引用,我相信这意味着我不需要一个对象DB或一些ORM系统.

我的要求：

>开源许可证 – 我可能需要调整一下.
通过扩展到多个服务器可扩展性,虽然首先只使用一个系统.
>快速查询 – 更新不是那么关键.
> C/C++,Java和Python的成熟驱动程序/绑定.最重要的是与其他人一起玩的许可证 – 我不想因为技术决定而承诺任何事情.我认为大多数DB驱动程序在这里没有问题,但应该提到.
> Linux的可用性
>这将是很好,但不是必需的,如果它也可用于Windows

我的理想数据库将允许我使用单个查询从指定的时间段检索所有事件.

到目前为止我已经发现/考虑过

> Postgresql增加的页面大小可以显示每个表中最多6000列.如果我对属性计数的估计不是关闭的,那可能会.
> MySQL似乎每个表的限制为4,000列.我可以使用多个表与一些SQL-fu,但我宁愿不.
> MongoDB是我目前所倾向的.这将允许我保留事件的内部结构,同时仍然可以查询它们.其API也似乎相当直截了当.我不知道它的性能是多么好 – 至少在一台服务器上.
> OpenTSDB及其度量收集框架听起来很有趣.我可以为每个属性使用单个时间序列(可能有助于我的某些处理),将属性值作为标签,并附加标记条目以将其与特定事件相关联.它可能有一个更陡的准备曲线,上面三个,从管理员和应用程序员的角度来看.不了解其性能.
>直接使用HBase.这可能适合我的要求比OpenTSDB更好,尽管从我以前的hadoop经验来看,管理开销可能还要高于前三个选项.

可能有其他的数据库可以做到这一点,所以请随时让我知道 – 我会感谢任何可能帮助我的建议或评论.

PS：我只有DB管理员的经验很少,所以我对任何误解都表示歉意.

解决方法

您应该首先考虑从以下转换您的数据结构：

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一起使用(您的唯一约束将是数据库的总体规模和性能)

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!