Elasticsearch索引使用方案
考虑到数据查询的性能问题，需要测试三个可选的索引使用方式，分别是
- 单索引12分片
- 单索引24分片
- 多索引24分片 考虑所有查询请求中都需要对时间进行过滤，所以上述三种方式都对时间字段进行排序存储。
测试环境
| 机器信息 | 机器CPU核数 | 机器内存容量（GB） | Elasticsearch堆内存大小（GB） |
|---|---|---|---|
| node1 | 12 | 32 | 16 |
| node2 | 12 | 32 | 16 |
| node3 | 12 | 32 | 8 |
测试结果
基于简单索引结构的查询，进行性能测试，由于Elasticsearch对查询具有缓存机制，因此测试结果分为两部分：首次查询和基于缓存查询。
- 首次查询结果
- 基于缓存的查询结果
从上述测试结果可以得出两个结论：
1、增加索引的分片数可以略微提升性能，但并不是特别理想。
2、将相同的数据分多个索引只有部分查询有轻微的性能提升。
从结果看，增加一倍的分片数并不能明显的提升查询的性能，但考虑到Elasticsearch的读写可以并行处 理不同的分片，因此为了提高资源的利用率，可以把索引的分片总数设置为集群的CPU核数，比如，集 群中有三台机器，每个机器有8个CPU核心数，那么集群的CPU核心数为24个；然后如果索引有一个副本（即索引在集群中会被存储两份），那么索引的主分片数可以设置为12个（24 / 2）。接下来分析单索引与多索引的选择。多索引在性能上的提升不明显，有些查询还出现性能的下降，其最大的优势在于可以利用Elasticsearch的索引生命周期管理机制自动完成对索引的管理，比如对存储时间 较久的索引执行删除操作。但这种管理方式不能很好的配合父子形式的文档的存储。有关联的父子文档 需要存储到相同的索引下，但多索引的切换机制不能确保这一点，例如，在测试上述查询性能时，多索 引的写入方式下，由于父子文档被分到不同索引下存储导致查询时其数据丢失了1‰。当然也可以通过 使用客户端接口进行控制以实现多索引下的父子文档正确存储，但这样会增加写入的复杂度，并影响写 入性能。
所以目前看单索引是唯一可行的方案。并且对于索引的管理，最重要的步骤是删除过期数据，由于索引 中的数据是按时间字段排序存储的，并且Elasticsearch支持按查询结果进行删除，所以根据时间删除数 据是一个很容易实现的功能，唯一不足的地方是这个动作需要通过外部控制执行。
