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

Question

我们有许多系统每天会产生大约500万个事件。目前，我们将这些内容保存了大约10天，总计40-50M个事件。当前，我们将RDBMS用作持久化层，并在上面粘贴了Web GUI。但是，我们遇到了某些性能问题。

一个事件由20-30个字段组成，这些字段由以下内容组成:

代表事件本身的

字段(例如OrderReceived)

代表生成事件的系统的

字段(例如ERP系统)

字段，代表在其中生成事件的业务环境(例如OrderManagement)

字段，表示我们认为相关/重要的

其他详细信息

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

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

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

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

Answer 1

我会建议一个混合解决方案，其中包括用于实际存储的常规SQL Server和基于Lucene的前端搜索引擎，该引擎是根据某些自动事件或定时事件从SQL中填充的。 Web层查询Lucene层并编写SQL。

SQL后端使您的选择在将来可以继续使用(OLAP ??等)，并且还提供了一种标准，可扩展和多用户的方式，可以通过dbconnection库和ui工具从世界接受数据。简而言之，如果您的数据存储在SQL中，则不会丢失...

如果Lucene层提供了足够的查询功能，则它可以提供出色的查询性能。 (简而言之:对数字，日期，字符串等进行字段值搜索，范围搜索，对多个字段值进行搜索(字段实际上是一个数组)，所有这些都具有逻辑运算符和逻辑二进制表达式，进行排序和分页。但是，它不能做分组和求和，平均等汇总函数)。

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

查询性能:在一个100M记录项目数据库中，选择数百个具有多字段查询谓词的项目在100ms以下。

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

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

这些架构可以在Java和.NET中轻松完成，它们都具有强大的SQL和Lucene支持。