mongodb - Elasticsearch vs.用于过滤应用程序的 MongoDB

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

6年前关闭。



Improve this question




这个问题是关于在深入研究实验和实现的细节之前做出架构选择。这是关于 Elasticsearch 与 Elasticsearch 在可扩展性和性能方面的适用性。 MongoDB，出于某种特定目的。

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

我的应用程序将围绕根据标准选择对象。
它会通过同时过滤多个字段来选择对象，换句话说，它的查询过滤标准通常包含 1 到 5 个字段，在某些情况下可能更多。而选择作为过滤器的字段将是大量字段的子集。想象一下现有的大约 20 个字段名称，每个查询都是尝试通过这 20 个字段中的几个字段过滤对象(存在的总字段名称可以少于或多于 20 个，我只是用这个数字来说明字段到在每个离散查询中用作过滤器的字段)。过滤可以通过所选字段的存在以及字段值，例如过滤掉具有场A，场B在x和y之间，场C等于w的对象。

我的应用程序将不断进行这种过滤，而在任何时候用于过滤的字段方面都没有或几乎没有恒定不变。也许在elasticsearch中需要定义索引，但也许即使没有索引，速度也与MongoDB不相上下。

根据进入 store 的数据，没有关于它的特殊细节......对象在插入后几乎不会改变。也许需要删除旧对象，我想假设两个数据存储都支持在内部或通过应用程序查询的过期删除内容。 (不太常见的是，也需要删除适合某个查询的对象)。

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

对于此类任务，我对两个数据存储中的每一个的性能和可扩展性感兴趣。这是一种架构设计问题，欢迎提供应使其架构良好的特定商店选项或查询基石的详细信息，以展示经过深思熟虑的建议。

谢谢!

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 版中引入了它。

由于我不知道您的其他要求，例如预期的数据大小、事务、准确性或您的过滤器的外观，因此很难提出任何具体建议。希望这里有足够的内容可以帮助您入门。