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

【问题标题】：Good data store for millions of events?数百万个事件的良好数据存储？
【发布时间】：2012-04-14 12:26:54
【问题描述】：

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

一个事件由 20-30 个字段组成：

表示事件本身的字段（例如 OrderReceived）
表示生成事件的系统（例如 ERP 系统）的字段
表示生成事件的业务环境的字段（例如 OrderManagement）
表示我们认为相关/重要的其他详细信息的字段

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

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

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

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

【问题讨论】：

MongoDB 不适合复杂的分析/报告 (IMHO)。这是 RDBMS 领域（其中一些做规模）。
@SergioTulentsev 他提到的对我来说听起来不像是复杂的分析。此外，唯一标识符 [即使它们跨越多条记录] 可以制作出色的索引（在 mongodb 和大多数系统中）并且查询速度很快。
您遇到了什么样的性能问题？事件的实际记录，或对它们的报告？你是如何索引表的？您在哪种硬件上运行 - 40M 行在今天的机器上并不算多，但这取决于事物的结构以及您正在使用它做什么。访问模式是什么？您使用的是什么 RDBMS？您是使用存储过程还是通过 Web UI 代码通过记录获取记录来遍历事件链？
@SergioTulentsev 但是 MongoDB 是网络...... ;-)
@TrevorTippins 事件的报告（目前仅搜索）很慢。 MS SQL 在相当现代的硬件上。搜索通常通过事件时间戳（索引）在业务上下文和系统上下文中添加字段（单独表的外键）。一切都使用存储过程完成。

标签： mongodb elasticsearch solr rdbms nosql

【解决方案1】：

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

SQL 后端为您的未来留有余地（OLAP?? 等），还提供了一种标准的、可扩展的和多用户的方式来通过 dbconnection 库和 ui 工具接受来自世界各地的数据。简而言之，如果您的数据存储在 SQL 中，您就不会丢失...

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

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

查询性能：在一个 100M 的记录项目数据库中，选择几百个具有多字段查询谓词的项目不到 100 毫秒。

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

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

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

【讨论】：