我们希望创建一个从大量设备接收日志文件的软件。我们每天用日志查找大约2000万行（每条日志行2kb/行）。
我开发了很多软件，但从未使用过如此大量的输入数据。数据需要可搜索、可排序、可按源IP、目标IP、警报级别等分组。
它应该组合类似的日志条目（发生6次等）
任何关于什么类型的设计、数据库以及围绕这一点的一般思考的想法和建议都将不胜感激。
更新：
发现这个演示，似乎是一个类似的场景，对此有什么想法吗？http://skillsmatter.com/podcast/cloud-grid/mongodb-humongous-data-at-server-density
我看到了一些您可能需要考虑的事情。
1） 消息队列-当时间允许时，丢弃日志行并让系统的其他部分（工作人员）处理它
2） noSQL-reddis、mongodb、cassandra
我认为您真正的问题是查询数据，而不是存储数据。
此外，您可能还需要一个可扩展的解决方案。有些noSql数据库是分布式的，您可能需要它。
看看这个，可能会有所帮助https://github.com/facebook/scribe
对"Stackoverflow logging device data"的网络搜索产生了数十次点击。
这是其中一个。所问的问题可能与你的问题不完全相同，但你应该从回答中得到几十个有趣的想法。
我会根据用户最常选择数据子集的方式做出许多决定——按设备？按日期？通过sourceIP？您希望将索引保持在最低限度，并且只使用完成任务所需的索引。
对于索引开销较高但使用索引的值较低的低基数列，例如警报级别，我建议使用触发器在另一个表中创建行，以识别与紧急情况相对应的行（例如，警报级别>x），这样就不必对警报级别本身进行索引，但您可以快速找到所有高警报级别的行。
由于用户正在更新日志，您可以将早于"x"天的已处理/托管行从活动日志中移出，并移到存档日志中，这将提高特别查询的性能。
为了识别重复出现的问题（例如，同一设备上的同一问题，或同一ip地址上的相同问题，同一制造商生产的所有设备上的相同故障，或来自同一生产运行），您可以识别定义特定类问题的列的子集，然后（在触发器中）创建这些列中值的哈希。因此，所有同类问题都将具有相同的哈希值。你可以有多个这样的列——这取决于你对"类似问题"的定义，以及你想跟踪多少不同的问题类型，以及你需要登记的列的子集来定义每种问题。如果你对哈希值列进行索引，你的用户将能够非常快速地回答"我们经常看到这种问题吗？"他们会查看当前行，获取其哈希值，然后在数据库中搜索具有该哈希值的其他行。