elasticsearch vs MongoDB用于过滤应用程序

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

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

我的应用程序将围绕根据条件选择对象。它会通过同时过滤多个字段来选择对象，换句话说，它的查询过滤条件通常包括1到5个字段之间的任意位置，在某些情况下可能更多。而被选作过滤器的字段将是大量字段的子集。想象一下现有的20个字段名称，每个查询都试图通过全部20个字段中的几个字段来过滤对象（可以小于或大于20个现有字段名称，我只是用这个数字来说明字段到在每个离散查询中用作过滤器的字段）。可以通过选择字段的存在以及字段值来进行过滤，例如过滤出具有字段A且其字段B在x和y之间的对象，

我的应用程序将继续进行这种过滤，而在任何时候都将哪个字段用于过滤没有任何或非常小的常数。也许在Elasticsearch中需要定义索引，但是即使没有索引也要与MongoDB的速度相提并论。

根据进入存储区的数据，没有关于此的特殊详细信息。对象在插入后几乎不会改变。也许需要删除旧的对象，我想假设这两个数据存储支持都在内部删除过期或由应用程序进行查询删除。（通常，也需要删除适合某个查询的对象）。

你怎么看？而且，您是否尝试过这方面？

对于这种任务，我对两个数据存储库中每个存储库的性能和可伸缩性都很感兴趣。这是一种架构设计问题，欢迎商店特定的选项或应使其架构合理的查询基石的详细信息，以作为经过深思熟虑的建议的演示。

谢谢！

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

我们在公司中同时使用MongoDB和Elasticsearch。我们将数据存储在MongoDB中，并且将Elasticsearch专门用于其全文搜索功能。我们仅发送需要查询以增强弹性的mongo数据字段的子集。我们的用例与您的用例不同，因为我们的Mongo数据一直在变化：一条记录​​或一条记录的字段的子集每天可以更新几次，这可能需要将该记录重新索引为弹性数据。仅出于这个原因，将弹性作为唯一的数据存储对我们来说不是一个好选择，因为我们无法更新选择字段。我们将需要对整个文档重新编制索引。这不是弹性限制，而是Lucene的工作方式，这是Elastic背后的基础搜索引擎。就您而言，记录将不会 一旦存储就无需更改，您不必选择该选项。话虽如此，如果您担心数据安全性，那么我将考虑将Elasticsearch用作数据的唯一存储机制。它可能在某个时候到达那里，但我不确定它是否在那里。

在速度方面，Elastic / Lucene不仅可以与Mongo的查询速度相提并论，在您的情况下，“在任何时候都使用哪个字段进行过滤方面几乎没有常数”，它的数量级可能是数量级更快，尤其是随着数据集变大。区别在于基础查询实现：

• Elastic / Lucene使用向量空间模型和反向索引进行信息检索，这是将记录相似性与查询进行比较的高效方法。当您查询Elastic / Lucene时，它已经知道答案了。它的大部分工作都在于按照最有可能的结果对您进行排名，以匹配您的查询字词。这一点很重要：与数据库相比，搜索引擎无法保证您获得准确的结果；他们根据与查询的接近程度对结果进行排名。碰巧的是，在大多数情况下，结果都接近准确。
• Mongo的方法是更通用的数据存储。它将JSON文档相互比较。您可以通过各种方式获得出色的性能，但是您需要精心设计索引以匹配将要运行的查询。具体来说，如果您有多个要查询的字段，则需要精心设计复合键以便他们减少将要尽快查询的数据集。例如，您的第一个键应过滤掉大部分数据集，第二个键应进一步过滤掉剩下的数据，依此类推。如果您的查询与键以及键在定义索引中的顺序不匹配，您的性能将下降很多。另一方面，Mongo是一个真正的数据库，因此，如果您需要准确性，那么它将给出答案。

为了使旧记录过期，Elastic具有内置的TTL功能。我认为Mongo从2.2版开始就引入了它。

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