在 Elasticsearch 中，读取优先于写入答案

【问题标题】：Give reads priority over writes in Elasticsearch在 Elasticsearch 中，读取优先于写入
【发布时间】：2014-02-19 20:46:36
【问题描述】：

我有一个运行 Elasticsearch 0.9 的 EC2 服务器和一个用于读/写访问的 nginx 服务器。我的索引有大约 750k 中小型文档。我对内容有相当连续的最少写入（主要是更新）流。我通过搜索获得的速度/一致性对我来说很好，但我在multi-get (/_mget) 上遇到了一些零星的超时问题。

在我的应用程序的某些页面上，我们的服务器将请求多次获取十几个到几千个文档（这通常需要不到 1-2 秒）。失败的请求会在 nginx 服务器超时 30,000 毫秒后失败。我假设发生这种情况是因为索引被临时锁定以用于写入/优化目的。有人对我可以在这里做什么有任何想法吗？

一个临时解决方案是降低超时并返回一条用户友好的消息，说明无法检索文档（但是他们仍然需要等待大约 10 秒才能看到错误消息）。

我的其他一些想法是让读取优先于写入。任何时候有人试图读取索引的一部分，都不允许对该部分进行任何写入/锁定。我不认为这将是可扩展的，甚至是不可能的？

最后，我想我可以有一个只读别名和一个只写别名。我可以通过文档弄清楚如何设置它，但我不确定它是否真的会像我期望的那样工作（而且我不确定如何在本地环境中可靠地测试它）。如果我这样设置别名，只读别名是否仍然存在由于通过只写别名写入信息而导致索引被锁定的时刻？

我确定其他人以前也遇到过这种情况，确保用户始终可以从索引中读取数据的典型解决方案是，其优先级高于写入。如果需要，我会考虑增加我们的服务器功率。目前我们有 2 个 m2x-large EC2 实例。一个是主副本，一个是主副本，每个都有 4 个分片。

来自失败请求的 cURL 信息转储示例（错误为 Operation timed out after 30000 milliseconds with 0 bytes received）：

{
   "url":"127.0.0.1:9200\/_mget",
   "content_type":null,
   "http_code":100,
   "header_size":25,
   "request_size":221,
   "filetime":-1,
   "ssl_verify_result":0,
   "redirect_count":0,
   "total_time":30.391506,
   "namelookup_time":7.5e-5,
   "connect_time":0.0593,
   "pretransfer_time":0.059303,
   "size_upload":167002,
   "size_download":0,
   "speed_download":0,
   "speed_upload":5495,
   "download_content_length":-1,
   "upload_content_length":167002,
   "starttransfer_time":0.119166,
   "redirect_time":0,
   "certinfo":[

   ],
   "primary_ip":"127.0.0.1",
   "redirect_url":""
}

【问题讨论】：

标签： search locking elasticsearch

【解决方案1】：

在使用 Paramedic 插件进行更多监控后，我注意到当我的 CPU 达到约 80-98% 时会出现超时（索引/搜索流量没有明显的峰值）。我终于在 Elasticsearch 论坛上偶然发现了 helpful thread。当索引正在刷新并且发生大型合并时，似乎会发生这种情况。

Merges can be throttled 在集群或索引级别，我已将它们从 indicies.store.throttle.max_bytes_per_sec 从默认的 20mb 更新为 5mb。这可以在运行时使用cluster update settings API 完成。

PUT /_cluster/settings HTTP/1.1
Host: 127.0.0.1:9200

{
    "persistent" : {
        "indices.store.throttle.max_bytes_per_sec" : "5mb"
    }
}

到目前为止，Parmedic 显示 CPU 使用率有所下降。从平均约 5-25% 降至平均约 1-5%。希望这可以帮助我避免我之前锁定查询的 90% 以上的峰值，如果我没有更多问题，我将通过选择此答案进行报告。

附带说明，我想我本可以选择更平衡的 EC2 实例（而不是内存优化）。我想我对当前的选择很满意，但我下次购买时也会考虑更多 CPU。

【讨论】：