弹性搜索：了解如何优化写入繁重的操作，以便读取不受影响

Question

我们有一个带有弹性搜索后端的NodeJS应用程序，90％的时间使用非常轻松，偶尔会被猛烈抨击。例如，在典型的基础上，它可能在一小时内收到50-100个读取请求，以及1-2个写入请求。在高峰时段，它可能会收到50,000个读取请求和30,000个写入请求。

在这些高峰时期，我们遇到的情况是，有很多写请求需要重新编制索引等;甚至连读取请求都在爬行;这使得网站没有反应。要处理这种类型的负载，我们显然需要以某种方式优化Elastic Search或重新构建应用程序，并且我正在试图找出最佳方法。

我想更好地理解的是：

1）在写入操作上发生了什么似乎会破坏所有内容，以及为了优化或加快速度而可以使用的内容？

2）从代码的角度来看，我可以通过使用批量操作来更快地插入更多记录，但我想知道Elastic Search是否对索引进行索引的方式实际上对系统的效率较低。如果我们摆脱散装插件，或者至少使插件的尺寸变小，我是否应该看到明显更好的性能（特别是在读取方面）？任何有助于我了解这种变化可能会对事物产生什么影响的事情都会有所帮助。

3）无论如何都要划分读/写操作，这样即使备份了写操作，读操作仍然可以继续工作吗？

e.g。我正在考虑使用消息队列而不是直接弹性搜索插入，但是再次回到问题＃2，我不肯定如何优化这个以使读取操作继续工作。

e.g。有没有办法将插入插入到与读取不同的集群中，然后合并数据？这或多或少会有效。

谢谢你的帮助。

Answer 1

1. 查看不同的thread pools - 包括索引，搜索和批量。这些的想法是批量不应该阻止查询。
2. 绝对使用批量请求 - 您将节省大量网络开销。但是找到optimal size for your scenario的基准。如上所述，也可以找到一个合理的刷新间隔，尽管这是一个权衡，直到您的数据可以搜索为止。
3. 如果您有基于时间的数据，则可以尝试不同的节点类型。但是如果你所有的写入和读取都是相同的索引，那你就不走运了。现在没有办法分割成同一索引的读写节点。
4. 具有非常尖锐的负载可能是队列的一个很好的用例，但它增加了更多移动部件和复杂性。根据您的情况，它可能是正确的选择，或者只是过度配置您的Elasticsearch集群以获得峰值负载可能更便宜。
5. 确保正确获取索引和分片的数量。这适用于每个群集，但这是一个常见的痛点。

PS：如果您发现任何调整建议，请确保它们适用于您的Elasticsearch版本。某些设置已随时间更改或已完全删除。更新的Elasticsearch版本通常应该表现更好 - 如果你没有使用最新的次要版本