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

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

在速度方面，Elastic/Lucene 不仅与 Mongo
的查询速度相当，在您的情况下，“在任何时候用于过滤的字段几乎没有固定不变”，它可能是幅度更快，尤其是当数据集变得更大时。区别在于底层查询实现：

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

对于过期的旧记录，Elastic 具有内置的 TTL 功能。我认为 Mongo 刚刚在 2.2 版中引入了它。

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