ES使用场景:
主要用来进行明细模糊搜索,用户通过关键字进行明细搜索,现在默认搜索区间是2年,ES中要存储10年数据。按照现在数据量,一年越400亿条数据。
集群部署方案:
物理机的配置为36core + 384GB + ssd磁盘,一共19台物理机,每台物理机只部署一个es节点。
3个master节点+16个data节点,堆内存配置为31GB。
建索引的方案:
索引文档定义情况:strict严格模式共定义了35个字段,9个中文字段采用standard分词且字符串长度在30以内,其余字段基本是keyword类型。400个主分片,复制分片个数为2,一个索引共400个主分片,800个复制分片,refresh_interval为2秒。
索引的id生成方式为5业务主键拼接。
终态为保存最近十年数据,按年建索引,比如2013到2022共十个年的数据,每年的数据放一个索引,共3000亿条数据,单条数据0.3k。
数据现状:
目前集群有三个索引2020,2021、2022,2023数据量分别为几百万条、400亿条,400亿条、30亿条。
无数据倾斜,通过es的监控api确认了16个data节点上每个data节点的数据量均匀,每一个索引在每个data节点上的分片数均匀,每个分片的的数据量均匀。
单个分片大小约为20GB
ES访问情况
实时写:两个机房增量数据7*24小时不停的写,因为不停有交易数据产生,每日写入2.2亿条,最高TPS为4k左右
批量写:夜间对于存量的数据做批量bluk导入,一个bulk条数为5000条。
现在写入都是指定id方式,没有使用ES自己生成ID的方式。因双机房双写的场景,实时写入场景无法使用自动生成id的方式。
五个现象:
1批量写数的时候有一两台es节点的物理机cpu特别高,90以上,其他很低,10%左右,重启该es节点之后,会变成其它节点的cpu特别高,问题没有解决,只是发生了转移。
2批量写较慢,当索引数据量小的时候TPS能到10万,目前索引数据量300亿条时,批量写的TPS只能到4万
3日间实时写的时候采用的是es的sdk中的Hi Level Rest 批量写入,bulk策略为(3秒、5M、1000条),超时时间2秒,会偶然出现超时问题,持续时间较短1-2分钟,此时es的监控并没有什么异常。
4夜间离线导数的时候,由于导入的数据量较大,实时写入的的超时报错比日间更严重。
5目前为内测查询阶段,只有几十个账户可用查询,根据es返回json中的took值发现,查询时间不稳定,具体分布还在统计,会有一定机率出现耗时较长的查询(超过1s),对用户体验影响较大。 查询指定了routing,采用了filter过滤,只查询当前用户的数据,对9个中文字段做multi query,只查询第一页数据。
收起