9

我正在搜索有关ElasticSearch如何随其索引中的数据量进行扩展的信息,并且惊讶于我在该主题上找不到多少。也许这里的人群经验可以帮助我。ElasticSearch的缩放

我们目前使用CloudSearch来索引≈约700万份文档;在CloudSearch中,这会生成2个类型为m2.xlarge的实例。我们正在考虑切换到ElasticSearch来降低成本。但我发现在ElasticSearch的缩放比例上它的扩展性很好,可以分布在多个实例中等。

但是我需要什么样的机器(存储器,光盘)来处理这种数据?

如果我将数据量增加了12倍(≈8000万份文档),这会发生怎样的变化?

+0

我想与你提供你只会得到典型的信息“这取决于”的答案:)但仍然...这取决于你的文件是什么样子以及你想要怎样处理它们。 – javanna 2013-04-30 19:06:52

回答

7

我实际上最近已从使用CloudSearch切换到我工作的公司中托管的ElasticSearch服务。我们的具体应用程序有超过1亿个文件,并且每天都在增长。到目前为止,我们使用ElasticSearch的经验绝对美妙。搜索性能的平均值为〜250ms,即使进行了所有排序,筛选和刻面。索引文件也相对较快,尽管我们每隔几个小时就会通过HTTP与批量API传递几MB的MB负载。刷新率似乎也接近即时。

对于我们的~100M doc/12GB索引,我们使用4个分片/ 2个副本(如果性能下降,则会冲击3个副本)分布在4个节点上。在设置索引之前,我们的团队花了几天时间研究ElasticSearch集群部署/维护,并选择使用http://qbox.io以节省资金和时间。我们非常害怕选择在像Qbox这样的专用集群上托管我们的索引的性能和规模问题,但到目前为止,这种体验非常棒。

由于我们的索引存在于专用集群中,因此我们无法访问节点级别的配置设置,所以我在ES部署方面的技术专长仍然非常有限。话虽如此,但我无法确定我们在索引上所体验的性能究竟需要多少性能提升。不过,我知道Qbox的集群使用SSD ......所以这肯定会产生重大影响。

点的情况下,ElasticSearch无缝缩放。我高度推荐这款交换机(即使它只是为了节省$$,CloudSearch也非常昂贵)。希望这些信息有帮助!

+5

挂上秒,你“选择”使用qbox.io?你的个人资料名称说你是qbox.io的首席架构师。 COI免责声明将对此答案有所帮助。 – NathanAldenSr 2014-09-16 18:53:50

+2

弥敦道,好点。去年早些时候,当我刚刚开始通过Qbox使用Elasticsearch时,我发布了这个消息。我当时正在和另一家当地的公司合作,因为我有一些在那里工作的亲密朋友,所以我在Qbox上跳槽。 自加入以来,我们已经下降并增加了几名工程师,而且我已经成为主要开发人员。因此,我的上述意见只是巩固(我没有羞耻:))。 – 2014-09-18 17:05:51

9

由于Javanna said,这取决于。主要是:(1)索引率; (2)文件的大小; (3)搜索的速率和延迟要求;和(4)搜索类型。

考虑到这一点,我们可以帮助的最好的例子就是它。 对our site(新闻监测)我们:

  1. 指数超过100文件每分钟。我们目前有近5000万份文件。我也听说过有数百万文件的ES索引。
  2. 文档是带有一些元数据的新闻文章,并不短但不是很大。
  3. 我们的搜索延迟时间在〜50ms之间(对于正常和罕见的情况而言)在常见术语(停用词,我们将它们编入索引)中高达800ms。这种变化很大程度上是由于我们的自定义评分(感谢Lucene/ES支持定制它)以及数据集(反转列表)不完全适合内存(OS缓存)。所以当它碰到一个缓存的倒列表时,速度会更快。
  4. 我们做的OR查询有很多条款是最难的。此外,我们还在两个单值域中进行切分。并用数据面(通过时间显示出版率)进行一些实验。

我们用4个EC2的m1.large个实例来完成这一切。现在我们正在计划移动到ES, just released, 0.9 version以获得Lucene 4.0的所有好处和性能改进。

现在抛开一些例子。 ElasticSearch具有很好的可扩展性。使用N个碎片和M个副本创建索引非常简单,然后使用ES创建X个机器。它将相应地分发所有的碎片和副本。您可以随时更改复制副本的数量(针对每个索引)。

一个缺点是,您不能在索引创建后更改分片的数量。但您仍然可以预先“过硬”,以便在需要时留出空间进行缩放。或者用正确数量的分片创建一个新的索引并重新索引一切(我们这样做)。

最后,ElasticSearch(还有Solr)在引擎盖下使用了非常成熟且众所周知的Lucene Search库。

+0

你能分享你使用了多少片碎片吗?通过oversharding你的意思是10,100,1000? – gondo 2013-10-07 00:42:19

+1

@gondo我们现在有8个m1.large实例。我们已经转移到日期分区方案,每月有一到两个分片。在此之前,我们每个索引有16个碎片(覆盖了大约60M个文档)。通过oversharding我的意思是像加倍。但你必须小心,根据设置,太多的碎片不好。例如,如果每个查询必须转到所有200个碎片,那么使用8个m1.large实例,开销将不值得。 – 2013-10-07 20:54:28