ElasticSearch 的扩展答案

【问题标题】：Scaling of ElasticSearchElasticSearch 的扩展
【发布时间】：2013-04-24 08:24:59
【问题描述】：

我正在搜索有关 ElasticSearch 如何随其索引中的数据量进行扩展的信息，我很惊讶我在该主题上找不到这么少的信息。也许这里人群的一些经验可以帮助我。

我们目前正在使用 CloudSearch 来索引大约 700 万份文档；在 CloudSearch 中，这会产生 2 个类型为 m2.xlarge 的实例。我们正在考虑改用 ElasticSearch 以降低成本。但我在 ElasticSearch 的扩展上发现的只是它的扩展性很好，可以分布在多个实例上等等。

但是我需要什么样的机器（内存、磁盘）来存储这种数据？

如果我将数据量增加 12 倍（约 8000 万份文档），情况会如何变化？

【问题讨论】：

我想根据您提供的信息，您只会得到典型的“视情况而定”的答案:) 但仍然...这取决于您的文档是什么样子以及您想用它们做什么.

标签： amazon-web-services elasticsearch scaling amazon-cloudsearch

【解决方案1】：

作为Javanna said，这取决于。主要是：（1）索引率； (2) 文件大小； (3) 搜索的速率和延迟要求； (4) 搜索类型。

考虑到这一点，我们能提供的最好帮助就是举例说明。在our site（新闻监控）上，我们：

每分钟索引超过 100 个文档。目前，我们拥有近 5000 万份文档。我还听说过包含数亿个文档的 ES 索引。
文档是带有一些元数据的新闻文章，不短但也不大。
我们的搜索延迟在约 50 毫秒（对于普通和稀有词）到 800 毫秒（对于常见词（停用词，我们对其进行索引））之间变化。这种变化主要是由于我们的自定义评分（由于 Lucene/ES 支持对其进行自定义）以及数据集（倒排列表）不完全适合内存（OS 缓存）的事实。因此，当它命中缓存的倒排列表时，它会更快。
我们使用很多术语进行OR 查询，这是最难的术语之一。我们还对两个单值字段进行分面。并对日期方面进行一些实验（以显示随时间变化的发布率）。

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

现在把例子放在一边。 ElasticSearch 具有很强的可扩展性。很简单，用N个shards和M个replicas创建索引，然后用ES创建X台机器。它将相应地分配所有分片和副本。您可以随时更改副本数量（针对每个索引）。

一个缺点是您无法在创建索引后更改分片数量。但是您仍然可以事先“过度分片”，以便在需要时为扩展留出空间。或者创建一个具有正确数量的分片的新索引并重新索引所有内容（我们这样做）。

最后，ElasticSearch（还有Solr）在底层使用了 Lucene Search 库，这是一个非常成熟且广为人知的库。

【讨论】：

您能分享一下您使用了多少个分片吗？过度分片是指 10、100、1000？
@gondo 我们现在有 8 个 m1.large 实例。我们已经转移到日期分区方案，我们每月有一个或两个分片。在此之前，我们每个索引有 16 个分片（涵盖约 60M 文档）。通过过度分片，我的意思是加倍。但是你必须小心，取决于设置，太多的分片是不好的。例如，对于 8 个 m1.large 实例，如果每个查询都必须访问所有 200 个分片，那么开销将不值得。

【解决方案2】：

实际上，我最近在我工作的公司从使用 CloudSearch 切换到了托管的 ElasticSearch 服务。我们的特定应用程序有超过 1 亿个文档，并且每天都在增长。到目前为止，我们对 ElasticSearch 的体验绝对是美妙的。即使进行了所有排序、过滤和分面，搜索性能平均约为 250 毫秒。索引文档也相对较快，尽管我们每隔几个小时使用批量 API 通过 HTTP 传递几 MB 的负载。刷新率似乎也几乎是即时的。

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

由于我们的索引位于专用集群上，因此我们无法访问具体的节点级配置设置，因此我在 ES 部署方面的技术专长仍然非常有限。话虽如此，我无法确定我们在指数上所经历的性能究竟需要多少性能周。但是，我知道 Qbox 的集群使用 SSD……所以这肯定会产生重大影响。

以防万一，ElasticSearch 已无缝扩展。我强烈推荐切换（即使只是为了节省 $$，CloudSearch 也非常昂贵）。希望这些信息对您有所帮助！

【讨论】：

等一下，您“选择”使用 qbox.io？您的个人资料名称表明您是 qbox.io 的首席架构师。 COI 免责声明将有助于此答案。
内森，好点子。去年早些时候，我刚开始通过 Qbox 使用 Elasticsearch 时发布了这篇文章。我正在与另一家失败的本地公司合作，所以我加入了 Qbox，因为我有一些在那里工作的好朋友。自从加入以来，我们已经放弃并增加了几名工程师，而我最终成为了首席开发人员。因此，我的上述观点只是巩固了（我没有羞耻:)）。

【解决方案3】：

CloudSearch 最近降价了，现在可能比在 EC2 上维护自己的搜索基础设施更便宜 - http://aws.amazon.com/blogs/aws/cloudsearch-price-reduction-plus-features/

【讨论】：