Cloud Native Geo-distributed Database

1. Cloud-Native Geo-distributed Database 李勇 ebay

2. 讲师简介请插入您的照片李勇 Senior MTS ee.msup.com.cn ebay云原生数据库NuDocument架构师。曾任华为GaussDB资深专家和Oracle BerkeleyDB Principle Engineer，在数据库内核和云基础架构领域有着多年的深耕。目前，在ebay负责 NuDocument的分布式事务和HTAP项目。

3. 目录 ee.msup.com.cn 历史机遇任重道远壮阔蓝图玩转生态平衡之道拥抱未来

4. 历史机遇 – 旧系统的问题昂贵 ee.msup.com.cn 笨重传统 • 高昂的License年费 • 扩缩容周期长 • 租户间不隔离 • 专有硬件 • Schema变更繁复 • 人工切换主备 • 低下的资源利用率 • 维护不透明 • 应用维护分片

5. 历史机遇 - 云化和微服务化经济敏捷云化 • 无年费 • 小时级扩缩容 • 租户间完全隔离 • x86服务器 • 文档数据模型 • 秒级自动故障恢复 • 良好的资源利用率 • 维护用户无感知 • 应用无需关心分片服务1.8亿活跃用户，日处理请求数超万亿级，可靠性>99.95% ee.msup.com.cn

6. 任重道远 - 坚实的第一步基本的分布式OLTP数据库 • 提供本地事务 • 可允许1副本损坏 • Sharding的细节对用户透明 • 自动化工作流 ee.msup.com.cn

7. 任重道远 - 充满挑战的转型完整的自研事务引擎 • 可允许N/2-1副本损坏 • 99%写时延降低3倍 • Point-in-time recovery • 全局二级索引 ee.msup.com.cn

8. 任重道远 - 无限可能的未来全自研OLTP系统 + 分布式事务 • 全自研存储引擎 • 跨租户分布式事务 • 分布式GTM ee.msup.com.cn

9. 壮阔蓝图 - 三地三中心部署 ee.msup.com.cn

10. 壮阔蓝图 - 控制面架构 ee.msup.com.cn

11. 壮阔蓝图 - 数据面架构 ee.msup.com.cn

12. 壮阔蓝图 - 监控架构 ee.msup.com.cn

13. 玩转生态 - Kubernetes深度整合挑战 ee.msup.com.cn 方案 • 跨Zone访问 • 全局唯一IP地址 • 数据持久化 • 本地SSD • 数据备份 • 网络存储 • 不停机维护 • 深度集成API

14. 玩转生态 - 数据圈消息平台使用CDC技术，将事务中包含的消息数据实时推送至消息平台，完成消息转发。 ee.msup.com.cn 流处理分析平台使用CDC技术，实时将变更发送到流处理平台。使用ETL技术，定时将一定时间内变更的所有数据发送到数据分析平台。

15. 平衡之道 - 资源规划交易密集型 CPU：中-高内存：中-高存储：低-中存储密集型 CPU：低-中内存：低- 中存储：高 ee.msup.com.cn 批处理任务 CPU：低-高内存：低-高存储：中-高

16. 平衡之道 - 资源规划 - 早期实现优点单一SKU/POD规格 - 资源规划简单 DC-aware 随机部署 - 实现简单缺点 - 资源利用率低 - 无资源碎片化 - 节点间负载不均衡 - 可容忍单数据中心故障 CPU/内存超卖 - 可提升资源利用率 - 租户间互相影响 - 性能波动大存储容量按需分配 ee.msup.com.cn - 实现简单 - 扩容需要数据迁移， - 资源利用率高成本高

17. 平衡之道 - 资源规划 - 自动规划多规格多路径精细化 • SKU-存储型/平衡型 • 变更POD规格 • Rack-aware • POD-1x/2x/4x • 变更复制组规格 • Shard rebalance ee.msup.com.cn

18. 平衡之道 - CAP 强一致影响性能高可用弱化一致性/性能 ee.msup.com.cn 高性能牺牲一致性

19. 平衡之道 - CAP - 早期实现优点 ee.msup.com.cn 缺点 MongoDB原生复制 - 零开发成本读写分离弱一致读 - 负载相对均衡写quorum=2 - 平均写时延 < 10ms - 可能出现脑裂复制集7副本 (3+3+1) - 单一DC故障下，可保 - 存储成本高 - 写时延长尾问题严重 - 选主不可控 - 弱一致读 - 平均读时延 ~ 1ms 证1主2备

20. 平衡之道 - 高可用 vs. 高性能 - 自主可控 ee.msup.com.cn 自研Raft复制 Quorum=大多数 • 99%写时延降低3倍 • 选主可控 • 单DC受灾无数据丢失 • 无脑裂

21. 平衡之道 - TP vs. AP 我们一共有多少条数据？这个卖家上个月成交多少笔？ ee.msup.com.cn 昨天更新了多少条数据？这个卖家某类订单总数？

22. 平衡之道 - TP vs. AP - 早期实现优点使用GSI 缺点 - 查询效率比较高 - 每个查询都要建立对 - 可以使用任意字段作应的index 为Sharding key - 需要自行实现算子，开发成本高使用预留节点 - 不占用额外的资源 - 仍然需要 index 来提升查询效率 - 自行实现算子，开发成本高 ee.msup.com.cn

23. 平衡之道 - TP vs. AP - HTAP 双存储引擎架构 • 异步复制 • Service层查询转发 • 查询引擎基于Clickhouse • 存储引擎扩展Clickhouse • 查询性能提升100x - 1000x ee.msup.com.cn

24. 平衡之道 - 集成开源 vs. 自研自研贴近业务运维成熟度高集成开源员工满意度高快速上线验证开发周期长聚焦核心 License风险运维学习曲线陡峭 ee.msup.com.cn

25. 平衡之道 - 速度 vs. 质量质量第一形式化证明代码审查代码重构多样化的测试快速迭代有效的监控小步快跑与用户合作解决问题不问责 ee.msup.com.cn

26. 拥抱未来 - 流程自动化到智能运维负载画像异常检测 Schema 变更负载预测实时监控 ee.msup.com.cn 故障定位

27. 拥抱未来 - 数据云第三方算法 BI 分析师产品数据数据治理 ee.msup.com.cn 决策

28. 关注msup公众号获取更多工程效能实践案例