酷应用

遇见 RadonDB，实力诠释新一代关系型数据库

百家作者：QingCloud 2017-12-19 12:41:08

「RadonDB 定位是新一代分布式关系型数据库，“新”主要体现在青云QingCloud 把目前比较流行的分布式算法和 MySQL 结合起来。这是一件非常有挑战的事情，不仅考验对分布式的理解，更考验对数据库的理解。」

本文由青云QingCloud 数据库高级专家张雁飞的演讲内容整理而来，共 2628 字，8 图，阅读大概需要 7 分钟。

「新」在哪里

随着数据量膨胀式发展，大量高并发的业务场景对单机数据库带来了巨大的压力与挑战。迫切需要一款支持能够处理高并发在线事务与海量数据分析、具有极强的扩展能力的新型分布式数据库。

为满足电商、金融、制造、零售等行业用户处理大规模结构化数据的要求，同时帮助传统企业将核心业务逐步向云端迁移，青云QingCloud 自主研发了具备大规模、高可靠、高扩展及高性能特点的新一代分布式数据库 —— RadonDB.

RadonDB 是基于 MySQL 研发的新一代分布式关系型数据库，规模可无限水平扩展，支持分布式事务，具备金融级数据强一致性，满足企业级核心数据库对大容量、高并发、高可靠及高可用的苛刻要求。

它的定位是新一代分布式关系型数据库，“新”主要体现在青云QingCloud 把目前比较流行的分布式算法和 MySQL 结合起来。这是一件非常有挑战的事情，不仅考验对分布式的理解，更考验对数据库的理解。

下面看一下 RadonDB 的特性：

第一，可扩展。用户只需用鼠标点击两下，就可以增加更多的节点，提供更大的容量和更高的性能，它的扩展是线性的；
第二，高可用。RadonDB 是一个分布式数据库，上层的 SQL 节点和下层的存储节点都是分布式的，而且完全无中心化，不会出现单点故障，当副本出现问题的时候，可以秒级自动切换，完全无人工干预；
第三，强一致，RadonDB 具备分布式事务的能力，可以满足金融客户的需求，虽然是分布式数据库，我们依然可以保证其强一致性；
第四，易部署，因为它没有中心化，所以很容易跟云平台相结合，也可以独立部署；
第五，MyNewSQL，数据库道路从 MySQL、NoSQL ，然后到现在比较流行的 NewSQL ，青云现在已经走到了 MyNewSQL 这条道路上，就是 MySQL 和 NewSQL 相结合，充分发挥两者的优势。

分布式的「SQL 节点 + 存储节点」

RadonDB 架构图

RadonDB 主要有两大部分组成，分布式 SQL 节点+分布式的存储节点。

分布式 SQL 节点的作用是把用户的请求生成分布式执行计划和分布式执行器，这些执行器在后端的存储节点上并行执行。目前，我们已经做到了对用户的每个 SQL 并行执行，这是 RadonDB 高性能的体现。

分布式存储节点，每一个存储节点其实就是一个 MySQL Plus，MySQL Plus 是一个一主多从的 MySQL 集群，具备高可用、强一致的能力。

以上两大部分就组成了 RadonDB 的整体架构。其中，底层存储副本是用 MySQL，MySQL 不仅提供存储能力，还可以提供计算能力。这样可以把 SQL 层一些用户请求中的计算下推到存储层，减少了 SQL 层和存储层的网络交互。

自动化扩容，双引擎选择

大容量是 RadonDB 首先要解决的一个问题。

目前，青云QingCloud 已经实现了智能化扩容，当用户需要扩容的时候，RadonDB 会采集一些数据，扩容机器人通过分析这些扩容数据，生成扩容建议，并将数据从一个存储引擎迁移到另一个存储引擎。

为了满足用户的多种需求，我们还提供了两种存储引擎供大家选择，一个是大家比较常用的 InnoDB，另一个就是高压缩的引擎 —— TokuDB，压缩比比较高，当数据量比较大的时候，可以选择 TokuDB 引擎。

RadonDB 如何做到金融级高可用、强一致

