成都那家网站建设好,广州网站建设多少钱,青岛模板建站代理,wordpress新增页面文章目录 困难解决方案初始方案及存在的问题segment merge引入预排序 拆分方案设计考量点如何去除冗余数据按什么维度拆分#xff0c;拆多少个最终的索引拆分模型演进历程整体迁移流程全量迁移流程流量回放比对验证异步转同步多索引联查优化效果 总结与思考参考 困难 索引数据… 文章目录 困难解决方案初始方案及存在的问题segment merge引入预排序 拆分方案设计考量点如何去除冗余数据按什么维度拆分拆多少个最终的索引拆分模型演进历程整体迁移流程全量迁移流程流量回放比对验证异步转同步多索引联查优化效果 总结与思考参考 困难 索引数据量亿查询请求耗时高大量查询耗时超过 1s 的请求数据的快速膨胀带来了很大的资源消耗和稳定性问题, 比如如查询抖动等等数据存在冗余大量的冗余数据带来了不必要的资源消耗索引所在集群资源已接近瓶颈但是扩容的话机器成本较高 解决方案
一开始从索引参数调整 forcemerge 任务引入等多个手段来缓解问题但是伴随数据的快速膨胀还是遇到类似高命中查询等难以优化的问题从而引出了索引拆分方案的探索与实施。
初始方案及存在的问题
我们先看看参数调整这些局限性的方案
segment merge
调大 merge 线程数调大 floor_segment 值。通过更多的 merge 来降低大量写入带来的 Segment 数增长引发的查询速率下降问题。 merge: {scheduler: {max_thread_count: 2,max_merge_count: 4},policy: {floor_segment: 5mb}}
segment merge 操作对系统 CPU 和 IO 占用都比较高从 es 2.0 开始merge 行为不再由 ES 控制而是转由 lucene 控制因此以下配置已被删除
indices.store.throttle.type
indices.store.throttle.max_bytes_per_sec
index.store.throttle.type
index.store.throttle.max_bytes_per_sec改为以下调整开关
index.merge.scheduler.max_thread_count
index.merge.policy.*最大线程数的默认值为
Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))是一个比较理想的值如果你只有一块硬盘并且非 SSD应该把他设置为1因为在旋转存储介质上并发写由于寻址的原因不会提升只会降低写入速度。
merge 策略有三种:
tieredlog_byete_sizelog_doc
默认情况下index.merge.polcy.type: tiered
索引创建时合并策略就已确定不能更改但是可以动态更新策略参数一般情况下不需要调整。如果堆栈经常有很多merge可以尝试调整以下配置 index.merge.policy.floor_segment: 该属性用于阻止 segment 的频繁 flush小于此值将考虑优先合并默认为2M可考虑适当降低此值。 index.merge.policy.segments_per_tier该属性指定了每层分段的数量取值越小最终 segment 越少因此需要 merge 的操作更多可以考虑适当增加此值。默认为10他应该大于等index.merge.policy.max_merge_at_once。 index.merge.policy.max_merged_segment: 指定了单个segment 的最大容量,默认为5GB可以考虑适当降低此值。 引入预排序
索引预排序的引入实测排序条件和预排序一致时亿级索引有3倍左右的提升。但是由于业务多样性导致命中预排序的场景只占一小部分。 sort: {field: [id,gmtModified,gmtApplied],order: [asc,desc,desc]}优化索引字段类型将精确匹配修改为 keyword 范围匹配修改为数值类型。( ES 针对不同的字段类型会采用不同的查询策略。keyword 使用 FST 的倒排索引方案数值类型采用 BKD 方案。前者更适合精确匹配后者对范围查询更优。增加索引的分片。当集群资源相对充足是有一定效果但是如果没有新的数据节点加入新增分片并不会有明显的性能提升。number_of_shards: 5每天跑 forcemerge 任务降低 Segment 数量提升白天的查询性能。但是伴随索引体积越来越大 forcemerge 的时间越来越长有时候整个晚上可能都无法结束。而且 forcemerge 期间会造成一定的集群抖动影响一些对请求耗时比较敏感的业务。难以解决的高命中字段查询。在实践中发现在大表中如果某个查询字段命中了大量文档在缓存失效的情况下大量时间会消耗在在这个字段上。 拆分方案设计
由于目前常规的操作都已经做过到目前阶段提升相对较小所以只能从拆索引的方案去入手。在方案的设计中我们主要有下面的一些考虑。
考量点 要实现不停机迁移。 要做到用户无感的底层数据表切换支持流量逐步切换用来观察集群压力支持快速的回滚用来应对可能出现的突发问题 能否去除全量xx索引降低数据冗余降低集群资源占用 按照何种维度去拆分拆分后的索引是否会有数据倾斜问题 能否支持后续的二次拆分伴随业务后续的发展第一次拆分后的索引在过了一两年后可能需要进行二次拆分操作 能否在查询时尽可能的要降低扫描的数据行数从而来规避可能遇到的高命中字段影响。 如何去除冗余数据
重新划定的索引数据范围将之前的全量xx索引数据分散成三份索引数据。 假设因为索引数据有交叉重复的部分可以对这部分重复数据打上特殊标识当三类型索引联查时过滤掉该部分数据解决数据重复问题。 按什么维度拆分拆多少个
一个索引怎么拆主要看使用的具体场景。 比如常见的日志索引就是按日期滚动拆分。 对应我们目前场景大约77%的请求会带上店铺ID 就基础商品查询而言有93%的查询都会带上店铺ID 。因此索引拆分最终是按照店铺维度去拆分。
最后就是拆多少个索引每个索引多少分片。拆多少个索引主要是看数据的分布拆多个索引可以保证每个索引上的数据大致相同不会有严重的数据倾斜问题。每个索引有多少个分片主要是评估拆完后每个索引有多少个数据以及未来一段时间的增量。 最终的索引拆分模型演进历程
【原始索引模型】
保留 基础索引 和 交易商品索引。 把全量商品索引拆分拆分后的整体全貌如下 拆分后需要进行【多索引联查】
整体迁移流程
整体迁移在设计中主要分为流量收集全量写入增量写入数据验证写入方式的异步转同步等阶段。通过完整的迁移流程设计来保证最终迁移的数据正确性。 全量迁移流程
该过程主要为历史数据的迁移并填充历史全量索引的部分数据重组后的商品数据分散写入到拆分后的新索引中。
全量迁移需要做到两点其中一个是数据不丢失第二就是较快的迁移速率。对于第一点主要解决手段就是在全量迁移任务开启前通过消息队列收集所有迁移过程中的数据。 【数据拉取慢的问题】
在迁移过程中我们遇到的第一个问题就是全量数据拉取过慢问题。
就迁移速度而言因为本次和一般的索引拆分不同不是单纯的将一个索引的数据按店铺拆分到多个索引上而需要额外填充字段所以 Reindex 并不满足。即使是通过先将一部分数据 Redinex 数据迁移到新集群上再二次填充也不太满足因为 ES 跨集群 Reindex 会限制并发数为1同时需要将两个集群添加白名单这个需要将集群进行重启操作成本也相对较高。之所以不在原集群进行拆分的原因是原集群的资源已经到达瓶颈没有足够的磁盘和内存空间承接新索引。
如何在不使用 Reindex 的情况下保证迁移速率呢。首先我们尝试了 Scroll 方案但是后续发现对一个亿级索引做全表 Scroll 查询单次拉取时间保持在500-600ms左右这个拉取时间严重不满足我们的需求。因为在全量数据迁移期间增量数据要保持收集的而商品每天平均有千万级别的更新请求同时在晚上会有大量的数仓回流任务。如果整个迁移要持续好几天会对在 MQ 中积压大量的写入消息不光会导致到时候流量回流时间过长也可能导致 MQ 集群磁盘被打满。
【优化方案】
那么如何提升拉取的效率呢要提升查询速率可以通过降低单次扫描数据量来单次降低查询耗时的方案。提升了单次查询耗时后就需要将大任务进行拆分多节点并行的方案来提升整体的拉取效率。最终我们选择按商品创建时间来作为任务拆分的方案一个是该字段不可变第二个是每天商品创建量相对比较恒定任务相对均匀。任务首先按应用节点拆分为节点级大任务节点内再按天拆分为更小的任务。这样可以做到多任务并行并可以根据 ES 集群的压力通过扩充节点的方案来加快数据迁移。
任务执行总共分为两步即数据拉取和写入阶段首先是数据拉取该阶段主要负责从原索引获取数据并填充上全量商品索引的部分字段这一个阶段的拉取是通过 SearchAfter 方案进行拉取因为整个迁移流程持续时间较长部分任务有可能因为网络抖动等问题执行失败利用 SearchAfter 可以做到任务断点续跑。
数据写入阶段组装完的数据就需要按店铺 ID选择索引并写到新集群了。将读写任务进行拆分可以提升整体的资源利用率并方便进行拉取或写入的限流。过程中只需要做好失败任务的从事并监控系统资源即可。
通过上述优化迁移完所有全量数据总计用时 5 个小时左右。 流量回放
在全量任务开始之前我们将老索引的流量拷贝了一份放入到了消息队列中流量回放即是将这部分流量在全量任务结束后进行回放到新索引上。
回放没有什么特别但是有一定要注意。在我们的数据写入场景中有一种一对多更新的任务比如店铺名称更新等如果这种增量流量和普通的商品主表流量一起回放可能会造成部分商品店铺信息未修改成功的问题。因为商品主表更新和店铺信息不处在同一个任务源。如果在商品主表流量未追平之前就开始进行店铺信息的修改就会导致部分商品漏改的情况。因此整个回放流程是商品主表增量流量追平后再开始回放一对多更新流量。 比对验证
在迁移完成后要进行比对验证验证数据和查询逻辑改造的正确性后才能开启。
【文档比对】
文档对比主要是新老索引文档内容进行比较比对分两次一个是正向比对即通过新索引的 Query 到的数据去和老索引进行比对。这次主要确认新索引上的字段与老索引保持一致。一个是反向比对即通过老索引 Query 到的数据去和新索引进行比对。这次主要解决比如类似新索引数据没有删除部分商品可能缺失的问题。由于整个商品数量级比较大且数据在频繁更新。比对主要采用的是抽样 DSL 语句比对。
【查询流量比对】
因为本次不光涉及到索引的拆分还涉及索引的合并。合并必然会带来查询逻辑的变更。因为三类索引上存在对同一个商品属性不同的索引字段名的情况比如商品的ID有的索引叫 ID 有的叫 ItemId 。此外还有查询时路由选择问题这些查询侧的改动需要对查询流量进行比对。 异步转同步
在迁移过程中为了保障服务的稳定性采用的是 MQ 异步写入新索引的方案。这样可以在灰度开放过程中限制新索引的写入流量同时不影响老索引的写入性能。在完全切换到新索引后需要由异步写入切换回同步写入。考虑切换回去主要有两点考虑一个是写入流程中增加了一个可能的不稳定性因素。一个是可能发生由于某个业务域推送大量变更消息引发的消息积压。比如大店铺的店铺名称变更操作等这些大任务可能会阻塞用户正常的商品发布下架等核心链路流程。
因为数据要求最终一致性核心问题就是如何保证从 MQ 消费写入更改为直接请求 ES 写入过程中消息没有乱序。 这里主要就是用 Redis 的分布式锁达到一种节点间的分布式共识。这中间主要分为 预备阶段共识磋商阶段
【预备阶段】
首先在 Redis 中创建一把值为0成功锁和一把值为0失败锁。
然后当观察 MQ 中消费堆积的阈值比较低时这时即可开启预备阶段。这样消费线程在投递到 MQ 队列之前会先检测一下当前消息堆积值当小于设定值时进入共识磋商阶段。
【共识磋商阶段】
应用节点的消费者线程进入该阶段后会进行一定次数的自旋并不投递消息而是每隔 1s 去 Check 一下当前 MQ 队列的堆积值如果连续两次 Check 到堆积值为 0就在 Redis 中把成功锁的值加一。后续执行过程中如果发现成功锁的值等于参加的节点数直接将数据写入到 ES 。
期间如果有一个节点发现自己超过设定的自旋次数就会将失败锁加一同时将消息投递到 MQ 中其他节点发现失败锁大于0后也会结束自旋将数据投递到 MQ 中。后续可以再通过调整自旋次数等参数直到所有节点全部达成一致。
这样就通过秒级的消费暂停达到了 MQ 队列下线的效果。 多索引联查
解决了数据迁移的问题后关键的问题就是要提升查询的效率降低查询 RT 提升请求 QPS 。一般来讲当查询遇到瓶颈我们往往都会通过建索引分库分表历史归档等操作。这些操作之所以能提升查询性能就在于能降低要扫描的数据规模。越早地降低数据规模就代表更低的 CPU磁盘 IO内存网络等开销。因此在设计拆分后的索引查询时也要尽可能地降低要扫描的数据规模。在本次设计中我们引入了请求改写、索引选择、返回体修改三个功能模块。 【请求改写】
当接收到用户请求后首先要进行一次请求改写。
这一步主要有两个目的一个是要将 DSL 语句改写为3种索引都兼容的格式因为后续这个语句可能要扫描所有类型的索引。
还有一个是解决基础商品索引和交易商品索引中重合的那一部分数据。目前的解决方案是在基础商品索引中做上标识在出现基础商品索引和交易商品索引联合扫描时排除掉基础商品索引中的数据。
【索引选择】
整体上有两次降低数据规模的机会在查询进来时尝试判断用户要看哪一类的商品基础商品还是交易商品等这一路如果成功可以减低 50% 左右的数据规模。在下一步判断供应商所在的具体索引这一步可以进一步降低要扫描的数据规模。通过两次索引推荐可以降低绝大部分查询要扫描的数据量。后续可以再对全表扫描的请求做针对性优化和限流控制即可保障整体的稳定性。 优化效果
在索引拆分完成后我们达到了如下效果。 总结与思考
本次主要通过索引的拆分与合并来提升查询性能同时降低整体集群的资源使用量。过程中我们探索了在线数据的跨集群迁移多索引联合查询的应用数据写入的同步异步切换等希望能够为大家提供解决 ES 大规模数据检索的瓶颈提供参考。
虽然本次相对比较平滑的完成了索引的拆分但是需要耗费大量的开发和测试资源。伴随业务的快速发展遇到数据瓶颈的业务线可能有会逐渐增多如果届时每个业务域要独自开发和测试成本还是相对较高的。
后续可能考虑将 ES 的索引层和存储层进行分离通过引入类似 TiKv 或 HBase 等可以无限扩充的 KV 存储来替代 ES 的存储层。通过 KV 存储来重建 ES 索引。这样可以做到业务方配置化的索引拆分分片扩容等无需任何的开发进一步的降本增效。 参考
ES亿级商品索引拆分实战
