mongodb - 适合数百万个事件的数据存储？

Question

我们有许多系统每天总共生成大约 500 万个事件。目前，我们将这些事件保存大约 10 天，总计大约 40-50M 个事件。目前，我们使用 RDBMS 作为持久层，并在其上添加了 Web-GUI，但我们遇到了某些性能问题。

一个事件由 20-30 个字段组成，其中包含以下内容:

• 代表事件本身的字段(例如 OrderReceived)
• 表示生成事件的系统(例如 ERP 系统)的字段
• 表示生成事件的业务上下文的字段(例如 OrderManagement)
• 代表我们认为相关/重要的其他详细信息的字段

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

目前，我们使用该解决方案来分析单个事件链，主要用于错误和异常值分析(我的订单去了哪里？)。将来我们可能还想收集有关事件和事件链的统计数据(每天有多少订单？系统 X 处理了多少订单？)。如果可能的话，解决方案还应该能够增长到至少当前大小的两倍(我们预计随着新系统的启用，事件数量会增加)。目前分析是由人类执行的，因此搜索需要具有可容忍性(搜索事件链应该需要几秒钟，而不是几分钟)。数据存储还应该允许清理过时的事件。

正如一开始提到的，我们为此使用标准 RDBMS。我们使用了一个相当规范化的结构，现在我们开始对其进行非规范化以尝试提高性能。我不禁想知道其他解决方案是否会更好。我开始研究不同的 NoSQL 数据库(在我看来，MongoDB 似乎很有前途)，但也尝试收集有关搜索引擎和类似数据库(例如 Solr 和 ElasticSearch)的信息。

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

Answer 1

我建议采用一种混合解决方案，其中包含用于实际存储的传统 SQL 服务器和基于 Lucene 的前端搜索引擎，该搜索引擎是根据某些自动或定时事件从 SQL 填充的。 Web层查询Lucene层并编写SQL。

SQL 后端让您的选择对 future 保持开放(OLAP?? 等)，并且还提供了一种标准的、可扩展的和多用户的方式来通过 dbconnection 库和 ui 工具接受来自世界的数据。简而言之，如果您的数据存储在 SQL 中，您就不会丢失...

Lucene层在提供的查询能力足够的情况下，提供了极致的查询性能。 (简而言之:字段值搜索数字，日期，字符串等，范围搜索，多字段值搜索(字段实际上是一个数组)，所有这些都带有逻辑运算符和逻辑二进制表达式，排序和分页。但是!它不能这样做分组和 sum、avg 等聚合函数)。

更新:几年过去了。 Solr 现在具有统计功能，例如 sum、avg 等...

查询性能:在 100M 记录项数据库中，使用多字段查询谓词选择几百个项的时间低于 100 毫秒。

由于内部 splitfile 的实现，填充索引需要恒定的时间(大小不会增加)。可以在几分钟内建立 500 万行索引，20 个顶部，主要取决于您的存储 Controller 。然而，Lucence 支持索引的实时更新，我们在高负载网站上广泛使用了这一功能，并取得了成功。

Lucene 支持拆分并索引为子索引和索引层次结构，因此您可以每天创建一个索引，但可以使用单个查询(使用多索引适配器)在所有索引(或特定子集)中进行搜索。我用 2000 个唯一索引文件进行了尝试，性能非常惊人。

这些架构可以在 Java 和 .NET 中轻松完成，两者都具有出色的 SQL 和 Lucene 支持