Elastic Search：了解如何优化写入繁重的操作，以免影响读取

Question

我们有一个带有 Elastic Search 后端的 NodeJS 应用程序，它 90% 的时间都非常轻松地使用，偶尔会被猛烈抨击。例如，在典型情况下，它可能在一小时内收到 50-100 个读取请求，以及 1-2 个写入请求。在高峰期，它可能会收到 50,000 个读取请求和 30,000 个写入请求。

在这些高峰时期，我们遇到了这样一种情况，即有太多的写入请求需要重新索引等；甚至读取请求都在爬行；这使网站无响应。为了处理这种类型的负载，我们显然需要以某种方式优化 Elastic Search 或重新构建应用程序，而我正在尝试找出最好的方法。

我想更好地理解的是：

1) 似乎会杀死所有内容的写入操作发生了什么，有什么可用于优化或加速该操作？

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

3) 有没有办法将读/写操作分开，这样即使写操作被备份，读操作仍然可以继续工作？

例如我正在考虑使用消息队列而不是直接 Elastic Search 插入，但再次回到问题 #2，我不肯定如何优化它以使读取操作继续工作。

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

感谢您的帮助。

Answer 1

1. 查看不同的thread pools — 包括索引、搜索和批量。这些想法是批量不应该阻止查询。
2. 一定要使用批量请求——你会节省大量的网络开销。但基准测试找到optimal size for your scenario。如上所述，还可以找到一个合理的刷新间隔，但这是一个权衡，需要多长时间才能搜索您的数据。
3. 如果您有基于时间的数据，您可以尝试不同的节点类型。但是，如果您所有的写入和读取都指向相同的索引，那么您就不走运了。目前无法为同一个索引拆分为读写节点。
4. 对于队列来说，负载非常高可能是一个很好的用例，但它会增加更多的移动部件和复杂性。根据您的情况，这可能是正确的选择，或者简单地为峰值负载过度配置 Elasticsearch 集群可能更便宜。
5. 确保获得正确的索引和分片数量。这适用于每个集群，但却是一个共同的痛点。

PS：如果您发现任何调整建议，请确保它们适用于您的 Elasticsearch 版本。一些设置随着时间的推移而改变或被完全删除。并且更多最新的 Elasticsearch 版本通常应该表现更好——如果你不是最新的次要版本