一、背景

1.1 分布式数据库架构

当前分布式数据库架构有不少，但是总体架构相差不大，主要组件都包含协调节点、数据分片、元数据节点、全局时钟。一种常见的分布式架构如下图：

• gtm ：全局事务管理器(全局时钟)，一主多备；

• catalog: 元数据管理，一主多备；

• group: 水平分片,每个 group 由一主多备数据存储节点组成；

• proxy : 协调节点，无状态，负责处理客户端的请求，把请求按照分片规则发送到数据分片，汇总数据分片返回的数据，协同其它组件保证分布式事务的一致性。

1.2 排序问题

分布式数据库中排序也是一种重要的功能。一条查询排序语句 select *from t1 order by field1，需要查询的数据可能会分布在不同的数据分片中。这就需要 proxy 对为不同数据分片返回的有序数据进行重排序，然后后给 client 返回全局有序的数据。

当相关的数据量不大时，proxy 可把不同数据分片返回的数据保存在内存中，然后对内存中的数据重排序后返回给 client。当相关的数据量比较大时，如果把待重排序数据放到内存中则可能会导致 OOM，如果把待重排序数据暂存在 proxy 的磁盘中，则也有耗尽磁盘的风险并且会存在大量的磁盘 IO。下面将介绍一种分布式数据库排序及优化方法。

二、解决方案

2.1 排序方案介绍

为了提高分布式排序的性能，每个数据分片本身也要参与排序。这样在 proxy 上得到分片返回的数据是有序的，proxy 对有序的数据重排序可以采用归并排序或者优先级队列排序方法，大大减轻 proxy 的压力。

可以根据 proxy 内存大小配置 sort buffer 大小，通常默认为 10M。如果一次查询语句关联 N 个数据分片，则需要到 sort buffer 按照 N 份进行切分，每个数据分片对应切分后的 sort buffer 大小为 10M/N。

直接在内存中进行，具体步骤如下图：

• client 向 proxy 下发排序查询语句 select *from t1 order by id。

• proxy 根据分片键以及分片规则向相关的数据分片 group1、group2 下发排序查询语句 select *from t1 order by id。

• 数据分片在本地对数据进行查询排序后，发送有序数据到 proxy。

• proxy 把数据分片返回的有序数据存储在数据分片对应的 sort buffer 中，并对有序数据进行归并排序。

• proxy 把归并排序好的数据发送给 client。

2.2 排序方案缺陷

这种方法只能满足小数据量排序，当排序的数据量较大我们可以选择调大 proxy 上的 sort buffer。但是调大 sort buffer 会占用更多的内存资源，所以不能无限制的调大 sort  buffer。

2.3 排序优化思路

把数据分片返回的有序数据保存到磁盘上，然后对磁盘数据进行重排序。下面将介绍一种优化方案，针对大数据量进行分布式排序的方法。

三、优化方案

3.1 排序方案介绍

由于内存的限制，在内存中对大数据量数据进行归并排序方案不可行，针对这种情况需要把数据分片返回的数据暂存在磁盘中。具体优化方案步骤如下图：

1）client 向 proxy 下发排序查询语句 select *from t1 order by id。

2）proxy 根据分片键向相关的数据分片 group1、group2 下发排序查询语句 select *from t1 order by id。

3）数据分片在本地对数据进行查询排序后，发送有序数据到 proxy。

4）proxy 把数据分片返回的有序数据存储在数据分片对应的磁盘文件中。

5）使用优先级队列排序方法进行重排序：

• 每个数据分片出一条数据构建堆，heap 包含的节点个数等于数据分片的个数。

• 为了避免优先级队列排序过程中从磁盘中逐条读取数据造成的性能问题，proxy 从磁盘文件中读取数据预填充到数据分片对应的 sort buffer。

• 每个分片的 sort buffer 出一条数据构造成一个 heap。

• 从堆顶弹出数据发送给 client。

• 堆顶数据弹出后，从已弹出节点对应的 sort buffer 再读取一条数据 push 到堆。

• 分片 sort buffer 中的数据取完后，需要继续从对应的磁盘文件中拉取数据，对 sort buffer 进行填充。

• 直至取完所有数据发送到 client。

3.2 排序方案缺陷

