《Elastic Stack 实战手册》——四、应用实践——4.3 性能优化场景——4.3.2.Elasticsearch 开发人员最佳实践指南(3): https://developer.aliyun.com/article/1225221spm=a2c6h.13148508.setting.16.438f4f0e18NXNE
在启用副本之前强制段合并及增加带宽
一个非常常见的 Elasticsearch 用例是：定期（每两小时一次）创建一个索引。
关于如何实现最佳性能，SoundCloud 上有一篇非常不错的 文章。从该文中引用，我特别发现
以下几项“必须”。
·在完成索引创建后，务必启用副本。
·在启用副本之前，请确保：
1）通过强制合并来缩小索引大小；
POST /twitter/_forcemerge
推荐阅读：https://developers.soundcloud.com/blog/how-to-reindex-1-billion-documents-i
n-1-hour-at-soundcloud
记录应用程序级别指标
Kibana 对 Elasticsearch 性能提供了多维监控指标仪表盘：
·indexing
·search latency and throughput
·flush
·merge operations
·GC pauses
·heap size
·OS (CPU usage, disk I/O
· kernel caches 等......
但，这还不够。如果由多个应用程序使用，Elasticsearch 将受到各种访问模式的影响。
想象一下，你的应用程序 A 试图删除 1000 万 个不太重要的用户文档，而另一个组件 B 试图更
新用户帐户详细信息。
如果你查看 Elasticsearch 监控指标，一切都是绿色正常。
但是，此时更新账户的用户可能不满意他们尝试更新帐户时的延迟。
因此，始终为你的 Elasticsearch 查询提供额外的应用程序级指标。
尽管 Elasticsearch 结合 Kibana 或者 cerbro 已经为整体集群性能提供了足够的指标，但它
们缺乏特定于操作的上下文监控，需要结合实际业务特事特办。
重视 CPU 的配置选型和使用率监控
怎么强调 CPU 都不过分。
从我过去的经验来看，无论是写负载还是读负载场景，CPU 一直是我们的瓶颈。
谨慎编写自定义的 Elasticsearch 插件
·许多 Elasticsearch 版本包含重大的内部更改。你的插件所基于的公共 API 很可能会向后不
兼容。
·你需要调整部署过程，不能再使用原始的 Elasticsearch 工作。
·由于你的应用程序依赖于于插件提供的特定功能，因此在集成测试过程中运行的 Elasticsea
-rch 实例也需要包含插件。你也就不能再使用原始的 Docker 镜像。
创作人简介：
铭毅天下，Elastic 认证工程师、Elastic 官方合作培训讲师、阿里云 MVP、CSDN 博客专家、
铭毅天下 Elasticsearch 公众号作者、死磕 Elasticsearch 知识星球星主。近 10 年工作经验，
关注 Elastic Stack 技术栈、大数据技术领域。
