首先，有一个重要的区别：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版开始就引入了它。

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