elasticsearch v.s. MongoDB用于过滤应用程序

Question

这个问题是在深入研究实验和实施细节之前做出架构选择。它是关于弹性搜索的可伸缩性和性能方面的适用性。 MongoDB，用于某种特定目的。

假设两者都存储具有字段和值的数据对象，并允许查询该对象体。因此，可能根据ad-hoc选择的字段过滤掉对象的子集，这两者都适合。

我的应用程序将围绕根据标准选择对象。 它将通过多个单个字段同时过滤来选择对象，换句话说，其查询过滤标准通常包括1到5个字段之间的任何地方，在某些情况下可能更多。选择作为过滤器的字段将是更大量字段的子集。图片中存在大约20个字段名称，每个查询都是尝试按照整个20个字段中的少数字段过滤对象（现有的字段名称可能少于或多于20个，我只是用这个数字来表示比例字段到在每个离散查询中用作过滤器的字段）。过滤可以是所选字段的存在，也可以是字段值，例如，过滤掉具有字段A的对象，并且它们的字段B在x和y之间，并且它们的字段C等于w。

我的应用程序将继续进行这种过滤，而在任何时刻哪些字段用于过滤都没有或几乎没有。也许在弹性搜索中需要定义索引，但即使没有索引，速度也与MongoDB的速度相当。

根据进入商店的数据，没有关于它的特殊细节......插入后几乎不会更改对象。可能需要删除旧对象，我想假设两个数据存储都支持在内部删除内容或通过应用程序查询。 （不太经常，需要删除适合某个查询的对象。）

你怎么看？ 而且，你有没有尝试过这个方面？

对于这类任务，我对两个数据存储中的每个数据存储的性能和可伸缩性感兴趣。这是一种架构设计问题，特定于商店的选项或查询基石的详细信息应该能够很好地构建它，这是对完全经过深思熟虑的建议的展示。

谢谢！

Answer 1

首先，这里有一个重要的区别：MongoDB是一个通用数据库，Elasticsearch是一个由Lucene支持的分布式文本搜索引擎。人们一直在谈论使用Elasticsearch作为通用数据库，但知道它不是它的原始设计。我认为通用NoSQL数据库和搜索引擎正在进行整合，但就目前而言，两者来自两个非常不同的阵营。

我们在公司使用MongoDB和Elasticsearch。我们将数据存储在MongoDB中，并将Elasticsearch专门用于其全文搜索功能。我们只发送我们需要查询弹性的mongo数据字段的子集。我们的用例与您的用例不同之处在于我们的Mongo数据一直在变化：记录或记录字段的子集可以每天更新几次，这可以要求将该记录重新索引为弹性。仅仅因为这个原因，使用弹性作为唯一的数据存储对我们来说不是一个好选择，因为我们无法更新选择字段;我们需要完整地对文档进行重新索引。这不是一个弹性限制，这就是Lucene的工作方式，它是弹性背后的底层搜索引擎。在您的情况下，记录在存储后不会更改的事实使您无需做出选择。话虽如此，如果担心数据安全问题，我会考虑使用Elasticsearch作为数据的唯一存储机制。它可能会在某个时刻到达，但我不确定它是否存在。

就速度而言，Elastic / Lucene不仅与Mongo的查询速度相当，在你的情况下，“在任何时刻使用哪个字段进行过滤都非常不变”，它可以更快的数量级，特别是当数据集变大时。不同之处在于底层查询实现：

• Elastic / Lucene对Vector Space Model使用inverted indexes和Information Retrieval，这是将记录相似度与查询进行比较的高效方法。当你查询Elastic / Lucene时，它已经知道了答案;它的大部分工作在于根据您的查询字词排列最有可能的结果。这是一个重点：搜索引擎，而不是数据库，不能保证您的确切结果;他们根据查询的接近程度对结果进行排名。大多数情况下都会发生这样的结果，结果非常接近。
• Mongo的方法是更通用的数据存储;它将JSON文档相互比较。您可以通过各种方式获得出色的性能，但是您需要仔细制作索引以匹配您将运行的查询。具体来说，如果您有多个要查询的字段，则需要仔细制作compound keys，以便它们尽可能快地减少要查询的数据集。例如。您的第一个键应该过滤掉大部分数据集，第二个键应该进一步过滤掉剩下的内容，依此类推。如果您的查询与定义索引中的键和这些键的顺序不匹配，那么您的性能将会下降很多。另一方面，Mongo是一个真正的数据库，所以如果准确性就是你所需要的，那么它所给出的答案就会被发现。

对于过期的旧记录，Elastic具有内置的TTL功能。我认为Mongo刚从版本2.2开始介绍它。

由于我不了解您的其他要求，例如预期的数据大小，交易，准确性或过滤器的外观，因此很难提出任何具体建议。希望这里有足够的东西让你开始。