• proxy 需要收集完所有相关数据分片的有序数据存入磁盘可以解决内存不够的问题，但是磁盘也是有限的，当数据量太大在 proxy 上磁盘也可能无法容纳需要排序的数据。

  
  

• proxy 上把数据存在磁盘，存在大量的磁盘 IO。

  
  

• 以 select * from t1 order by field1 limit 100w 为例：如果本次查询的数据在 50 个数据分片上，则 proxy 节点需要从每个数据分片上拉取 100w 数据然后保存到磁盘上。这样需要保存 5000W 数据(100w*50)，而 client 只需要 100w 条数据，浪费了很多网络带宽和磁盘 IO。

3.3 排序优化思路

这种方法是 proxy 把相关数据分片的有序数据全部拉取到 proxy 上，然后再进行排序。我们是否分批从数据分片拉取数据，批量数据处理后再从数据分片拉取下一批数据呢？下面将介绍一种分批排序的方法。

四、最终方案

4.1 排序方案介绍

proxy 上磁盘上不保存数据分片数据，一次从数据分片拉取固定大小的有序数据，proxy 把拉取的数据填充到分片对应的 sort buffer，sort buffer 中数据使用完后再次从对应的数据分片上拉取。具体步骤如下图：

1）client 向 proxy 下发排序查询语句 select *from t1 order by id。

2）proxy 根据分片键向相关的数据分片 group1、group2 下发排序查询语句 select *from t1 order by id。

3）数据分片在本地对数据进行查询排序后，发送固定大小有序数据到 proxy。

4）proxy 把数据分片返回的有序数据存储在数据分片对应的 sort buffer 中。

5）优先级队列排序。

• 每个数据分片对应的 sort buffer 出一条数据构建堆，堆节点的个数等于数据分片的个数.

• 从堆顶弹出数据发送给 client.

• 堆顶数据弹出后，从已弹出节点对应的 sort buffer 再读取一条数据 push 到堆.

• 分片 sort buffer 中的数据取完后，需要继续从对应的数据分片节点中拉取数据，对 sort buffer 进行填充.

• 直至取完所有数据发送到 client.

4.2 排序方案分析

针对优化方案 3.2 存在的三个缺陷的解决情况。

缺陷 1：proxy 需要收集完所有相关数据分片的有序数据存入磁盘可以解决内存不够的问题，但是磁盘也是有限的，当数据量太大在 proxy 上磁盘也可能无法容纳需要排序的数据。

解决情况：从图中可以看出 proxy 的磁盘上不保存数据分片的数据。

缺陷 2 ：proxy 上把数据存在磁盘，存在大量的磁盘 IO。

解决情况：proxy 的磁盘上不保存数据分片的数据，所以不存在磁盘压力太大问题。

缺陷 3：select * from t1 order by field1 limit 100w 为例：如果本次查询的数据在 50 个数据分片上，则 proxy 节点需要从每个数据分片上拉取 100w 数据然后保存到磁盘上，需要保存 5000W 数据(100w*50)，而 client 只需要 100w 条数据，浪费了很多网络带宽和磁盘 IO。

解决情况：每次从数据分片拉取固定大小的数据，边排序边给客户端返回数据，当给客户端返回的数据达到 100W 时则完成本次查询，网络带宽浪费得到大大改善。

假设 proxy 上数据分片对应的 sort buffer 大小为 2M，从数据分片拉取的数据量：

• 最坏情况：拉取的数据量为 2M*50+100W，并且不需要保存磁盘。

• 最好情况：数据分布很均匀，给 client 返回 100w 数据后，所有 sort buffer 分片对应的数据正好基本取空(都剩下一条)，此时拉取的数据量为 100W+50。

4.3 方案使用限制

1）数据分片节点本身支持排序，绝大多数数据分片都是支持排序的。

2）数据分片需要支持分批读取。

以 MySQL 作为数据分片为例，则需要 proxy 上可以使用流式查询或者游标查询。另外有些分布式数据库在设计时就考虑到一些分布式的问题，它们数据分片节点在查询结束前一直保留上下文，它们的分批读取性能更高，这里就不在举例。

五、参考文献

1.JDBC操作MySQL（3）—查询

2.MySQL JDBC StreamResult通信原理浅析

作者：vivo 互联网数据库团队-Xia Qianyong