数百万事件的良好数据存储？

Question

我们有许多系统每天产生大约500万事件。目前我们将这些节目保存约10天，共计约40-50万次事件。目前我们使用RDBMS作为持久层，并且使用web-GUI，但我们遇到了某些性能问题。

事件由以下组成的20-30字段组成：

• 字段表示事件本身（例如OrderReceived），表示所生成的事件（例如ERP系统）的系统
• 字段
• 代表事件产生的商业环境的字段（例如OrderManagement）
• 代表我们认为相关/重要的其他细节的字段

大约5-6个字段是标识符，其中大多数是唯一的，代表事件本身，业务实体/对象，上下文等。使用这些标识符我们还可以将事件彼此链接在一起。事件链中的时差可能是几个小时，甚至偶数天甚至几天。

目前我们使用解决方案来分析各个事件链，主要是针对错误和异常值分析（我的订单去哪了？）。将来我们也可能会收集关于事件和事件链的统计信息（每天有多少订单？系统X处理了多少订单？）。如果可能的话，解决方案应该能够增长到至少是当前规模的两倍（我们预计随着新系统启用，事件数量会增加）。今天的分析是由人类进行的，所以搜索需要可以忍受（搜索事件链应该花费几秒钟而不是几分钟）。数据存储还应该允许清除陈旧事件。

正如我们在开始时提到的那样，我们正在使用标准的RDBMS。我们使用了一个相当规范的结构，现在我们开始非规范化以提高性能。我不禁想知道是否有其他解决方案可能会更好。我已经开始关注不同的NoSQL数据库（并且我个人认为MongoDB看起来很有前景），同时也尝试收集有关搜索引擎和类似搜索引擎（例如Solr和ElasticSearch）的信息。

问题是什么类型的数据存储/解决方案适合这些事件？我们是否应该进入NoSQL领域，或许是我们想要的搜索引擎，或者当我们真正需要的是找到一个真正擅长优化RDBMS的人时，我们会咆哮错误的树：？

Answer 1

我会建议一个hibrid解决方案与传统的SQL服务器的实际存储和基于Lucene的前端搜索引擎，这是从SQL基于一些自动或定时事件填充。 Web层查询Lucene层并写入SQL。

SQL后端为将来保持开放选项（OLAP ??等），还提供了一种标准的，可扩展的和多用户的方式，通过dbconnection库和ui工具接受来自世界的数据。总之，如果你的数据存储在SQL中，你不会丢失...

如果它提供的查询功能足够的话，Lucene层提供极端的查询性能。 （简而言之：字段值搜索数字，日期，字符串等，范围搜索，多字段值搜索（实际上字段实际上是一个数组），所有都有逻辑运算符和逻辑二进制表达式，排序和分页。但是，它无法做到分组和总和，平均等聚合函数）。

更新：几年过去了。 Solr现在具有统计功能，如总和，平均等...

查询性能：在100M记录项目数据库中选择几百个项目与多字段查询谓词小于100ms。

由于内部分割文件的实现，填充索引需要一个固定的时间（不增加大小）。可以在几分钟内建立500万行索引，主要取决于您的存储控制器。然而，Lucence支持实时更新索引，这是我们在高负载网站上广泛使用的一项功能。

Lucene支持拆分和索引到子索引和索引层次结构，因此您可以每天创建索引，但可以使用单个查询（使用多索引适配器）在所有索引中（或其中的特定子集）进行搜索。我用2000个独特的索引文件试了一下，性能很棒。

这些架构可以在不Java和.NET的精力来完成，既具有很大的SQL和Lucene支持