【IT168 评论】1. 简介
RadonDB是?款基于MySQL研发的新?代分布式关系型数据库(MyNewSQL)。
向?户提供具备?融级?可?、强?致、超?容量的数据库服务，?度兼容MySQL语法，?动?平分表，智能化扩容。
2. RadonDB的优势
?动?平分表，?键即可开启智能化扩容，扩容过程业务不中断 数据多副本并可跨数据中?部署，率先使?GTID并?复制+Raft?致性协议确保副本间数据强?致、零丢失 主副本故障?动秒级切换，实现?动化运维，?需???预 存储副本使?MySQL(5.7.19)存储，稳定可靠的存储能?与强?的计算能?并存 提供分布式事务能?，保证跨节点操作的数据?致性 同时?持OLTP(?并发事务需求)和OLAP(复杂分析需求) ?度兼容MySQL语法，数据可快速导?、导出，简单易?
3. 架构
RadonDB由SQL节点(Distributed SQL Nodes)和存储节点(Storage Nodes)以及计算节点(Compute Nodes)三?部分组成。
整体架构如下：
3.1 SQL节点
SQL节点主要负责:
?成分布式执?计划(Distributed Plan) ?成分布式执?器(Distributed Executor)且并?式执? 协调分布式事务
对于?户的每?个query，到达?个SQL节点后，处理流程如下：
SQL节点是?状态的，但是为了保证事务的Snapshot Isolation隔离性，?前是?写多读模式。
3.2 存储节点
RadonDB整个存储层由多个存储节点组成。
每个存储节点默认是由?主两从(三副本)的?可?MySQL集群组成，负责分区数据的存储与计算。
3.2.1 副本基于MySQL存储
为什么选择MySQL进?副本存储呢?
我们的考量是:
MySQL稳定可靠、多索引写原?保证 储存可以异构化，InnoDB/TokuDB多引擎可选 尽量把计算下推给MySQL，充分发挥数据就近(Data Locality)优势，以减少存储层与SQL层数据传输 MySQL 8.0即将推出，功能更加强?
3.2.2 副本?可?、强?致
为了保证节点内副本的?可?，我们把MySQL GTID并?复制技术与分布式?致性协议Raft完美结合，在主副本故障后?动秒级切换 并瞬间可?，并确保切换后数据零丢失。
在RadonDB?，我们把GTID(Global Transaction Identifier)作为Raft协议的log index，结合MySQL的Multi-Threaded Slave (MTS)， 可以做到log entry的并?复制、并?回放，log重放时间异常短暂，故障切换后即刻对外服务。
同时，RadonDB使?强Semi-Sync-Replication技术确保?少?个从副本与主副本在数据上是完全同步的，当主副本故障后，数据完 全同步的从副本将被选为新的主副本，这样就确保了数据零丢失，并实现了?可?。
?如，某个存储节点的三副本状态为:
这样当Master(主副本)不可服务的时候，Slave1(从副本)将被选为新主，Slave2?动’CHANGE MASTER TO’到新主Slave1并根据 GTID(4和5)进?数据同步，切换后状态为:
当某个副本不可?被判定为损坏时，RadonDB则开启流式重建(streaming-rebuildme)机制，对该副本进?快速重建，以保证?够多的 副本可?。
3.3 数据分布
RadonDB对数据的划分最?单元是?个“?表”。
划分策略为(默认):
整张表共 4096 slots 每个?表 128 slots
这?的4096和128均可配置，默认可?持单表最?4PB的容量(假设物理盘最?1TB)。
如果我们在RadonDB?创建?个表t1，数据分布情况为:
可以看到，表t1被划分成32个?表，它们均匀的分散在多个存储节点上。
每个?表都有?个??的哈希区间，?于标识??所能存储的HASH范围。
3.4 动态扩容
为了减少扩容数据迁移量，RadonDB优先以?表为单位进?迁移。
RadonDB定期的采集存储节点资源使?情况(CPU/Disk/表热度等)，在扩容的时候会优先选择这些空间紧张且热度较?的?表为迁移 对象，使得整体资源分配达到最优。
扩容时，?先进?全量迁移(并发式)，然后根据全量时的位点进?增量同步，如果业务写?较?，数据差异量?直呈加?趋势， RadonDB会启动动态限流机制以加快增量迁移。
迁移完毕，RadonDB会对表数据并发式做Checksum校验，严格保证迁移前后数据的正确性，根据我们的测试(RDB虚机环境)， Checksum速率可以达到300MB/s，所以对这些?表来说还是?常快的。
添加新存储节点后数据分布情况:
3.5 分布式事务
为什么需要分布式事务能?呢?
我们通过?个例?来说明分布式事务的重要性，?如?户执?了?个区间update操作:
Distributed Executor在不同存储节点执?情况为:
这?，node2的执?器执?失败，其他2个执?成功，如果没有分布式事务保证，整个表其实是处于?种不?致、甚?数据不可?状 态。
RadonDB提供了分布式事务能?，node1和node3的操作将被回滚(ROLLBACK)，这样就保证了跨节点操作原?性，使数据库处于? 个?致性状态。
3.6 数据?致性
那么，RadonDB?持什么级别的?致性呢?
我们先来看?个场景，对于2个不同的client操作，?个为区间读，?个为区间更新，?如：
假设表t1.a初始值全部为0，如果没有分布式事务保证, client1的查询结果集可能是:
因为client1的查询读到了client2的更新数据(部分)。
在RadonDB?，这种情况是不存在的，client1的返回结果集有2种。
全部为1 这种情况发?在client2-update完成后client1-select再执?:
全部为0
client1-select的开始(START)在client2-update完成(COMMIT)之前：
RadonDB在?致性上做到了SI(Snapshot Isolation)级别，只要某个分布式事务没有commit，或部分区已经commit，那么它的操作对 其他事务都是不可?的。
我们使?go-jepsen进?SI测试，经过100多亿次操作并检测，并在检测期间随机kill存储节点主副本，均未发现问题。
go-jepsen是?个验证SI隔离级别的?具，它的原理?较容易理解:
1个线程不停的更新(update)整张表，16个读线程不停的扫表(scan)，然后对读到的数据进?等值校验，如果这批数据有差异，说明 读到了update的脏数据，是不满?SI的。
4. 复杂查询
对于跨节点join等复杂查询(偏OLAP查询)，如果放到SQL层实现，这样的问题有:
SQL层与存储层?络传输较?，因为数据要在SQL层进?计算和过滤，导致性能低下或不可? 复杂查询会抢占OLTP资源，互相?扰?造成抖动
出于以上考虑，RadonDB对于复杂的OLAP类查询，SQL层会?动路由到单独的计算节点进?计算并返回，OLAP和OLTP资源完全隔 离，互不影响，?户在使?时?感知。
这样的缺点是数据需要2份，?前通过?压缩解决。
5. 性能
5.1 硬件环境:
5.2 测试模型
sysbench: 16表, 512线程，随机写，5000万条数据
5.3 测试结果
可以看到RadonDB的延迟是单机MySQL的1/3，但性能?乎是单机的3倍，这要得益于RadonDB对?表进?切分后，?户的写操作 在这些?表上可并发式执?。
6. 数据导?和导出
RadonDB?前只?持go-mydumper?式的数据导?和导出。
XeLabs/go-mydumper使?go语?开发，与maxbube/mydumper格式完全兼容，但是对并?进?了优化，性能更加卓越。
导?数据到RadonDB，go-mydumper会批量并?式导?，?常快捷。
从RadonDB导出数据时，go-mydumper会批量并?流式导出，资源占?率较低。
6.1 安装go-mydumper
6.2. 如何导?数据到RadonDB
6.2.1 从数据源导出数据
?先使?mydumper从别的MySQL数据源导出数据，?如:
6.2.2 修改schema
在导出?录(?如sbtest.sql)?找到*-schema.sql(?如sbtest.benchyou0-scehma.sql):
对原语句最后增加’PARTITION BY HASH(分区键)’的语法:
sbtest.benchyou0-schema.sql:
修改为(这?是以id为分区键):
6.2.3 导?数据到RadonDB
6.4 如何导出RadonDB数据
可以使?mydumper导出RadonDB数据，此过程是流式获取(select语句加’/*backup*/’ hint)并导出，基本不占?系统内存。
7. 总结
RadonDB是?个基于MySQL?实现的?可?、强?致的分布式数据库。
RadonDB具备双层计算能?，SQL节点提供基本的计算能?(结果集的?次运算)，?存储层由于使?MySQL则具备强?的存储计算 能?。
对于?户的每?个query，RadonDB都尽可能的把计算下推，让存储层MySQL过滤掉更多的数据，以减少SQL层和存储层之间的?络 传输，充分利?data locality优势，发挥非常好的性能。
我们认为基于MySQL的分布式数据库(MyNewSQL)远未到头，RadonDB只是?个开始。
