弹性search：了解如何优化写入操作，使读取不受影响
我们有一个带有弹性search后端的NodeJS应用程序，其中90％的时间使用非常less，偶尔绝对会砰的一声。 例如，典型情况下，它可能会在一个小时内收到50-100个读取请求，并且有1-2个写入请求。 在高峰时间，它可能会收到50,000个读取请求和30,000个写入请求。
在这些高峰时期，我们遇到了这样的情况：写入请求太多，以至于重新build立索引等。 甚至有读取请求被抓取; 这使得网站无响应。 为了处理这种types的负载，我们显然需要以某种方式优化弹性search或重新构build应用程序，并试图找出如何最好地做到这一点。
我想更好地理解的是：
1）在写操作上发生了什么似乎会杀死所有的东西，以及为了优化或加速呢？
2）我可以从代码的angular度来看，我可以使用批量操作更快地插入更多的logging，但是我想知道弹性search索引这种方式在系统上实际上效率较低。 我应该看到显着更好的性能（特别是在事物的读取方面），如果我们摆脱了批量插入，或者至less使插入的尺寸更小？ 任何能够帮助我理解这种改变如何影响事物的东西都是有帮助的。
3）是否有分割读/写操作的能力，即使写操作被备份，读操作仍然继续工作？
例如，我正在考虑使用消息队列而不是直接使用弹性search插入，但是，再次回到问题＃2，我不确定如何优化读取操作以继续工作。
例如有没有办法插入到不同的读取集群，然后合并数据？ 这会多less有效吗？
感谢您的帮助。
- 查看不同的线程池 – 包括索引，search和批量。 这些想法是批量不应该阻止查询。
- 绝对使用批量请求 – 您将节省大量的networking开销。 但基准find您的scheme的最佳大小 。 如上所述，也可以find一个合理的刷新间隔，虽然这是一个折衷需要多长时间，直到您的数据可以search。
- 如果您有基于时间的数据，则可以尝试不同的节点types。 但是，如果你所有的写和读都是相同的索引，那么你倒霉了。 目前没有办法将相同索引分解为读取和写入节点。
- 有一个非常尖刻的负载可能是一个很好的用例，但它增加了更多的移动部分和复杂性。 根据您的情况，这可能是正确的select，或者简单地将您的Elasticsearch集群过度configuration为高峰负载可能会更便宜。
- 确保正确获取索引和碎片的数量。 这适用于每个集群，但是是一个常见的痛点。
PS：如果您发现任何调整build议，请确保它们适用于您的Elasticsearch版本。 一些设置已经随着时间而改变或者完全被移除。 而更新的Elasticsearch版本通常应该会更好 – 如果你不是最新的小版本