大数据量解决方案

Mysql大数据量解决方案

由于关系型数据库大多采用 B+ 树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降。

下文主要产品对比：

1. Mycat；

2. ShardingSphere；

3. TiDB；

4. OceanBase。

常见关系型数据库大数据量解决方案：

方案一：分库分表

分库的含义是根据业务需要，将原库拆分成多个库，通过降低单库大小来提高单库的性能。常见分库方式为垂直分库和水平分库。

• 垂直分库：根据业务进行划分，将同一类业务相关的数据表划分在同一个库中。 比如订单和用户这两类业务可以拆分为两个库。

• 水平分库：按照一定规则对数据库进行划分，每个数据库中各个表结构相同，比如按年份划分。也可按数据主键范围划分。

分表的含义是根据业务需要，将大表拆分成多个子表，通过降低单表的大小来提高单表的性能。常见分表方式为垂直分表和水平分表。

• 垂直分表就是将一个大表根据业务功能拆分成多个表，例如原表根据业务拆分成基本信息表和详细信息表。

• 水平分表是按照一定的规则对数据表进行划分。每个数据表结构相同，数据存储在多个分表中。比如按照手机最后一位取模。

分库分表后可做读写分离，解决的是数据库的写入影响查询的效率。

分库分表优点：

1. 解决数据库瓶颈。

2. 解决连接数过多问题。

3. 分表可解决单表数据量大查询性能问题。

4. 分库可解决单条数据库并发访问压力问题。

5. 解决系统本身IO、CPU瓶颈。

分库分表缺点：

1. 跨节点数据库join问题。

2. 分布式事物问题。

3. 数据排序计算问题。

4. 分布式主键问题。

5. 数据倾斜导致数据二次扩容问题。

Mycat

Mycat是一个开源的分库分表组件，隐藏了分库分表的细节，代码中引入Mycat进行分库分表，无须修改业务代码，只需要修改JDBC连接即可实现项目的升级。

Mycat1.x

Mycat社区开发了另一款分布式关系型数据库中间件Mycat2，相比较于Mycat1.x 支持的功能更多。

Mycat1.x与Mycat2功能对比链接 ：https://www.yuque.com/ccazhw/ml3nkf/vm9gru

Sharding-Sphere

Sharding-JDBC版本演进：

ShardingSphere支持无中心模式与中心代理模式两种模式

• 无中心模式：由ShardingSphere的前身Sharding-JDBC发展而来，ShardingSphere-JDBC 定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。
  它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

• 中心代理模式：代理模式与Mycat架构相同，都是在业务层与数据层间，插入一个透明的数据库代理层Proxy。Proxy就是封装了数据库二进制协议的 服务端版本，支持多语言连接。从客户端来看，Proxy中间层代理就是数据库服务器。

相比于无中心模式，代理模式支持多种语言的客户端，侵入性低。因为数据连接集中管理，可以有效减少jdbc连接数。配置中心化，管理更方便。缺点是在原有的网络传输中增加了代理层，牺牲了部分系统性能。

简单总结：Mycat以代理的形式提供数据库服务，对应用程序完全透明。Sharding-JDBC采用在JDBC协议层扩展分库分表，是一个以jar 形式提供服务的轻量级组件。

方案二：分布式数据库

分布式数据库NewSQL 是介于关系型数据库与 NoSQL 数据库之间的数据库，论性能比关系型数据库好，论数据一致性比NoSQL数据库好。

TiDB数据库是众多NewSQL数据库中比较主流的一款。截止2022/10/16，TiDB github上面高达32.6k 星。

TiDB

TiDB数据库最大的特点是兼容了Mysql数据库，所有采用Mysql数据库的应用系统，可以无缝地切换为TiDB数据库。

TiDB集群主要包括3个核心组件：

• TiDB Server：负责接收sql请求，处理sql相关逻辑，并通过PD找到存储计算所需数据的Tikv地址。（无状态，不提供存储，只负责计算）

• PD Server：只负责位置信息，一个是存储元数据信息，一个是对存储集群Tikv进行调度和负载均衡。

• Tikv Server：存储系统，其对外提供分布式的、基于事务的key-value存储。数据以Region为单位进行分片，Region之间通过Raft协议保持一致性。 Tikv中数据会自动维护多副本（默认三副本），天然支持高可用和自动故障转移。

TiDB技术架构图：

最核心的是Tikv Server，存储的是k-v形式。在Tikv Server之上部署的是TiDB Server，它是外部应用系统的访问接口。 外部应用系统通过sql语句访问TiDB Server，TiDB Server再将sql语句转换成k-v操作指令，然后去操作底层的Tikv存储。

然后TiDB又将存储数据的具体节点的信息存储在PD Server中，这些信息就是元数据。有了这些元数据，系统在数据查询时，就可以先通过元数据精确定位数据在哪个节点上，然后再到那个节点获取数据。

TiDB在底层k-v存储的基础上增加了一个Raft一致性算法。

TiDB特性：

1. 高度兼容msyql。

2. 分布式事务。

3. 高可用，基于Raft一致性算法，自动恢复单点故障。

4. 同时支持OLTP和OLAP功能，并且提供云原生支持。

TiDB和传统的分库分表中间对比图：

OceanBase

OceanBase 数据库是一个金融级分布式关系数据库，提供社区版和企业版：

• OceanBase 数据库社区版包含 OceanBase 的所有核心功能，源代码完全公开，且使用免费。

• OceanBase 数据库企业版在 OceanBase 社区版的基础上，提供更多高级功能，如商业特性兼容、图形化管理工具、操作审计、安全加密、高可用扩展等。

发展历程：

系统架构：

OceanBase 数据库采用 Shared-Nothing 架构，各个节点之间完全对等，每个节点都有自己的 SQL 引擎、存储引擎，运行在普通PC服务器组成的集群之上，具备可扩展、高可用、高性能、低成本、云原生等核心特性。

OceanBase 数据库的一个集群由若干个节点组成。

在集群的每个节点上会运行一个叫做 OBServer 的服务进程，它内部包含多个操作系统线程。节点的功能都是对等的。 每个服务负责自己所在节点上分区数据的存取，也负责路由到本机的 SQL 语句的解析和执行。这些服务进程之间通过 TCP/IP 协议进行通信。 同时，每个服务会监听来自外部应用的连接请求，建立连接和数据库会话，并提供数据库服务。

OceanBase 数据库为了对应用程序屏蔽内部分区和副本分布等细节，提供了 obproxy 代理服务。应用程序并不会直接与 OBServer 建立连接，而是连接obproxy，然后由 obproxy 转发 SQL 请求到合适的 OBServer 节点。 obproxy 是无状态的服务，多个 obproxy 节点通过网络负载均衡（SLB）对应用提供统一的网络地址。

存储架构：

OceanBase将数据分为两部分，一部分是相对早些的数据（如一天前），另一部分是最近的更新数据。前者称为基准数据，后者称为增量数据。

在每天的业务低谷时，将增量数据合并到基准数据中，形成新的基准数据。基准数据被分片存储到多台机器上。

而增量数据的处理则只由一台机器完成。查询时将基准数据与增量数据合并，修改时只修改增量数据。如此一来，因为增量数据只由一台机器处理，所以绕开了分布式事务的难点。

 

产品对比图

参考资料

1. 《Spring5 企业级开发实战》

2. 《企业互联网架构原理与实践》

3. 《中台落地手记：业务服务化与数据资产化》

4. Tidb官网

5. Sharding-Sphere官网

6. OceanBase官网