分布式数据库（ShardingSphere）

单库单表数据量过大导致的问题与应对

传统的将数据集中存储至单一数据节点的解决方案，在容量、性能、可用性和运维成本这三方面

已经难于满足互联网的海量数据场景。我们在单库单表数据量超过一定容量水位的情况下，索引

树层级增加，磁盘 IO 也很可能出现压力，会导致很多问题。

从性能方面来说，由于关系型数据库大多采用 B+树类型的索引，在数据量超过阈值的情况下，索

引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降；同时， 高并发访问

请求也使得集中式数据库成为系统的最大瓶颈。

从可用性的方面来讲，服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最

终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数

据库的可用性，已成为整个系统的关键。

从运维成本方面考虑，当一个数据库实例中的数据达到阈值以上，对于 DBA 的运维压力就会增大。

数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例的

数据的阈值在 1TB 之内，是比较合理的范围。

MySQL 单表一般可以存多少数据

MySQL 常用的 InnoDB 引擎（支持事务，有行级锁），使用的 B+树的索引结构， InnoDB 存储引擎的最小存储单元是页，页可以用于存放数据也可以用于存放键值 + 指针， 在 B+ 树中叶子节点存放数据，非叶子节点存放键值 + 指针。索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中，进而在去数据页中查找到需要的数据。为了跟磁盘 io 的交互次数 2-3 次就能找到一条记录，我们假设树不超过 3 层。假设一行数据的大小是 1k，那么一个页（innodbpagesize 一般为 16k）可以存放 16 行这样的数据。

我们假设主键 ID 为 bigint 类型，长度为 8 字节，而指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节，我们一个页中能存放多少这样的单元，其实就代表有多少指针，即 16384/14=1170。

那么可以算出一棵高度为 2 的 B+ 树，能存放 1170*16=18720 条这样的数据记录。

根据同样的原理我们可以算出一个高度为 3 的 B+ 树可以存放：1170 x 1170 x 16=21902400 （两千万）条这样的记录。

MySQL 5.7 (PARTITION-分表的思想)

分区是把数据库、或它的组成部分(比如表)分成几个小部分。而且专门介绍的都是’水平分区’，即对表的行进行划分。

分区的优点：

1. 可以提高数据库的性能；

2. 对大表(行较多)的维护更快、更容易，因为数据分布在不同的逻辑文件上；

3. 删除分区或它的数据是容易的，因为它不影响其他表。

缺点：

不能解决单节点数据库容量的压力

分布式数据库

1、垂直分片：

垂直拆分（拆库）：例如拆分所有订单的数据和产品的数据，变成两个独立的库。

垂直拆分（拆表）：如果单表数据量过大，还可能需要对单表进行拆分。比如一个200 列的订单主表，拆分成十几个子表：订单表、订单详情表、订单收件信息表、订单支付表、订单产品快照表等等。

2、水平分片：

水平拆分（按主键分库分表）：水平拆分就是直接对数据进行分片，有分库和分表两个具体方式，但是都只是降低单个节点数据量，但不改变数据本身的结构。

水平拆分（按时间分库分表）：很多时候，我们的数据是有时间属性的，所以自然可以按照时间维度来拆分。比如当前数据表和历史数据表，甚至按季度，按月，按天来划分不同的表。

Apache ShardingSphere

Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。 它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。

ShardingSphere-JDBC

定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

• 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。

• 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。

• 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 标准的数据库。

ShardingSphere-Proxy

定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端(如：MySQL Command Client, MySQL Workbench, Navicat 等)操作数据，对 DBA 更加友好。

向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用。

适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。

ShardingSphere-Sidecar

定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问。 通

过无中心、零侵入的方案提供与数据库交互的啮合层，即 Database Mesh，又可称数据库网格。

Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互进行有效地梳理。 使用 Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。

ShardingSphere-混合架构

比较