分库分表后复杂查询的应对之道：基于DTS实时性ES宽表构建技术实践
内容提要
文章介绍了数据库架构在业务发展初期往往是单库单表，随着用户量和订单量的增加，数据库成为系统瓶颈。解决方案有分库分表、构建ES宽表和构建查询条件到表主键Mapping映射表。ES宽表的构建解决方案有同步双写、异步双写和基于Binlog的实时同步。文章对解决方案的优缺点进行了对比，并介绍了实践中的顺序性保证、幂等性保证、数据一致性保证和存量数据迁移。最后，介绍了ES复杂检索的分类和查询条件构建。
延伸解读
分库分表后的查询挑战与应对思路
分库分表虽能解决数据库读写和存储瓶颈，但会带来多条件分页、联表查询等复杂性问题。业界常用方案包括构建ES宽表和查询条件到主键的映射表。ES宽表通过主键将多张表关联成一张宽表，例如订单维度宽表可包含订单主表、明细表、商品表、用户表等字段，从而支持复杂检索。
ES宽表构建方案对比：同步双写、异步双写与Binlog同步
同步双写是在写请求后同步写DB和ES，异步双写是先写DB再异步发MQ写ES，基于Binlog的实时同步则分为将Binlog作为消息（需RPC调取下游组装数据）和将Binlog作为数据（直接解析变更构建宽表）。文章对比了各方案优缺点，但未给出具体结论，读者需结合业务场景权衡。
实践中的关键保障：顺序性、幂等性与数据一致性
基于Binlog构建ES宽表时，顺序性通过DTS按业务主键（如订单号）哈希到同一队列和分区来保证局部有序；幂等性需业务方处理，因DTS可能重复发送消息，UPDATE/DELETE天然幂等，INSERT需先判断存在性；数据一致性通过定时任务对账和补偿任务保证；存量数据迁移采用定时任务分页从MySQL迁移到ES。
ES复杂检索的实现要点
ES复杂检索主要针对多条件复杂查询，采用Bool查询进行条件构建。文章未展开具体构建细节，但指出这是应对分库分表后复杂查询的重要环节。读者需注意，Bool查询的组合方式会影响检索性能，实际应用中需结合业务查询模式优化。
Q&A
为什么单库单表在业务发展中会成为瓶颈？
随着用户量和订单量的增加，单库单表的计算和存储能力无法满足需求，导致系统性能瓶颈。
分库分表的主要解决方案有哪些？
主要解决方案包括分库分表、构建ES宽表和查询条件到表主键Mapping映射表。
ES宽表的构建方案有哪些？
ES宽表的构建方案有同步双写、异步双写和基于Binlog的实时同步。
同步双写和异步双写有什么区别？
同步双写是在写请求后同步写入DB和ES，而异步双写则是先写DB后异步发送MQ写入ES。
如何保证数据的一致性？
可以采用定时任务对账机制保证数据一致性，若不一致则使用补偿任务进行修复。
ES复杂检索是如何分类的？
ES复杂检索主要分类为多条件复杂查询，通常使用Bool查询进行检索条件构建。
