分布式数据库选型

低
缓存 系统 分布 式数 据库
较成熟
低
较成熟
利用软件技术，将单机的 相对于传统单机数据库， 需要存储超越千万级到 传统数据组合为分布式的 增加了一定的复杂度， 百亿级别的记录规模的 数据存储系统，通常基于 同时部分SQL在分布式 场景 开源的数据库构建，具备 情况下难以很好的实现， 传统数据库的优点的同时， 比如跨库JOIN，事务问 又在一定程度上解决了单 题也是一个突出问题 机数据库的缺点 1
6
数据库分片的实施经验和指导
• 分片数量：一个表的分片数量不建议太多，一开始尽量数量少，当低于 可接受的性能指标之后，再扩展
• 分片规则：建议的分片规则为范围分片，比如ID，比如数据的时间，范 围分片的好处是容易扩容，数据无需移动
• 分片查询：查询SQL尽量能增加分片字段的查询条件，避免跨分片查询， 跨分片的SQL导致性能和并发性问题 • 数据热点：频繁访问的数据，与非频频访问的数据交叉在每一个数据库 实例上，使得系统负载总体比较均匀，避免数据访问热点
• 结果集缓存：对于复杂的SQL，可能消耗数据库服务器很多资源，这类SQL的结果集由
中间件缓存下来，对应用透明，会是一个很好的改进，但查询结果集的缓存远比K-V缓存 复杂，实现有难度
5
分布式数据库选型要点
• 支持MySQL，MySQL是目前是使用最为广泛的开源数据库的先锋，由于分布式数 据库往往要部署几十个数据库实例，因此采用商业版本数据库代价太大，而其他 开源数据库的接受程度则没有MySQL广泛 • 支持基于数据库实例而非Database的连接池共享机制，对于一个表分片为30个物 理表的情况，则一次跨分片查询需要同时占用30个后端数据库连接，100并发就 是3000个，因此特性很关键 • 支持分布式事务XA，虽然我们建议尽量避免跨分片事务，但个别场景仍然需要， 因此必须要支持分布式XA事务 • 分片规则支持自定义，很多时候，应用需要根据不同的表的数据模式和访问模式 来制定最优的分片规则。 • 支持负载均衡，避免单点故障 • 支持弹性动态扩展，增加数据库节点或扩容分片表 • 支持读写分离 • 支持服务端的分片SQL基本汇聚功能，如Count，SUM，Group ，Order，Limit等 • 具备基本的管理监控子系统
几乎可以用于任何企业 应用的开发
用户可以自主选择： 使用开源的数据库 成本很低，包括硬 件要求。使用商业 版本则性能和容量 方面可以超越开源 的。 较高
内存 数据 库 NoSQ L
较成熟
支持的SQL有限制， API有特殊性，系统对 硬件通常有特殊要求 不支持事务 范围查询是瓶颈 周边工具少 对运维有一定要求 具有NoSQL的缺点，另 外数据通常不会持久化
• 分片与分区：分片与分区结合使用，使得单分片的可接受容量最大化， 结合合适的数据库索引，提升SQL性能
• 监控：做好系统监控和运维工作，分布式情况下，节点出现故障的概率 增大，要及时修复，避免系统无法服务。
7
MySQL分布式数据库的开源项目
项目 fabric Amoeba 历史 <1 年 6年 成熟度 不成熟 较成熟 案例 少 中等 社区活跃度 高 低 特性 客户端模式，客户端Driver中 实现分片功能 中间件方式，模拟MySQL Server,实现分片和数据库主 从切换
• 初步估计，11台高性能X86服务器，每个存储为10T磁盘，万兆交换机， 可以实现1000亿单表分片规模数据支持（每个机器分片400个，每个分 片1000万数据。
10
建议采纳基于MyCAT的分布式数据库架构架构
客户端程序
MyCAT Server
MySQL 实例群组
11
MyCAT分布、集群和高可用方案
13
基于MyCAT的分布式数据库服务架构
分布式数据库能力架构
App 1
分布式数据库管控功能
App2
App3
数据库订购服务
多租户管理 MyCAT 集群 MyCAT配臵管 理
MyCAT监控 MySQL监控
14
MySQL Pool
一些实时性要求很高的 系统 使用Key-Value模型来访 问数据的，对存储和事 务要求不高的系统 某些数据访问很频繁， 而变动很少的场景
不 通 用 较 通 用 较 通 用 较 通 用
较成熟
数据模型简单，通常为 Key-Value模式，基于键 值的操作非常快，通常具 备分布式能力 利用内存来做数据缓存， 可以集中或分布式缓存， 访问性能很高
数据存储的分类与对比
类 型
传统 关系 数据 库
成熟 度
很成熟
特点
缺点
适用场景
通 用 性
很 通 用
使用成本
从几千到几千万的记录规 模都能存储，支持事务， 周边开发语言、框架和平 台都有完毕的支持，是企 业应用必不可少的基础设 施之一 千万级以上的记录规模
存在并发性和实时性的 瓶颈、数据规模达到一 定程度，则系统响应能 力明显下降，难以平滑 扩容
客户端
Select * from a where cola=‘xxx’ Hash(cola)
Db1.A (物理表) 分片规则 Db2.A (物理表) Db3.A (物理表) server1 路由模块 Db1.A (物理表) Db2.A (物理表) Db3.A (物理表) server2
Table A (逻辑表)
SQL解析
对于跨分片的查询SQL，则还要合 并结果集并返回客户端
4
分布式数据库的几个热点和难点问题，及解决思路
• 分布式事务：目前理想做法是用数据库本身的XA分布式事务的能力，将涉及到的分片
上的 操作纳入到全局事务中，两阶段提交，但XA两阶段提交遇到意外情况导致失败后， 数据的修复和回滚可能存在操作上的困难，特别是在主从复制的模型下，因此，实际上建 议的是程序业务中的补偿机制，即将失败的SQL重新再执行或者撤销，由业务逻辑控制
低
分布式数据库的两种主要模型
客户端（Driver）模式：改 造数据库的驱动，分片分 表等在客户端实现
中间件（Proxy）模式： 实现某个数据的通信协议，模拟为 Server，将客户端的SQL发往后端 具体的数据库，实现分片分表
2
客户端模式Or中间件模式
客户端模式：面向开发人员，因此从运维角度来看，缺乏透明度，数据
• 读写分离：分布式数据库中，读写分离是一个基本需求点，一般做法是由客户端指定某
个查询语句是否进行读写分离，然后数据库中间件根据指令将符合条件的查询SQL发到后 端从节点上执行，前提条件是后端数据库做了主从同步复制机制关于读写分离过程中的数 据时延问题，这个目前没有很好的办法，只能是监控主从同步的时延，忍受一个预定义的 延迟时间阀值，超过阀值，则不走从节点，对于持续大量写入数据的表来说，基本上延迟 始终有，因此程序端需要判断，哪些表的查询可以走从节点
排查等任务比较复杂，由于少了中间环节，因此SQL时延最低
中间件模式：模拟一个数据库Server，因此对于使用者来说就好象一个
真实的数据库服务器，运维和数据排查比较容易，管理调整方便，并且可以 搭建集群，增加吞吐量，另外中间件模式可以实现更多高级功能，比如后端 数据库资源共享、数据缓存、SQL拦截等保护机制，从整个平台的角度来看， 整体收益要更好，但因为存在一个中间环节，因此带来SQL时延和一定的单 机性能损耗，经测评，这个损耗在5%-10%之间，基本感知不到。
水平分表 分表规则 后端连接池复用 读写分离 存储过程 数据集合并 支持 Hash分片 只能Database级别 不支持 不支持 不支持（select count(*)会返回N条记录，N为表的分片个 数 支持 Hash分片、范围分片、ER分片 实现Mysql实例级别最大复用 支持 支持 支持，count,sum,group by ,以及order by limit等
• 跨分片JOIN：若表A在分片host1主机的1，2，3上，B在host2的1，2，3上，则为了完成
A与B的JOIN查询，需要搬迁大量数据到本地，进行编程JOIN，无论是时间消耗还是算法 的的复杂度都很高，除了能支持很有限的SQL之外，通常这个处理也很难满足实时性要求。 因此，避免跨分片JOIN，成了分片设计的第一原则
9
MyCAT公开的性能报告
• 相对直连MySQL，程序连接MyCAT后的性能为85-95%左右 • 多个分片在多个独立的物理机上，总体吞吐性能接近N倍，即单台 MYSQL插入的TPS为1万，则5台机器的MYSQL分片集群，TPS接近5万 （同时5台机器都插入数据）
• 目前测试过的最大分片表的数据为150亿，5台X86服务器，单表分片 1000万，共计1000个分片，一万个网关同时插入数据，吞吐量为2000条/ 秒，20个用户并发查询1万条记录的时间为1.4s左右（含Web展现），完 全符合预计。
8
开源项目MyCAT与Cobar的对比
Cobar是目前已知的MySQL分表分片功能做的最好的一个，阿里内部大量使用过， 其稳定性和功能经过考验，业界也有广泛使用，但后来不再开源，转向RDS收费产 品 Cobar的最终开源版本存在一些深层次的问题，包括数据汇聚、分页等都未能实现， 更深层的问题有后端连接的复用问题、阻塞IO导致系统假死和无法支撑更大规模 Mysql实例等 MyCAT则是深入研究和分析了Cobar的优缺点以后，针对Cobar的问题作了很多优化， 并且考虑了传统业务中关系模型的问题，创新的实现了ER关系分片，以及设计了 全局表，用于解决跨节点JOIN的难题 目前MyCAT社区有很多用户和开发者，来自不同的公司，持续改进和发展，很活跃， 这也是其他几个类似的开源项目所不具备的优势。 功能项 Cobar MyCAT
HA Proxy做负载均衡
后端MySQL可以主从搭配，故障自动切换
多台MyCAT Server可以同时工作
12
MyCAT的分片规则
• Hash分片：数据均匀分片在N个后端节点上，优点是数据按主键 操作的时候，没有热点问题，缺点是安装范围查询往往会产生跨 节点的请求，资源占用多，性能低，另外，分片范围调整和扩容， 都比较困难，比较适合类似枚举字段的分片，比如固定的省份分 片。 • 范围分片：可以根据时间范围和整数范围分片，连续的数据存放 在同一个节点上，是建议的一种分片方式，这种方式，分片范围 容易根据业务数据规模进行调整，比如开始是3个分片，当数据量 增加，响应变慢，再分裂和增加新分片，为了避免热点问题，可 以是不同的表交叉搭配，使得总体上各个MySQL分片的访问都比 较均匀 • ER关系分片：遵循关系数据库的ER设计，从表的记录跟随主表放 在同一个分片上，这样的好处是，每个分片都可以在数据库层面 完成JOIN，然后MyCAT可以合并各个分片的JOIN结果，这样就 实现了最高效的JOIN结果，对于一些业务来说很有用处。
在平台+应用的分布式云应用环境下，从业务与技术分离、 降低应用技术门槛、管控等角度看，‚中间件模式‛更符 合我们的能力目标。
3
分布式数据库的核心：数据分片和路由
将一个单表拆分为多个数据库服务器上的多个小表这种数据分片思想，实现千万级 别甚至100亿级别的‚大表‛，通过数据路由以及并行算法，来避免数据规模膨胀导 致的性能问题。
Cobar
2年
成熟
多
（已经关闭） 从Amoeba改造而来，大范围 部署使用，稳定性各方面比 较好
很活跃 Cobar被阿里放弃之后，在 Cobar源码上修复缺陷和引Biblioteka Baidu 新特性
MyCAT
1年
成熟
多
Cobar被放弃继续发展的一个重要原因是阿里推广其收费云服务RDS,RDS的代 码则来自Cobar和TDDL（后者从未公开核心代码，并且与Cobar有关