一、背景

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