我有一个8节点集群（AWS上的8 r3.xlarge使用临时的80GB SSD磁盘随实例一起提供）。一个主索引和两个主索引类型。 他们之间有父/子关系。有7500万父母和15M孩子。 （我们定期清理孩子但保留父母）
为了加速has_child查询，我在孩子的父母字段上使用了渴望的全球序数。
使用渴望的全球序数似乎会显着减慢刷新时间。刷新现在最多可能需要3秒钟。
我相信我可以通过增加机器上的IO来加速刷新。但是，我可以使用其他任何设置来加快刷新速度吗？
我使用的是elasticsearch 1.4.2。
请注意，当我使用8 m3.xlarge和1 EBS卷时，刷新速度更快。 （这没有任何意义，因为EBS卷应该比短暂的磁盘具有更慢的IO ...）
谢谢！
答案 0 :(得分：3)
没有任何指标可以指出争用的位置，这很棘手。你是真的受IO限制吗？还是计算限制？我发现后者经常发现它并不是一无所知。这可能是你比较两个四核实例类型的结论，但是当你到达r3时，其他的东西也可能会改变。
可能有所帮助的一些事情：
删除合并限制index.store.throttle.type: none。使用SSD你不需要它，我们只是为了安全而使用它，因此索引不会消耗一个盒子。您可以为每个索引设置它，但如果测试显示它有帮助并且不会减慢搜索速度，只需将它放在每个节点上的配置中，或者在创建索引时将其放在应用程序中。
如果您正在使用Linux，请确保数据卷的IO计划程序设置为noop，或至少deadline。在使用固态硬盘时CFQ应该是DTRT，但我还没有发现这是真的。此外，在EC2上，您不需要具有虚拟化层的任何存储（理论上）的调度程序。请记住，除非您发现写入的持续时间大约为60mb / s，或者您的计算受限，否则这不会产生任何影响。
由于你没有在m3上使用预先加载，它真的是苹果和橘子。只是预感，但减速可能会有点层叠，细分市场正在堆积，只有在索引流量中断时才能恢复。您可以尝试将index.refresh_interval增加到5s并查看手动刷新是否加快。使用/_cat/segments/INDEX | wc -l即可轻松监控。
您可以尝试增加ES允许Lucene使用的线程数。在四个核心上，您可能没有太多的空间（需要那些CPU图表），但您可以进行一些测试并进行检查。 index.merge.scheduler.max_thread_count: 6（硬件上默认为4）。
答案 1 :(得分：0)
也许您可以完全避免计算全局序数。以下博客列出了用于处理高基数术语聚合的几种方法，并讨论了Elasticsearch如何构建和使用全局序数：https://www.elastic.co/blog/improving-the-performance-of-high-cardinality-terms-aggregations-in-elasticsearch