NoSQL、ElasticSearch 甚至是老式的关系数据库？答案

【问题标题】：NoSQL, ElasticSearch or even old school relational database?NoSQL、ElasticSearch 甚至是老式的关系数据库？
【发布时间】：2015-04-28 12:57:52
【问题描述】：

我们有一个将事件记录存储在 DB2 数据库中的应用程序。我们有用户根据事件的时间查询这些事件，并且可选的一些 id 作为搜索条件。

目前这个概念有效，但查询速度不是很快。在未来，传入事件将增加。因此，我们目前正在考虑我们的解决方案，如果关系数据库是我们用例的正确解决方案，或者 NoSQL 解决方案能否更好地满足我们的要求。

在对不同的 NoSQL 解决方案（基于列、键值、...）进行了一些研究之后，我们不知道其中一个是否适合。我们也看到了 ElasticSearch 作为替代方案，但不知道 ElasticSearch 使用哪种存储。

那么，您有什么想法可以做什么，或者我们的研究应该朝哪个方向发展，以适应这个用例。

问候，马纳那

【问题讨论】：

【解决方案1】：

根据您的说法，不清楚您是否尝试调整现有数据库。如果不这样做，调整现有解决方案通常比将所有数据移动到新平台（仍然需要调整）更有效（时间和精力）。只有在明确用尽所有调整选项后，您才应考虑迁移。

【讨论】：

【解决方案2】：

我只能给你我的经验。几个月前，我们遇到了类似的问题。我们使用的是 mssql 数据库，并正在考虑更改为 nosql 解决方案。

我研究了很多数据库，最终决定使用弹性搜索，因为它具有惊人的搜索速度和强大的搜索能力。

设置非常简单。甚至建立一个集群也是轻而易举的事。它在后台使用 lucene 进行搜索。

自从我们进行转换以来，我们没有遇到任何重大问题。

【讨论】：

【解决方案3】：

“查询不是很快”似乎含糊不清。优化现有解决方案可能是最便宜和最快的选择，即使这意味着对现有数据库进行一些更改。调查慢查询的原因。表是每天、每周或其他时间间隔进行范围分区的，如果不是，那为什么不呢？该表是否使用行压缩？最常见的谓词是否有合适的索引？它们是否被使用？

【讨论】：