elasticsearch与MongoDB进行过滤应用
这个问题是关于在深入研究实验和实现细节之前作出架构select。 关于弹性search与MongoDB的可伸缩性和性能方面的适用性，有一些具体的目的。
假设都存储具有字段和值的数据对象，并允许查询该对象的主体。 所以大概根据选定的字段筛选出对象的子集，是适合这两者的。
我的应用程序将围绕根据标准select对象。 它将通过同时过滤多个字段来select对象，换句话说，其查询过滤标准通常包含1到5个字段之间的任何地方，在某些情况下可能更多。 而select作为filter的字段将是更大量的字段的子集。 图片中存在大约20个字段名称，每个查询是试图通过整个20个字段中的几个字段来过滤对象（可以less于或多于20个总字段名称存在，我只是用这个数字来表示比例字段到用作每个离散查询中的filter的字段）。 过滤可以通过所选字段的存在以及字段值来实现，例如过滤掉具有字段A的对象，并且字段B在x和y之间，并且字段C等于w。
我的应用程序将会不断地进行这种过滤，而在任何时候哪个字段用于过滤将没有什么或者很less。 也许在弹性search中需要定义索引，但是甚至可能没有索引，速度与MongoDB相当。
根据进入商店的数据，没有任何特别的细节..插入后对象几乎不会被改变。 也许旧的对象将需要被删除，我想假设两个数据存储支持到期删除东西在内部或由应用程序进行查询。 （不太经常，适合某个查询的对象也需要被删除）。
你怎么看？ 而且，你有没有尝试过这方面？
我对这两个数据存储库中的每一个的性能和可扩展性感兴趣。 这是一个build筑devise的问题，应该使其架构良好的商店特定的选项或查询基础的详细信息，作为一个充分思考的build议的示范。
谢谢！
首先，这里有一个重要的区别：MongoDB是一个通用数据库，Elasticsearch是一个由Lucene支持的分布式文本search引擎。 人们一直在谈论使用Elasticsearch作为通用数据库，但知道这不是它的原创devise。 我认为通用的NoSQL数据库和search引擎正在走向整合，但是就目前而言，这两个来自两个截然不同的阵营。
我们在我的公司使用MongoDB和Elasticsearch。 我们将数据存储在MongoDB中，并将Elasticsearch专门用于其全文searchfunction。 我们只把我们需要查询的mongo数据字段的一个子集发送到弹性域。 我们的用例与您的不同之处在于，我们的Mongo数据始终在变化：logging或logging字段的子集可以每天更新多次，这可以要求对该logging进行重新索引以使其具有弹性。 仅仅因为这个原因，使用弹性作为唯一的数据存储对我们来说不是一个好的select，因为我们不能更新select的字段; 我们将需要重新索引整个文档。 这不是一个有弹性的限制，这是Lucene如何工作的，弹性背后的底层search引擎。 在你的情况下，一旦存储logging不会被改变的事实使你不必做出select。 话虽如此，如果数据安全是一个问题，我会考虑使用Elasticsearch作为您数据的唯一存储机制。 它可能在某个时候到达那里，但我不确定它在那里。
在速度方面，不仅Elastic / Lucene与Mongo的查询速度相当，在您的情况下，“在任何时候使用哪个字段进行过滤”的情况下，“Elastic / Lucene”可能是幅度更快，特别是当数据集变大时。 不同之处在于底层的查询实现：
- Elastic / Lucene使用向量空间模型和信息检索的 倒排索引 ，这是比较logging相似性和查询的高效方法。 当你查询Elastic / Lucene时，它已经知道答案; 它的大部分工作就是根据最有可能的匹配你的查询条件对你的结果进行排名。 这是一个重要的观点：search引擎，而不是数据库，不能保证你的确切结果; 他们排名的结果是如何接近你的查询。 大多数情况下，结果都接近确切。
- Mongo的方法是更通用的数据存储的方法; 它将JSON文档相互比较。 您可以通过任何方式获得很好的性能，但是您需要精心devise索引以匹配您将要运行的查询。 具体而言，如果您有多个要查询的字段，则需要仔细制定复合键，以便尽可能快地减less将要查询的数据集。 例如，您的第一个键应该过滤掉大部分数据集，第二个键应该进一步过滤掉剩下的内容等等。 如果你的查询不符合定义索引中的键和顺序，你的性能会下降不less。 另一方面，Mongo是一个真正的数据库，所以如果准确性是你所需要的，它将给出的答案将被发现。
为了使旧logging失效，Elastic具有内置的TTLfunction。 Mongo刚刚介绍了它的版本2.2我认为。
由于我不知道您的其他要求，例如预期的数据大小，交易，准确性或您的filter的外观，因此很难提出具体build议。 希望在这里有足够的启动。
