一、背景介绍1、分布式数据库架构目前分布式数据库的架构有很多种，但总体架构差别不大。主要组件包括协调节点、数据分片、元数据节点和全局时钟。一种常见的分布式架构如下：gtm：全局事务管理器（全局时钟），一主多备；catalog：元数据管理，一主多备；group：水平分片，每个group由一个master和多个backup的数据存储节点组成；proxy：协调节点，无状态，负责处理客户端请求，根据分片规则向数据分片发送请求，汇总数据分片返回的数据，与其他组件协同保证分布式事务的一致性。2.排序问题排序也是分布式数据库中的一个重要功能。一条查询排序语句select*fromt1orderbyfield1，查询的数据可能分布在不同的数据分片中。这就需要代理对不同数据分片返回的有序数据进行重新排序，然后将全局有序的数据返回给客户端。当相关数据量不大时，代理可以将不同数据分片返回的数据存储在内存中，然后将内存中的数据重新排序返回给客户端。当相关数据量比较大的时候，如果要重新排序的数据放在内存中，可能会造成OOM。如果需要重排的数据暂时存放在proxy的磁盘中，同样存在磁盘耗尽的风险，会出现大量的DiskI/O。下面将介绍一种分布式数据库排序和优化方法。二、解决方案1、排序方案介绍为了提高分布式排序的性能，每个数据分片本身也参与排序。这样proxy上的分片返回的数据是有序的，proxy可以使用归并排序或者优先队列排序的方式对有序的数据进行重新排序，大大减轻了proxy的压力。排序缓冲区大小可以根据代理内存大小进行配置，通常默认为10M。如果一条查询语句关联了N个数据分片，则需要将排序缓冲区分成N个部分，每个数据分片对应一个大小为10M/N的排序缓冲区。直接在内存中进行，具体步骤如下：客户端向代理发送排序查询语句select*fromt1orderbyid。Proxy根据分片键和分片规则，向相关数据分片group1和group2发送排序查询语句select*fromt1orderbyid。数据分片在本地查询和排序数据，然后将排序后的数据发送给代理。Proxy将数据分片返回的有序数据存储在数据分片对应的排序缓冲区中，并对有序数据进行合并排序。代理将合并和排序后的数据发送给客户端。2.排序方案的缺陷这种方法只能对少量数据进行排序。当排序的数据量很大时，我们可以选择增加代理上的排序缓冲区。但是，增加排序缓冲区的大小会占用更多的内存资源，因此排序缓冲区的大小不能无限制地增加。3.排序优化的思路是将数据分片返回的有序数据保存到磁盘中，然后对磁盘数据进行重新排序。下面将介绍一种优化方案，一种针对大量数据进行分布式排序的方法。三、优化方案1、排序方案介绍由于内存限制，在内存中对大量数据进行归并排序是不可行的。在这种情况下，需要将数据分片返回的数据暂存在磁盘中。优化方案的具体步骤如下：(1)客户端向代理发送排序查询语句select*fromt1orderbyid。(2)proxy根据分片key向相关数据分片group1和group2发送排序查询语句select*fromt1orderbyid。(3)数据分片在本地查询和排序数据，然后将排序后的数据发送给代理。(4)代理将数据分片返回的有序数据存储在数据分片对应的磁盘文件中。(5)采用优先队列排序的方法进行重排序：每个数据分片生成一个数据构造堆，堆中包含的节点数等于数据分片数。为了避免在优先级队列排序过程中，从磁盘中逐条读取数据带来的性能问题，proxy从磁盘文件中读取数据，并预先填充到数据分片对应的排序缓冲区中。从每个分片的排序缓冲区中生成一条数据，形成一个堆。从堆顶弹出数据并将其发送给客户端。堆顶数据出栈后，再从出栈节点对应的sortbuffer中读取另一条数据入栈。分片排序缓冲区中的数据取出后，还需要继续从相应的磁盘文件中取出数据填充排序缓冲区。直到所有数据都被获取并发送到客户端。2、分选方案的缺陷。代理需要收集所有相关的数据碎片，并将有序的数据存储在磁盘上，以解决内存不足的问题，但磁盘也是有限的。当数据量过大时，代理上的磁盘可能无法容纳需要排序的数据。数据。数据存储在proxy上的磁盘上，存在大量的磁盘IO。以select*fromt1orderbyfield1limit100w为例：如果本次查询的数据在50个数据分片上，代理节点需要从每个数据分片中拉取100w条数据存盘。这样一来需要保存5000W条数据（100w*50），而客户端只需要100w条数据，浪费了大量的网络带宽和磁盘IO。3.排序优化思路这种方式是proxy把相关数据分片的所有有序数据拉到proxy，然后进行排序。是不是批量从数据分片中拉取数据，批量处理完数据后再从数据分片中拉取下一批数据？下面介绍一种批量排序的方法。四、最终方案1、排序方案介绍proxy上的磁盘不保存数据分片数据，一次从数据分片中拉取固定大小的有序数据，proxy将拉取的数据填充到sortbuffer中对应分片，sortbuffer中的数据用完后，再次从对应的datashard中拉取。具体步骤如下：(1)客户端向代理发送排序查询语句select*fromt1orderbyid。(2)proxy根据分片key向相关数据分片group1和group2发送排序查询语句select*fromt1orderbyid。(3)数据分片在本地对数据进行查询排序后，将固定大小的有序数据发送给proxy。(4)代理将数据切片返回的有序数据存储在数据切片对应的排序缓冲区中。(5)优先队列排序：每个数据分片对应的排序缓冲区创建一个数据堆，堆的节点数等于数据分片数；从堆顶弹出数据并发送给客户端；top数据弹出后，从弹出节点对应的sortbuffer中读取一段数据入栈；分片排序缓冲区中的数据取完后，需要继续从相应的数据分片节点中拉取数据填充排序缓冲区；untilFetch所有数据并发送给客户端。2.排序方案分析优化方案3.2中三个缺陷的解决方案：(1)缺陷1：proxy需要将相关数据分片的所有有序数据收集起来存入磁盘，解决内存不足的问题，但是磁盘也是有限的，当数据量太大时，proxy上的磁盘可能无法容纳需要排序的数据。解决方法：从图中可以看出，代理盘没有保存数据分片的数据。(2)缺陷2：数据存储在proxy上的磁盘上，存在大量的磁盘IO。解决方法：proxy的磁盘不保存dataslice的数据，所以不存在磁盘压力过大的问题。(3)缺陷3：以select*fromt1orderbyfield1limit100w为例：如果本次查询的数据在50个数据分片上，代理节点需要从每个数据分片中拉取100w条数据存盘，需要保存5000W条数据（100w*50），但是客户端只需要100w条数据，浪费了大量的网络带宽和磁盘IO。解决方案：每次从数据分片中拉取固定大小的数据，边排序边返回给客户端。当返回给客户端的数据达到100W时，查询就完成了，大大改善了网络带宽的浪费。假设proxy上dataslice对应的sortbuffer大小为2M，从dataslice拉取数据量：最坏情况：拉取数据量为2M*50+100W，不需要保存磁盘。最好的情况：数据分布非常均匀。向客户端返回100w数据后，所有sortbuffer分片对应的数据刚好基本为空（只剩一个），此时拉取数据量为100W+50。3.方案使用限制(1)数据分片节点本身支持排序，大部分数据分片都支持排序。(2)数据分片需要支持批量读取。以MySQL为例，数据分片，流式查询或游标查询需要在代理上可用。此外，一些分布式数据库在设计时考虑了一些分布式问题。它们的数据分片节点一直保持上下文直到查询结束，它们的批量读取性能更高，这里就不举例了。
