Tidb分表聚合业界经验咨询

🪐 TiDB 技术问题 备份&数据迁移
1

为提高效率，提问时请尽量提供详细背景信息，问题描述清晰可优先响应。以下信息点请尽量提供：

  • 系统版本 & kernel 版本： 无关
  • TiDB 版本： 无关
  • 磁盘型号： 无关
  • 集群节点分布： 无关
  • 数据量 & region 数量 & 副本数： 无关
  • 集群 QPS、.999-Duration、读写比例： 无关
  • 问题描述（我做了什么）：

请问，有同学基于tidb在生产环境实现过稳定可靠的分表聚合场景需求吗？ 如果有，是通过什么技术路线实现的呢？

2
  • 摩拜开源了他们的技术方案 Gravity. Shopee内部实现了一个类似的中间件 DEC (Data Event Center) 来解决这个问题. 关于DEC, 我们的架构师同学在QCon上做过分享. 如果摩拜开源得更早一些, 或许我们就不需要从零开始再造一个轮子了. 当然, 除了异构数据复制, 我们的DEC也做了一些更细致的业务层适配. 例如, MySQL Binlog还可以转化为有业务含义的事件通知; 也可以使用LUA脚本自定义处理逻辑.
  • 如果要做一个通用的组件来处理分表聚合问题, 可以考虑借鉴或者重用Gravity. 通用组件的设计和开发都会遇到一些棘手的问题. 从多个MySQL分表聚合数据到一个TiDB表的复杂性在于, 某些字段可能会发生微妙的变化. 例如, 通常而言每个MySQL表都会有使用自增ID做主键, 同步到TiDB后该如何处理呢? 因为来自不同MySQL分表的自增ID可能会重复, 这些自增ID也可能有业务含义, 如何在下游的TiDB表中继续保持其业务语义的兼容性就成为一个问题了.
  • 如果不走通用组件路线, 则自由度大一些, 可以和业务做更多绑定. 缺点是不够通用, 每一个分表聚合场景都要重新写一遍. 但是胜在性能好, 简单直接. 我们内部也有舍弃DEC, 直接自己上手做增量异步数据同步的案例.
1 个赞
3

感谢介绍:heart:

4

你好，请问你们分表聚合的场景是把上游数据库中间件的各个分片聚合同步到下游 TiDB 的表中嘛？

6

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。