25

ES集群优化 之 海量时序数据处理 - 简书

 5 years ago
source link: https://www.jianshu.com/p/fd9aef9b124b?qq=
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

ES集群优化 之 海量时序数据处理

0.5332019.07.17 18:32:19字数 1,259阅读 2,416

终于要用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集群的规模也在不断升级；正所谓没有最好的架构，只有最适合的架构，数据中台做性能最强、稳定最好、使用便捷的系统初心不会改变


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK