写点什么

分库分表后复杂查询的应对之道:基于 DTS 实时性 ES 宽表构建技术实践

  • 2024-06-24
    北京
  • 本文字数:939 字

    阅读完需:约 3 分钟

1 问题域

业务发展的初期,我们的数据库架构往往是单库单表,外加读写分离来快速的支撑业务,随着用户量和订单量的增加,数据库的计算和存储往往会成为我们系统的瓶颈,业界的实践多数采用分而治之的思想:分库分表,通过分库分表应对存系统读写性能瓶颈和存储瓶颈;分库分表帮我们解决问题的同时,也带来了复杂性;比如多条件的分页查询,多条件的联表查询变得复杂起来,通过调研我们发现针对这些分页,联表的复杂查询,业界常用的解决方案有以下两种:1 构建 ES 宽表2 构建查询条件到表主键 Mapping 映射表;本表文章介绍我们的实践:基于公司的中间件 DTS 构建实时性的 ES 宽表。所谓的宽表是通过主键将多张表关联成一张表,比如订单维度的宽表字段包含:订单主表,订单明细表,商品表,用户表等表字段。

2 ES 宽表构建解决方案域

2.1 同步双写

应用在接收到写请求后,同步写 DB 成功,然后再同步写 ES。


2.2 异步双写

应用在接收到写请求后,同步写 DB 成功,异步发送 MQ,消费 MQ 异步写 ES。


2.3 基于 Binlog 的实时同步

2.3.1 Binlog 作为消息

将 Binlog 作为消息,或者驱动的 Event,接收到消息后,RPC 调取下游的业务系统,获取业务数据进行数组的组装,写入 ES。


2.3.2 Binlog 作为数据

解析 Binlog 中的数据,获取库表,字段变更前后的内容,INSERT, UPDATE, DELETE 事件,基于 Binlog 中的数据去构建宽表,写入 ES。


3 解决方案优缺点对比

4 我们的实践

4.1 Binlog 作为数据构建 ES 宽表

4.1.1 顺序性的保证

上游 DTS 监听的 binlog 是有序的;发送消息时,业务方可以配置业务主键例如 uep_order_no,DTS 可以根据业务主键进行 hash,将该条消息发送到对应的队列保证局部有序性;消费者消费时,同一个订单号 uep_order_no 映射到同一个分区,保证顺序消费;

4.1.2 幂等性的保证

DTS 可以保证消息不丢失,但不保证消息不重复,可能发送重复的消息需要业务方保证幂等性,


UPDATE/DELETE 操作天然具有幂等性


INSERT 操作在进行操作前需要先判断下数据是否存在,不存在则插入,存在则更新

4.1.3 数据一致性的保证

由于数据存储在 Mysql 和 ES 两种存储媒介,可以采用定时任务对账机制保证数据的一致性,如果数据不一致采用补偿任务进行补偿操作

4.1.4 存量数据迁移

采用定时任务分页将数据从 Mysql 迁移到 ES

4.2 ES 复杂检索

4.2.1 检索的分类

多条件的复杂查询,采用 Bool 查询;


4.2.2 查询条件构建


发布于: 刚刚阅读数: 5
用户头像

拥抱技术,与开发者携手创造未来! 2018-11-20 加入

我们将持续为人工智能、大数据、云计算、物联网等相关领域的开发者,提供技术干货、行业技术内容、技术落地实践等文章内容。京东云开发者社区官方网站【https://developer.jdcloud.com/】,欢迎大家来玩

评论

发布
暂无评论
分库分表后复杂查询的应对之道:基于DTS实时性ES宽表构建技术实践_京东科技开发者_InfoQ写作社区