这个问题是关于在深入研究实验和实现的细节之前做出架构选择。它是关于elasticsearch v.s. MongoDB在可伸缩性和性能方面的适用性,以达到某种特定的目的。
假设两者都存储具有字段和值的数据对象,并允许查询对象体。因此,根据特别选择的字段过滤出对象的子集可能是适合这两种情况的东西。
我的应用程序将围绕着根据条件选择对象。它会通过同时过滤多个字段来选择对象,换句话说,它的查询过滤标准通常包括1到5个字段,在某些情况下可能更多。而被选作过滤器的字段将是大得多的字段的子集。假设存在大约20个字段名称,每个查询都试图通过所有20个字段中的几个字段来过滤对象(可能少于或多于20个字段名称,我只是使用这个数字来演示在每个离散查询中用作筛选器的字段与字段的比率)。过滤可以通过所选场的存在以及通过场值来进行,例如过滤出具有场A的对象,并且它们的场B在x和y之间,并且它们的场C等于w。
我的应用程序将不断地进行这种过滤,而在任何时刻都不会有或很少有用于过滤的字段的常量。也许在elasticsearch中需要定义索引,但也许即使没有索引,速度也与MongoDB相当。
根据进入商店的数据,没有关于这方面的特殊细节。这些对象在被插入后几乎不会改变。也许需要删除旧对象,我想假设两个数据存储都支持过期删除内部内容或通过应用程序进行查询。(不太常见的是,适合某个查询的对象也需要删除)。
你认为如何?还有,你有没有在这方面做过实验?
对于这类任务,我感兴趣的是它的性能和可伸缩性,两个数据存储中的每一个。这是一种架构设计问题,欢迎将特定于商店的选项或查询基石的细节作为经过充分考虑的建议的演示。
谢谢!
发布于 2012-10-05 02:22:50
首先,这里有一个重要的区别: MongoDB是一个通用数据库,Elasticsearch是一个由Lucene支持的分布式文本搜索引擎。人们一直在谈论使用Elasticsearch作为通用数据库,但知道这不是它的原始设计。我认为通用的NoSQL数据库和搜索引擎正在走向整合,但就目前而言,这两者来自两个截然不同的阵营。
在我的公司里,我们同时使用了MongoDB和Elasticsearch。我们将数据存储在MongoDB中,并专门使用Elasticsearch来实现其全文搜索功能。我们只将需要查询的mongo数据字段的子集发送到elastic。我们的用例与您的用例的不同之处在于,我们的Mongo数据一直在变化:一条记录或记录的字段子集可以一天更新几次,这可以要求将该记录重新索引到elastic。仅仅因为这个原因,使用elastic作为唯一的数据存储对我们来说不是一个好的选择,因为我们不能更新选择的字段;我们需要重新索引整个文档。这不是一个弹性限制,这是Lucene的工作方式,elastic背后的底层搜索引擎。在您的情况下,记录一旦存储就不会被更改的事实使您不必做出这种选择。话虽如此,如果数据安全是一个问题,我会三思而后行使用Elasticsearch作为您的数据的唯一存储机制。它可能会在某个时候到达那里,但我还不确定它是否会在那里。
在速度方面,Elastic/Lucene不仅与Mongo的查询速度相当,在您的情况下,“在任何时刻用于过滤的字段几乎不是恒定的”,它可能会快几个数量级,特别是当数据集变得更大时。不同之处在于底层查询实现:
对于过期的旧记录,Elastic有一个内置的TTL功能。我想Mongo是从2.2版本开始引入的。
因为我不知道你的其他要求,比如预期的数据大小,事务,准确性或你的过滤器看起来是什么样子,所以很难给出任何具体的建议。希望这里有足够的东西让你入门。
https://stackoverflow.com/questions/12723239
复制相似问题