扩展和测试方案

在体验完 Elasticsearch 便捷的操作后，下一步一定会碰到的问题是：数据写入变慢了，机器变卡了，是需要做优化呢？还是需要扩容设备了？如果做扩容，索引的分片和副本设置多少才合适？如果做优化，某个参数能造成什么样的影响？

而 ES 集群性能，受服务器硬件、数据结构和长度、请求接口复杂度等各种环节影响颇大。这些问题，都需要有一个标准的测试流程给出答案。

由于 ES 是近乎线性扩展的分布式系统，所以对上述需求我们都可以总结成同一个测试模式：

1. 使用和线上集群相同硬件配置的服务器搭建一个单节点集群。

2. 使用和线上集群相同的映射创建一个 0 副本，1 分片的测试索引。

3. 使用和线上集群相同的数据写入进行压测。

4. 观察写入性能，或者运行查询请求观察搜索聚合性能。

5. 持续压测数小时，使用监控系统记录 eps、requesttime、fielddata cache、GC count 等关键数据。

测试完成后，根据监控系统数据，确定单分片的性能拐点，或者适合自己预期值的临界点。这个数据，就是一个基准数据。之后的扩容计划，都可以以这个基准单位进行。

需要注意的是，测试是以分片为单位的，在实际使用中，因为主分片和副本分片都是在各自节点做 indexing 和 merge 操作，需要消耗同样的写入性能。所以，实际集群的容量预估中，要考虑副本数的影响。也就是说，假如你在基准测试中得到单机写入性能在 10000 eps，那么开启一个副本后所能达到的 eps 就只有 5000 了。还想写入 10000 eps 的话，就需要加一倍机器。

另外，测试中我们使用的配置都尽量贴合当前现状。事实上，很多配置可能其实并不合理。在确定基准线并开始扩容之前，还是要认真调节配置，审核请求使用的接口是否最优，然后反复测试。然后取一个最终的基准值。

审核请求，更是一个长期的过程，就像 DBA 永远需要关注慢查询一样。ES 的慢查询请求处理，请阅读稍后性能日志一节。