数据库选型解读，分布式数据库带来的技术革命

[qingcloud]

对所有企业来说，数据库都是其 IT 系统的核心应用。随着企业的创新与转型，业务日益增加与复杂，产生的数据量也越来越庞大，对数据库也有了更高的要求。大规模、高可靠、高扩展及高性能成为新一代数据库的选型标准。

目前，业内的数据库选型基本可以分为两类：第一，使用开源数据库自建，例如 MySQL ；第二，传统的商业数据库。这两种选型在不同场景应用中都各自的优劣，下面让我们来简单分析一下。

互联网公司的主流是 MySQL ？

开源数据库 MySQL，由于其自身特点和互联网使用场景，在互联网界非常受欢迎，有着极为广泛的应用。

互联网公司往往有高并发、大数据量等业务特点，同时为了在激烈的竞争中占得先机，产品会不断迭代，需要不断推出新产品，并做大量的促销运营活动，这些从技术角度来看是没有办法提前预知的，只能寄希望于 IT 的伸缩能力，所以互联网公司对于系统的伸缩能力都有着执着的追求。

MySQL 之所以在互联网圈子广受欢迎，可以简单归纳为以下几点：

第一，MySQL 简单易用、具备极高的稳定性、功能也比较完善，且具备商业软件没有的可定制化特点，企业可以根据自身业务定制所需的存储引擎，进行性能优化，从而适应自身业务。

第二，由于 MySQL 代码完全开源，当企业的业务出现任何问题时，可以第一时间进行排查和响应，从而保证用户体验。而商用数据库软件的核心技术用户无法深度掌握，很难有足够快速的问题解决能力。

第三，将 MySQL 运行在标准的 X86 服务器上，硬件费用大大降低，同时也可以节省一大笔 License 费用。

MySQL 虽然有种种优势，但 MySQL 也不是万能的，一个复杂 SQL 或者大表 Join 就可能使 MySQL 负载过重，资源耗尽。同时 MySQL 自身也有一个很严重的缺点：没有一个成熟的高可用和分布式解决方案。

所以，大多数互联网公司的选择都是混合使用，当 MySQL 能解决问题时就用 MySQL，而一些对性能、安全性、可靠性要求更高的业务则使用商用数据库软件。

对于他们来说，需要一个开源的分布式数据库产品，来替代目前的商用数据库，进一步节省成本。

金融行业的选择是什么？

金融行业绝大多数系统的数据存储层都采用『小型机+商用数据库+高端存储阵列』的实现方式，随着业务和技术的发展，这种方式逐渐暴露出一些问题。

第一，安全可控的需求。监管机构从国家信息安全高度对银行业的 IT 基础设施提出了开源化、国产化、安全可控的要求。

第二，成本压力的问题。银行业面临着日趋严峻的 IT 成本控制压力，而基于现行数据存储层的实现方式，每个系统的数据存储成本都以数百万计。

第三，扩展性差。随着电子银行、网上银行业务的创新、拓展，数据存储层缺乏良好的可扩展性，难以应对应用层的高并发数据访问。

第四，性能问题。过去银行采用高端的设备，比如使用小型机和大型存储来保证数据库的可用性。在扩展性方面，主要通过增加 CPU、内存、磁盘等方式提高处理能力。这种集中式架构，使得数据库逐渐成为整体系统的瓶颈，越来越不适应海量数据对计算能力的巨大需求。

金融行业普遍面临互联网金融在技术和业务上带来的新挑战，高可用、高可靠、可扩展的大数据平台和分布式数据库解决方案是金融行业的全新技术选择，不但有利于金融行业提升业务创新能力和用户体验，同时增强了自身的技术储备，以迎接互联网时代的市场挑战。

因此，对于银行业来说，以『分布式数据库 + Hadoop 大数据平台』解决方案来逐步替代现有关系型数据库成为最佳选择。

新一代分布式关系型数据库应运而生

无论互联网企业还是传统企业，他们都需要一款分布式数据库来解决处理大规模结构化数据的需求，既要追求最大程度的扩展性，同时也要兼顾性能和可靠性，以及对传统应用的兼容，以替代目前基于开源数据库自建的数据库和商业数据库方案。

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

青云的分布式关系型数据库 —— RadonDB

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

如上图所示，RadonDB 采用分布式 SQL 节点 + 分布式存储节点的高可用分布式架构，每个分区内采用一主多从的架构设计，数据多副本存储，可自动实现故障秒级切换与瞬间生效。同时支持跨数据中心部署，全面保障服务高可用。

存储层由多个 Node 组成，每个 Node 负责部分数据存储，同时在存储节点内，通过 GTID + Raft + Semi-Sync-Replication 机制保障数据写入的高度一致性。 底层硬件一般采用低成本的 X86 架构存储服务器。

同时，存储层采用一主多从的 MySQL 作为存储引擎，这点与行业内其他的分布式数据库不同（ Google Spanner ）。 之所以选择经典的 MySQL 作为存储引擎，主要有以下几点原因：

• MySQL 使用广泛，其可靠性和稳定性经过长期验证；

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

• MySQL 不断的演进，功能日益完善，如支持计算下推，数据就近计算原则；多索引写原子保证； SQL 与 Storage 层数据传输最小化等等。

如上图所示，分布式数据库系统中的数据是相互关联的，虽然每个小表（子表）都是分散的，但逻辑上是一个统一的整体，对上层应用来说，可视为一个集中式的数据库系统。

同时，小表（子表）可以动态漂移，随着表的热度和大小进行动态的扩容和伸缩，保证资源分配最优化。支持存储节点无限水平扩展，从而提供可动态无限扩展的存储容量。性能随节点扩展而线性增长，轻松应对超大容量及超高并发请求带来的性能挑战。

除上述基本特征外，RadonDB 还高度兼容 MySQL 语法，支持 HTAP 混合模式，可跨数据中心部署，支持智能化自动分表、平滑扩容及自动运维，扩容与故障切换时业务零中断，无需人工干预；同时支持 HTAP 混合模式，并提供完善的服务监控、审计日志及安全防护措施。

作为一款基于云模式的大型分布式数据库服务，RadonDB 具备云服务所有的弹性、敏捷、按需和轻运维特性。

写在最后

希望 RadonDB 数据库可以给行业从业者带来更多的可能，包括金融行业新业务、新 IT 的建设，互联网公司核心业务的高可靠、高性能等诉求。

未来，RadonDB 将会全部开源，希望可以有更多的伙伴加入进来，给行业带来更多的惊喜。如果你对分布式数据库还有更多问题，12 月 12 日，我们将会有一场线上发布会，RadonDB 的研发工程师会与大家面对面进行交流，千万不要错过。

12 月 12 日 14:00 - 16:00，不见不散~

👉点击预约未来