DB设计用于大量数据(2000万行/天)

时间:2011-07-01 09:38:39

标签: database performance database-design

我们希望创建一个从大量设备接收日志文件的软件。我们每天查看大约2000万行日志(每个日志行每个2kb)。

我开发了很多软件但从未使用过大量的输入数据。数据需要通过源IP,目标IP,警报级别等进行搜索,排序,分组。

它应该结合相似的日志条目(发生6次等)。

关于这种设计,数据库和一般思考的任何想法和建议将非常感激。

更新
发现这个演示文稿,似乎是一个类似的场景,对此有何看法? http://skillsmatter.com/podcast/cloud-grid/mongodb-humongous-data-at-server-density

4 个答案:

答案 0 :(得分:0)

检查一下,它可能会有所帮助 https://github.com/facebook/scribe

答案 1 :(得分:0)

我看到了一些你可能想要考虑的事情。

1)消息队列 - 在时间允许的情况下删除日志行并让系统的其他部分(工作人员)处理

2)noSQL - reddis,mongodb,cassandra

我认为你真正的问题在于查询数据,而不是存储。

此外,您可能需要可扩展的解决方案。 您可能需要分发一些noSql数据库。

答案 2 :(得分:0)

我会根据用户最常用的方式做出很多决定选择数据子集 - 按设备划分?按日期?通过sourceIP?您希望将索引保持在最低限度,并且只使用完成工作所需的那些索引。

对于索引开销很高的低基数列,使用索引的值很低,例如警报级别,我建议使用触发器在另一个表中创建行以识别与紧急情况相对应的行(例如警报级别> x),以便警报级别本身不必编入索引,但您可以快速找到所有高警戒级别的行。

由于用户正在更新日志,因此您可以将处于活动日志之前的“x”天的处理/托管行移动到存档日志中,这样可以提高即席查询的性能。

为了识别重复出现的问题(同一设备上的同一问题,或同一IP地址上的同一问题,同一制造商生产的所有设备上的问题,或同一制造运行中的相同问题),您可以识别列的子集定义问题的特定,然后创建(在触发器中)这些列中值的哈希值。因此,所有相同类型的问题将具有相同的散列值。您可以拥有多个这样的列 - 它取决于您对“类似问题”的定义以及您想要跟踪的不同问题种类,以及您需要登记以定义每种问题的列子集。如果您对哈希值列进行索引,那么您的用户将能够非常快速地回答“我们经常看到这种问题吗?”的问题。他们查看当前行,获取其哈希值,然后在数据库中搜索具有该哈希值的其他行。

答案 3 :(得分:0)

对“Stackoverflow日志设备数据”的网络搜索产生了数十次点击。

Here就是其中之一。提出的问题可能与您的问题不完全相同,但您应该从答复中获得数十个想法。