业务场景优化

1. 使用 SSD。就像其他地方提过的， 他们比机械磁盘优秀多了。
2. 使用本地磁盘
3. 使用 RAID 0。条带化 RAID 会提高磁盘 I/O，代价显然就是当一块硬盘故障时整个就故障了。不要使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能
4. 使用大内存机器，比如 1:4
5. 确保堆内存最小值（ Xms ）与最大值（ Xmx ）的大小是相同的，防止程序在运行时改变堆内存大小。
6. 使用 G1 ZGC 减少停顿垃圾回收时间（ GC 默认采用 CMS 的方式，并发但是有 STW 的问题，可以考虑使用 G1 收集器。）
7. swap 调低，减少使用（保留一些，避免真的内存溢出了）
8. 减少字段，保留关键字段，详情通过 sql，或者 mongodb 查
9. 降级，使用 mq 写入，批量，查询量多时候暂缓插入
10. 深度分页优化
11. 增加 condition 协调节点
12. 增加机器性能配置
13. 增加节点数据，不过需要迁移索引

业务性能估算

• 日志类场景多属于写多读少型，计算资源主要用于写入，根据火山的测试数据，2C8G 的节点最大可支持 5000-10000 条日志/秒的写入，根据节点规格增长，基本上可以认为是线性的增长，例如 8C32G 节点可最大支持20000-40000 条日志/秒的写入，建议开始按最小值预估，后根据实际情况进行扩缩容。
• 日志场景若要实现超长时间（例如大于1个月）的存储，建议配置温节点、冷节点进行数据存储，配置数据的生命周期，可以显著降低存储成本，提升实例处理性能，具体参考利用 Data Streams 和 ISM 实现时序数据管理。
• 文本搜索场景如网站搜索、在线搜索场景，与日志场景相反，大多属于读多写少类型，计算资源主要用于查询，根据火山的经验，云搜索服务在不同的数据结构、不同的查询语法、不同的数据大小、不同的写入和查询 QPS 所需的资源均不一样，因此没有标准建议值，建议您实际数据和业务场景测试出适合您实际情况的实例规格和容量。

经验