在云计算、大数据等新技术的带动下，越来越多的企业需要对结构化的数据进行查询、分析、处理和更新。同时，随着创新业务的不断增加，业务的复杂及庞大的体量必然会产生错综复杂且规模巨大的结构化数据，这些都必然迫使企业对数据库的需求指向大规模、高可靠、高扩展及高性能。
对任何企业而言，数据库都是其应用的核心资源，如何选择适合自身企业 IT 架构及业务的核心数据库是每一个 CIO/CTO 必须面对的问题。
本文将从互联网企业及传统行业（银行、保险等行业）两个部分来具体分析和阐述，希望对大家有所帮助。?
互联网公司的主流是 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 架构图
如上图所示，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 的研发工程师会与大家面对面进行交流，千万不要错过。
青云QingCloud 下一代企业级云架构 ——「全模云」线上发布会，期待你的报名。
