总结主流的分布式数据库解决方案

随着公司的产品和用户规模的上涨，随之而来的便是数据量的剧增。随之而来的便是数据库数据量上升读写性能严重下降。解决该问题有三个方面：1.增大磁盘 2.数据压缩 3.数据分片。
增大磁盘:会带来运维和数据备份和恢复等问题，无法解决吞吐量下降的问题
数据压缩：对性能下降严重，如果数据规模较大效果不明显
数据分片：我们可以借助分库分表中间件，比如mycat、shardingjdbc来实现分库分表，缓解单库的读写性能。但是分库分表中间件并不支持事务，如果要保证数据一致性，就需要借助于分布式事务中间件，比如阿里巴巴的seata。后来分布式数据库逐渐成为解决数据一致性的选择，目前分布式数据库产品已经比较成熟，支持ACID事务。
本文就来聊一聊分布式数据库。

如何拆分

Mysql 的 B+树索引存储在磁盘上，Mysql 每次读取磁盘 Page 的大小是 16KB，为了保证每次查询的效率，需要保证每次查询访问磁盘的次数，一般设计为 2-3 次磁盘访问，再多性能将严重不足。Mysql B+树索引的每个节点需要存储一个指针（8Byte）和一个键值（8Byte）。因此计算16KB/(8B+8B)=1K 16KB 可以存储 1K 个节点，3 次磁盘访问(即 B+树 3 的深度)可以存储 1K * 1K * 1K 即 10 亿数据，如果查询依赖非主键索引，那么还涉及二级索引。这样数据量将更小。
分而治之——没有什么问题不能通过拆分一次来解决，不行就拆多次
Mysql 单表存储的数据量有限。一个解决大数据量存储的办法就是分库分表。说白了就是一个数据库一张表放不下那么多数据，那就分多个数据库多张表存储。

拆分可分为垂直拆分和水平拆分
垂直拆分是按照不同的表（或者 Schema）来切分到不同的数据库（主机）之上，水平拆分则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面或多张相同 Schema 的不同表中。

垂直拆分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。

水平拆分与垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。

垂直拆分最直接的就是按领域拆分服务，隔离领域数据库。如此每个库所承担的数据压力就减少了。

水平拆分就是将同一个 Schema 的数据拆分到不同的库或不同的表中，这样每个表的数据量也将减小，查询效率将更高效。水平拆分就涉及到表的分片规则问题。

几种典型的分片规则包括：

按照用户 ID 求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中。
按照日期，将不同月甚至日的数据分散到不同的库中。
按照某个特定的字段求摸，或者根据特定范围段分散到不同的库中。

如何实现

Mycat

关键特性

• 支持前端作为MySQL通用代理
• 后端JDBC方式支持Oracle,DB2,SQL Server,mongodb,巨杉
• 基于心跳的自动故障切换，支持读写分离
• 支持MySQL Cluster,Galera,Percona,cluster集群
• 支持数据的多片自动路由与聚合
• 支持sum,count,max等常用的聚合函数,支持跨库分页
• 支持库内分表,支持单库内部任意join全局表，支持跨库2表join
• 基于caltlet的多表join
• 支持通过全局表，ER关系的分片策略，实现了高效的多表join查询
• 支持多租户方案
• 支持弱XA,XA分布式事务
• 支持全局序列号，解决分布式下的主键生成问题
• 分片规则丰富，插件化开发，易于扩展
• 支持命令行监控,支持密码加密,支持IP白名单
• 支持SQL黑名单、sql注入攻击拦截
• 支持prepare预编译指令
• 支持非堆内存(Direct Memory)聚合计算
• 支持oracle存储过程，out参数
• 支持zookeeper协调主从切换、zk序列、配置zk化

ShardingSphere-JDBC/Proxy

数据分片

• 分库 & 分表
• 读写分离
• 分片策略定制化
• 无中心化分布式主键

分布式事务

• 标准化事务接口
• XA 强一致事务
• 柔性事务

数据库治理

• 分布式治理
• 弹性伸缩
• 可视化链路追踪
• 数据加密