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

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

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

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

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

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

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

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

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

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）优先级队列排序。

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

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

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

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

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

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

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

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

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

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

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

作者丨vivo互联网服务器团队-Xia Qianyong