我们有一个应用程序，用于存储DB2数据库中的事件记录。我们有用户根据事件的时间查询这些事件，并选择一些ID作为搜索条件。
目前这个概念有效，但查询速度不是很快。将来，传入的事件将会增加。 因此，如果关系数据库是我们用例的正确解决方案，或者NoSQL解决方案能够更好地满足我们的要求，我们目前正在考虑我们的解决方案。
在对不同的NoSQL解决方案（基于列，键值，......）进行一些研究之后，我们不知道其中一个是否合适。我们还看到ElasticSearch作为替代方案，但不知道ElasticSearch使用哪个存储。
那么，您有什么想法，或者我们的研究应该朝哪个方向发展，以适应这个用例。
此致 mananana
答案 0 :(得分：3)
根据您的说法，您是否尝试调整现有数据库尚不清楚。如果不这样做，那么调整现有解决方案通常会更加高效（时间和精力），而不是将所有数据移动到新平台（这仍然需要调整）。只有在明确耗尽所有调整选项之后，才应考虑迁移。
答案 1 :(得分：0)
我只能给你我的经验。几个月前，我们遇到了类似的问题。我们使用的是mssql db，并且正在考虑更改为nosql解决方案。
我调查了很多dbs并最终决定使用弹性搜索，因为它具有惊人的搜索速度和功率。
设置非常简单。即使设置群集也是轻而易举的事。它在后台使用lucene进行搜索。
自从我们进行转换以来，我们没有遇到任何重大问题。
答案 2 :(得分：0)
“查询不是很快”似乎含糊不清。优化现有解决方案可能是最便宜和最快的选择，即使这意味着对现有数据库进行了一些更改。调查查询速度慢的原因。表格范围是每天，或每周或其他间隔，如果不是，那么为什么不呢？表是否使用行压缩？是否有适用于最常见谓词的索引并且是否正在使用它们？