首先，SQL 层是分布式、无状态的，所以可以实现故障秒级切换与瞬间生效，同时支持跨数据中心部署，全面保障服务高可用。

接下来是存储层，从上面这张 PPT 的图中可以看出，MySQL Plus 是三副本，每一个副本都是一个 MySQL。当主节点故障时，我们使用 Raft 协议选主（Raft 协议是当今分布式比较流行的、普遍采用的一个协议）。

另外，还结合 GTID 并行复制，包括 Semi-Sync-Replication 复制技术，保证主从切换后，数据零丢失且强一致，这是 RadonDB 达到金融级高可用、强一致的原因。

为什么需要数据一致性呢？

在分布式数据库里，数据是分散在多个存储节点上的，举个例子：一整张表放在 3 个节点上，执行一个更新操作，涉及到的 3 个节点都需要更新，假设没有分布式事务保证，某节点更新失败了，其他都成功，最终这个表也是坏的，数据不一致。

所以，为了保证数据一致性，RadonDB 提供了分布式事务能力，当某个节点更新失败时，其他节点的数据会自动回滚。单个节点内多个副本间通过 GTID + Raft + Semi-Sync-Replication 机制保障数据写入的高度一致性。两个层面结合起来，就可以实现整个数据库的强一致，以满足金融级用户的需求。

HTAP：同时满足 OLTP 与 OLAP 需求

RadonDB 还支持 HTAP 混合模式，在传统的解决方案里，一般都是两套系统，就是两个端口。在需要事务和需要分析的时候，分别在两个端口处理，中间通过ETL通道进行数据同步。

但是，在 RadonDB 里就一个端口，如果是 OLAP 的操作，我们会自动路由到计算节点，而且 OLTP 和 OLAP 这两个计算的资源是隔离的，互不影响。

性能和容量可以通过节点的增加而线性增长

接下来看一看 RadonDB 的性能。上图是单机 MySQL 和四个存储节点的 RadonDB 的对比。

我们用 sysbench 16 个表、512 个线程，随机写了 5000 万条数据，测试得出来的结果，RadonDB 基本上可以做到 26589 TBS，单机是 9346 TBS，可以看到在 TBS 层面 RadonDB 性能将近是单机的三倍，延迟却只有的三分之一。

这就是分布式数据库的威力，性能和容量可以通过节点的增加而线性增长。

最后说一下为什么要选择 MySQL

首先，MySQL 是经过业界广泛应用、长期验证并且达到工业级的可靠。

第二，MySQL 是多索引写的原子保证。现在很多分布式数据库的存储引擎都是自己写的，如果你有多个索引的话，必须花很大力气去处理一个索引写成功了，另外一个索引写失败了的这种错误。在这一点上，MySQL 已经做得很好了，我们基于 MySQL 完全可以做到多索引原子写。

第三，计算下推。由于 MySQL 可以做比较强大的计算，所以我们把 SQL 层的计算尽量推给存储层的 MySQL，让 MySQL 在拷取数据的同时，完成计算，再将数据返给 SQL 层，SQL 层只需进行一些聚合，从而提升效率。

第四，用户的 MySQL 数据库不需要进行太多修改，即可迁移至 RadonDB；

最后一点，对 MySQL 的版本没有要求，目前我们用的是 MySQL 5.7，等未来 MySQL 8.0 出来，我们完全可以替换成 8.0 版本。这样，我们存储层会更加强大。

RadonDB 免费深度试用

RadonDB 面向大规模高性能数据库需求，青云QingCloud 注册用户可通过控制台发送工单开通配额体验。如果您的机构有明确的数据库建设计划，希望对 RadonDB 进行深度的试用，您可以通过如下方式申请加入「RandonDB 免费深度试用”」计划。

第一步，填写申请调研问卷：
https://jinshuju.net/f/9gtJAm

第二步，青云QingCloud 安排专人与您取得联系，并审核您的申请；

第三步，审核通过后，我们将依据您的具体业务需求提供定制化试用计划，试用期内，RadonDB 免费使用；反馈测试结果，分享试用体验。