据 Gartner 预测，到 2025 年，基于云原生平台的数字化业务比例将达到 95%，将带来云原生数据库市场的快速增长。毫无疑问，云原生数据库即将成为云上数据库使用的标准范式。

云原生数据库使得传统数据库得以充分结合云服务的免运维、高弹性、高可扩展、高可用、高性价比优势，又顺应了云端应用大爆发的历史趋势，在过去几年成为 IT 领域的大热门方向，但总体仍处于高速发展的早期阶段。

云原生数据库领域的挑战

在过去相当长的一段时间里，云服务中被使用最多的是虚拟机，也就是物理服务器在云端的虚拟化服务。IT 用户享受到的好处是最朴素的自服务、免运维、高可用、高弹性、高可扩展性和按使用付费，当然这些都只是在虚拟机和 OS 层面（Infrastructrue as a service）。

为了更好地满足数据库用户的需求，云厂商开始提供数据库服务（Database as a service，DBaas）。为了降低开发成本和用户的学习难度及应用迁移门槛，最早的 DBaaS 大多是基于 IaaS 的数据库运维自动化，本质是传统数据库系统平移到云端的一种全托管服务，用户看到的和使用的数据库，除了在访问 OS 层面有所限制，其他并无二致。

在云计算（IaaS）成为趋势并逐渐成为 IT 行业的标准基础设施之后，上述这种做法导致的问题便浮出水面：

问题一：数据本身的爆炸式增长，数据库无论在物理环境还是云端虚拟环境，都需要具备更高的扩展性和更强悍的性能。传统数据库的架构由于受限于历史原因，本身具有的缺陷和瓶颈在云端则更加明显。例如，进行性能优化和执行调度时，传统数据库在资源有上限的物理环境中更在意资源的使用率，并且需要投入大量精力来考虑 RTO 和 RPO，那么整个系统就会因此增加复杂度。然而，这种复杂度在云端是没必要的，并且会造成巨大的资源浪费和开发投入。

问题二：随着数字化程度的进一步加深，业务敏捷度也成为 IT 系统最关注的核心指标之一，数据库的弹性能力是支撑应用和业务敏捷度最重要的基础能力。基于物理环境设计的传统数据库，即使平移到云端，也无法充分利用云端计算和存储资源的高弹性能力。例如物理环境和云端环境的硬件特性，包括但不限于吞吐量、读写特性、资源部署时间、资源回收时间以及消耗成本，都是不同的。如果没有考虑到这些不同点，就会严重影响数据库实际的弹性能力。

问题三：由于大多数用户在数据库上的预算增长超过其他组件的增长，使其更加看重数据库服务的性价比。然而，多云部署日益流行的今天，每个云厂商的定价策略，计算、存储和网络资源的计价方式和能力表现都有或多或少的差异。如果仅仅将一个传统数据库平移上云，很难基于这些复杂的因素做出最优的判断决策，也无法达到最优性价比。

因此，用户和市场都需要一款能充分利用云端的计算、存储和网络资源特性，具备真正的高弹性、高可用和高性价比优势的数据库，这就是云原生数据库发展的最核心驱动力。要实现这样的目的，一个基于云环境精心设计、打磨的技术架构是不可或缺的。这就需要长期持续的投入，才能对云环境足够的了解并对数据库生态充分适应。

云原生数据库领域的进展

曾经有一种说法是“软件吞噬世界”，暂且不管这种说法是否正确，但物理世界愈发数字化是一个正在发生的事实。过去数十年，数字化的加速催生了数以亿级的软件，包括手机 App、SaaS 等等，这些软件对数据库提出了各种各样的需求，也驱动全球出现了多达数百种不同的数据库。

十几年前，我们就知道数字化进程的一大阻碍就是数据孤岛（Data Silo），其严重制约了企业的智能化和创新能力，并以几何级数提高了企业利用数据的门槛和成本，一直以来都是企业信息化部门最头痛的顽疾之一。然而，随着云计算、软件应用和数据库的蓬勃发展，非但没有使这个顽疾得到缓解，反而变得愈发严重。为了解决这个问题，在过去数年中，IT 从业者做了多种尝试。

第一种，简单粗暴地投入最强硬件，搭载一款数据库支持所有软件应用。目前，这种方式已经越来越少见了，因为纯硬件的纵向扩展能力是有限的，而软件应用的组合和变化是无穷的，大部分客户无法负担成本变成了最主要的阻碍。

