背景
终于要用ES干一件大事了，最近一个需求需要记录用户作品的实时访客行为，有点类似于pv明细日志，记录用户什么时间打开的产品、在里面都做了什么操作，初步预估日流量在5000w左右，月累积15亿+，业务方要求数据保留1年，没有聚合，只需支持任意检索与排序，这么大的数据量如何实现高并发下的查询排序将是一个很大的挑战。
操作流程
经常有同学问我，想用ES但不知道怎么去优化，根据在易企秀多年业务实战经验总结 分别是：集群规划、索引配置、存储策略、索引拆分、冷热分区、段合并等几个维度优化。
集群规划
hot 组 4台：
| 参数 | 说明 |
|---|---|
| cpu | 16c |
| 内存 | 48g |
| 硬盘 | 300g ssd |
| 数据 | 近3个月 |
| 特点 | 经常读写 |
cold 组 2台：
| 参数 | 说明 |
|---|---|
| cpu | 16c |
| 内存 | 64g |
| 硬盘 | 1T*2 hdd |
| 数据 | 历史9个月 |
| 特点 | 没有写、也不怎么读 |
索引配置
和搜索业务不同，并不需要对文档数据的相关度计算，所以索引配置可以做些优化：
1、通过配置index_options优化text field的索引生成方式，es默认除生成倒排以外还会记录文档的词频与term的位置信息，如果只是用来对文档的检索不需要评分与高亮，可优化。
2、禁用field评分，如果该字段不需参与相关度打分那么可禁用，通过将norms设置为false来禁用评分提升检索性能。
3、禁用doc_values，es为提升keyword类型下数据的排序与聚合性能，默认为每一个keyword field都开启了此功能，非必要场景禁用此操作可节省磁盘空间。
4、开启最优化压缩，通过配置"index.codec":"best_compression"开启最优压缩，可节省磁盘空间，但会增大cpu负载。
5、单分片的优势是检索速度快，但并发支持不高；我们大多数业务场景 1-2 个分片足够了（官方建议单分片10-20亿条，20GB 到 40GB存储大小为最佳）。
6、热数据采用两副本，提升数据容错与检索性能，冷数据禁用副本分片，节约存储空间。
7、设置刷新，当月数据设置"index.refresh_interval":"120s"，历史索引禁用刷新操作。
8、translog异步操作，"index.translog.durability": "async"
9、term的使用
ES 7对term类型做了性能优化 ，较之前提升37倍多，所以能用term解决的就不要使用数值或文本类型
10、自动生成Id
因为存储的是用户行为日志，所以不存在更新操作，每条日志的唯一标识可随机生成，写入性能提升近1倍。
索引策略
routing，根据某个字段将相同数据发送到相同分片上存储，检索时使用相同路由策略可实现数据的快速获取：
shard_num = hash(_routing) % num_primary_shards
默认使用doc id路由，因为我们存储的是用户作品的访问记录，这里会根据user_id，将同一用户下作品数据的访问记录路由到一个分片：
PUT my_index/my_type/1?routing=user_id
{
"title": "This is a document"
}
GET my_index/my_type/1?routing=user_id
由于用户的作品量是不同的，且不同作品的传播能力差别也很大，故上面的路由规则实际操作过程中会出现数据倾斜的问题，导致各别节点存储资源，检索压力会特别大，故优化上述路由策略，新增routing_partition_size
shard_num = (hash(_routing) + hash(_id) % routing_partition_size) % num_primary_shards
routing_partition_size 为ES 6.x之后新增配置，取值大于1 且小于主分片数，另外在mapping中还需配置：
{
"mappings": {
"_routing": {
"required": true
}
}
}
经测试 routing 在分片数大于2时使用效果明显
索引拆分（冷热分离）
应用程序内通过系统时间动态生成索引，并将超出3个月的索引通过定时任务归档到cold组 ：
1、将data node划分为冷热数据节点
# cat elasticsearch.yml // 配置文件设置tag区分
node.attr.tag: cold/hot
# bin/elasticsearch -d -Enode.attr.box_type=hot //启动设置
2、根据模板按月生成索引，格式如 visitor_2019-01
#构建索引模板,滚动新增的索引将按照模板进行创建
curl -X PUT "localhost:9200/_template/visitor" -H 'Content-Type: application/json' -d'
{
"index_patterns": ["visitor_*"],
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1,
"index.routing.allocation.include.tag" : "hot"
}，
"mappings": {}
}
'
3、归档历史数据到cold节点
curl -X PUT "${es}/${i}/_settings" -H 'Content-Type: application/json' -d'{
"number_of_replicas": 0,
"index.routing.allocation.include.tag": "cold"
}'
段合并
对于不再进行数据写入的历史索引，强制进行segment合并可大幅提升检索性能
curl -XPOST "http://host/visitor/_forcemerge?only_expunge_deletes=true&max_num_segments=1&flush=true"
结论
想要了解按照上面流程优化后的实际性能，请关注我的下一篇文章 ES数据实测分析
架构的快速迭代源于业务的快速发展，正是由于易企秀近几年的快速发展，ES集群的规模也在不断升级；正所谓没有最好的架构，只有最适合的架构，数据中台做性能最强、稳定最好、使用便捷的系统初心不会改变