我们有许多系统每天产生大约500万个事件。目前，我们将这些活动保存了大约10天，总计大约40-50万个活动。目前我们正在使用RDBMS作为持久层，并在其上打上了Web-GUI，但我们遇到了一些性能问题。
一个事件由20-30个字段组成，包括以下内容：
大约5-6个字段是标识符，其中大多数是唯一的，表示事件本身，业务实体/对象，上下文等。使用这些标识符，我们还可以将事件彼此关联在一起。事件链中的时差可能是几小时，或者在极少数情况下甚至是几天。
目前我们使用该解决方案来分析各个事件链，主要用于错误和离群值分析（我的订单在哪里？）。在未来，我们可能还想收集有关事件和事件链的统计信息（每天订单数量？系统X处理多少订单？）。如果可能，解决方案也应该能够增长到当前大小的两倍（我们预计在启用新系统时事件数量会增加）。今天的分析目前由人类执行，因此搜索需要是可以容忍的（搜索事件链应该花费几秒而不是几分钟）。数据存储区还应允许清除陈旧事件。
如开头所述，我们正在使用标准RDBMS。我们使用了一个相当规范化的结构，我们现在开始非规范化以试图提高性能。我不禁想知道其他一些解决方案是否会更好。我开始环顾不同的NoSQL数据库（我个人认为MongoDB似乎很有希望），但也试图收集有关搜索引擎和类似信息的信息（例如Solr和ElasticSearch）。
问题是什么类型的数据存储/解决方案适合这些事件？我们是否应该进入NoSQL空间，或许是我们想要的搜索引擎，或者当我们真正需要的是找到一个真正擅长优化RDBMS的人时，我们是在咆哮错误的树吗？
答案 0 :(得分：4)
我建议使用传统SQL服务器进行实际存储的hibrid解决方案和基于Lucene的前端搜索引擎，该搜索引擎基于某些自动或定时事件从SQL填充。 Web层查询Lucene层并编写SQL。
SQL后端使您的选项在未来保持开放状态（OLAP ??等），并提供标准，可扩展和多用户方式，通过dbconnection库和ui工具接受来自世界的数据。简而言之，如果您的数据存储在SQL中，您就不会丢失...
如果Lucene层提供的查询功能足够，则可提供极高的查询性能。 （简而言之：字段值搜索数字，日期，字符串等，范围搜索，多字段值搜索（字段实际上是一个数组），所有都带有逻辑运算符和逻辑二进制表达式，排序和分页。但是，它不能做分组和总和，平均等聚合功能）。
更新：几年过去了。 Solr现在具有sum，avg等统计功能......
查询性能：在100M记录项数据库中，选择带有多字段查询谓词的几百个项目的时间不到100毫秒。
由于内部的splitfile实现，填充索引需要一个恒定的时间（不会增加大小）。可以在几分钟内建立500万行索引，20个顶部，主要取决于您的存储控制器。然而，Lucence支持对索引的实时更新，这是我们在高负载网站上成功使用的一项功能。
Lucene支持拆分和索引子索引和索引层次结构，因此您可以每天创建索引，但可以使用单个查询（使用多索引适配器）搜索所有索引（或在其中的特定子集中）。我尝试了2000个独特的索引文件，性能非常棒。
这些架构可以在Java和.NET中轻松完成，两者都具有出色的SQL和Lucene支持