问elasticsearch v.s. MongoDB用于过滤应用

EN

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

在我的公司里，我们同时使用了MongoDB和Elasticsearch。我们将数据存储在MongoDB中，并专门使用Elasticsearch来实现其全文搜索功能。我们只将需要查询的mongo数据字段的子集发送到elastic。我们的用例与您的用例的不同之处在于，我们的Mongo数据一直在变化:一条记录或记录的字段子集可以一天更新几次，这可以要求将该记录重新索引到elastic。仅仅因为这个原因，使用elastic作为唯一的数据存储对我们来说不是一个好的选择，因为我们不能更新选择的字段；我们需要重新索引整个文档。这不是一个弹性限制，这是Lucene的工作方式，elastic背后的底层搜索引擎。在您的情况下，记录一旦存储就不会被更改的事实使您不必做出这种选择。话虽如此，如果数据安全是一个问题，我会三思而后行使用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版本开始引入的。

因为我不知道你的其他要求，比如预期的数据大小，事务，准确性或你的过滤器看起来是什么样子，所以很难给出任何具体的建议。希望这里有足够的东西让你入门。