第二种，整合多种集中式和分布式数据库系统，使用统一界面给数据和应用开发者提供各种能力和服务，并隐藏其底层管理运维的复杂度，这种方式常常被称作“数据中台”和“数据底座”。

基于过往多年的实践，虽然证明这种形式在某些领域和客户群体中是有其价值的，但在某些场景下便会出现局限性：一方面，当后台需要整合的数据库系统过多，又或者前台的应用变化过快、过于复杂时，它的运维、管理和开发成本增长会陷入失控，且相比第一种方案会带来数据实时处理性能的瓶颈；另一方面，当用户需求相对较小和简单时，使用这种方案又会过于臃肿和复杂，投入产出不成正比。

第三种，一些成熟的数据库厂商退而求其次，如果不能一蹴而就地整合这么多数据库系统，那么可以尝试在现有成熟数据库系统中添加新的能力，来减轻一小部分数据烟囱带来的痛苦。

湖仓一体、批流融合、HTAP 等都是这种思路下的产物，但融合的挑战也是巨大的。拿 HTAP 举例，由于 TP 和 AP 数据库在过去默认就是服务两个不同的应用团队，由不同的数据库管理团队来维护，因此对安全性、资源共享和性能隔离等都有各自的需求。当融合在一起的时候，想要性能完全隔离，就应该使用完全独立的计算和存储资源；想要资源利用最大化，就应该使用共享计算和存储资源；同时想要获得更低的处理时延，就应该只存一份数据；想要各自都有读写极致性能，就应该存多份数据...... 这里有太多矛盾的技术点，要想找到平衡点来解决上述提到的技术矛盾是一件不容易的事情。

当然第三种尝试还有很多其他类型的方案，这里就不一一列举了。在 2022 年，我们也注意到有众多云原生数据库厂商在朝着这个方向演进：

- Snowflake 在其年度用户大会 Snowflake Summit 2022 上，宣布推出 Unistore 存储引擎，使得用户在 Snowflake 平台上运行 OLAP 的同时也可以确保数据的完整性和一致性，而这是 OLTP 的核心特性之一。

- 在 2022 re:Invent 大会中，亚马逊云科技发布了一个新服务——“Zero ETL”，其在后台打通了 Aurora 数据库和 Redshift 数据仓库。用户无需自己开发 ETL，就可以轻松地进行数据分析和机器学习，这更像是数据中台和 HTAP 的结合体。

- 最近刚刚完成 F 轮融资的 SingleStore，也号称其数据库系统能在云上通过结合事务和分析工作负载，消除了性能瓶颈和数据移动，以支持数据密集要求苛刻的工作负载。

- 国内初创公司矩阵起源提出的“HSTAP”更为彻底， 将 HTAP 进行了重新定义，融入了串联 AP 和 TP 的 Streaming 能力，并完全重新开发了一款云原生的融合性数据库MatrixOne。目标是让企业只用一款数据库，就能覆盖大中小应用系统的的 TP 和 AP 需求，并能用最高性价比的方式建设好数据中台。

云原生数据库的选型建议

虽然国内数据库的发展相比国外起步得要晚一些，但凭借着后发优势、业务环境等因素，国内数据库市场也逐渐呈现出百花齐放的态势，粗略判断，目前云原生数据库数量已达到几十甚至上百种。

因此，企业在进行选型时，首先要考虑清楚自身选择云原生数据库的驱动力是什么，既要让云原生数据库的特性与自己的业务类型相结合，又要与自己的团队能力进行匹配，是更看重低运维自治，还是更看重资源的弹性扩展，或者更看重性价比，需求不同往往会做出不同的选择。为了避免踩坑，也需要考虑厂商的技术实力和周边生态支持的能力。

其次，企业在选型时还要做好中长期的规划，绝对不要低估数据烟囱对未来业务的影响。随着企业的发展和数据规模的不断攀升，数据库带来的成本增长会远超于业务应用的成本。如果提前做好规划，在数据库的选型与后续建设中就可以做到游刃有余，将来的数字化道路就会事半功倍。比如，由矩阵起源打造的新一代超融合异构云原生数据库 MatrixOne，便可以帮助用户降低数据的使用难度，提供极简的使用体验，让企业可以将精力从繁杂的技术细节中释放出来，最终达到降本增效的目标。

写在最后

回顾这一年，云原生数据库领域依然在稳健高速的发展中。云原生数据库依然还需要时间来达到成熟，但无论是使用创新架构来更好地使用云上资源，还是融合多种能力更好地服务数据应用，各云原生数据库厂商都在沿着帮助客户降本增效的初心，持续进化中。