这个问题是关于在深入研究实验和实现的细节之前做出架构 Select .这是关于elasticsearch v.s.MongoDB在可扩展性和性能方面是否适合某种特定用途.
假设两者都存储具有字段和值的数据对象，并允许查询该对象体.所以，根据临时 Select 的字段过滤出对象的子集，这两种方法都适用.
我的应用程序将围绕根据标准 Select 对象展开.
我的应用程序将持续进行这种过滤，而在任何时候，过滤所使用的字段都没有或几乎没有常数.也许在Elastic search 索引中需要定义，但甚至没有索引的速度与MangGDB的速度是相同的.
根据进入store 的数据，没有特别的细节..这些对象在被插入后几乎永远不会改变.可能需要删除旧对象，我想假设两个数据存储都支持内部或通过应用程序生成的查询删除内容.(符合特定查询的对象也需要删除的频率较低).
你怎么认为？
我对这两个数据存储的性能和可伸缩性感兴趣，这两个数据存储都适用于这类任务.这是一个类似于架构设计的问题，store 特定选项或查询基石的详细信息应该使其具有良好的架构，这是一个经过深思熟虑的建议的展示.
谢谢
首先，这里有一个重要的区别:MongoDB是一个通用数据库，Elasticsearch是一个由Lucene支持的分布式文本搜索引擎.人们一直在谈论使用Elasticsearch作为通用数据库，但知道这不是它的"原始设计".我认为，通用NoSQL数据库和搜索引擎正在走向整合，但目前来看，它们来自两个截然不同的阵营.
我们公司同时使用MongoDB和Elasticsearch.我们将数据存储在MongoDB中，并专门使用Elasticsearch进行全文搜索.我们只向elastic发送需要查询的mongo数据字段的子集.我们的用例与您的不同之处在于，我们的Mongo数据一直在变化:一条记录或记录字段的子集可以一天更新几次，这可能需要将该记录重新索引到elastic.仅出于这个原因，使用elastic作为唯一的数据存储对我们来说不是一个好 Select ，因为我们无法更新 Select 字段；我们需要对一个文档的"整体"重新编制索引.这不是弹性限制，这是Lucene的工作方式，它是弹性背后的底层搜索引擎.在您的情况下，记录一旦存储就不会被更改，这样您就不必做出这样的 Select .话虽如此，如果数据安全是一个问题，我会三思而后行，使用Elasticsearch作为数据的唯一存储机制.它可能会在某个时候到达那里，但我不确定它是否在那里.
在速度方面，不仅弹性/ Lucene与Mongo的查询速度保持一致，在你的情况下，"在哪个时刻用于过滤的字段非常少"，它可以是数量级的更快，尤其是随着数据集变得更大.不同之处在于底层的查询实现:
对于过期的旧记录，Elastic有一个内置的TTL功能.我想Mongo是从2.2版开始引入的.
由于我不知道您的其他要求，例如预期的数据大小、事务、准确性或过滤器的外观，因此很难提出任何具体建议.希望这里有足够的东西让你开始.