李奎？李鬼？揭秘真假云原生数据库

在我的数据库开发职业生涯中，云原生技术绝对是让人“又爱又恨”的一个存在。

爱的原因自不必说，“恨”的原因却各有不同。单说真假云原生数据库这一点，就有不少人中招。市场上不乏“李鬼们”打着“云原生数据库”的旗号招摇过市。

为什么会出现这种现象？这恐怕要从云原生技术说起。云原生技术的概念出现在 2010 年之前，基本与 AWS 的历史相当。云原生数据库的时间就短多了，也就不到 10 年，所以真正的云原生数据库都还处于一个比较早期的阶段，盖棺定论为时尚早，因此大家对于云原生数据库的理解也可能“千人千面”。

那么，问题来了：

• 开发者为什么偏爱云原生数据库？

• 既然云原生数据库没有一个明确的定论，那么何来真假之分？所谓真假是指什么？

• 如果必须做云原生，开发者可能会遇到哪些问题？

今天咱们就来说上一说（太可研究所：techinstitute）。

Vol.1

数据库为什么上云？

使用云的优势，拥趸们可以说出一百条，反对者们能列出来一千条，双方争论的焦点还是成本问题。

对于创业公司、小体量的公司来说，公司都不一定能活过明年，花大力气搞基础设施建设成本无疑很高，对于一定体量、走到 pre-IPO 的公司来说云账单又是一个很吓人的数字。公司也养了很多不错的工程师，同时业务增量也基本能预测，所以有规划地下云、自建机房也是很合理的选择。所以，云计算的存在，是助力创业公司变成大公司非常好的拐杖，成年之后把拐杖丢掉也不足为奇。

说回数据库上云。数据库作为软件架构中最核心的部分，承担了存储、分析、管理业务数据的职责，保存了大量状态，同时性能要求极高。而云原生应用的特点是无状态、容器化、弹性伸缩、自动化，状态都存在数据库、云存储里，虽然 k8s 也存在有状态服务(StatefulSet)的概念，也能为 pod 绑定存储，但总有各种各样的问题。

因此，当一家公司大量的基础设施都在云上的时候，使用云的数据库也是很自然的选择。其实，很长一段时间里行业都是云厂商提供数据库服务、业务开发购买服务的模式，至于这些数据库技术上是不是云原生的这就不得而知了。同时一些老牌的数据库也在纷纷上云卖自己的产品，既然都已经在云上卖了，号称自己是云原生数据库貌似也挺合理的。翻开云厂商的数据库列表没有一百也有八十个，这其中有开源魔改的、有自研的，其中哪些是真的云原生数据库，得展开讨论。

Vol.2

接下来咱们再说说真假云原生数据库。

业务研发、DBA 都是有惯性的，会选择使用自己熟悉的数据库例如 MySQL、PostgreSQL，云厂商也很识时务地推出了自己的托管 MySQL、PostgreSQL 服务，这些数据库服务大概率真的是在虚拟机上跑了一个数据库，绑定了固定的物理机磁盘，同时提供了很多运维上的最佳实践，顶多还会对数据库做些魔改、打一些安全和性能上的补丁。这类产品肯定不能称为云原生数据库，只被称为数据库云服务。

上述的方式，只能一个数据库卖给一个用户。对于云厂商来说资源利用率不高，最佳的策略一定是结合自身云存储、网络的特点自研数据库，一个数据库服务卖给一千个用户，同时做好租户资源隔离，无疑是最佳的选择。对于用户来说，在业务早期很难评估到底需要多少数据库资源，资源买多了浪费，买少了扩容又很麻烦，这时候如果云厂商能按数据量或者请求量收费，无疑是极好的。在此情况下，自然而然地催生出了云原生数据库。

一般而言，判断是否是云原生的数据库有这么几个特点：

• 契合云的存储、网络、安全、基础设施

• 收费模式按需而非提前规划

• 云、SaaS生态集成，丰富的自动化运维工具，开箱即用的易用性

• 技术上具有极高的可用性、弹性、多租户、资源隔离的特点

有这些特点的数据库更像是 SaaS 服务，而不再是需要复杂运维的技术产品。云厂商最先推出云原生的数据库不足为奇，同时还有众多创业公司推出了独立云厂商的产品。作为 SaaS 服务的核心竞争力在于易用性，帮助用户提升效率，减少用户的心智负担，性能反倒不是最关键的，Snowflake 就是其中最成功的例子。

不过，即使有了上述特征可以帮助开发者做出判断，仍会有不确定的情况出现。例如，最让开发者迷糊的分布式数据库和云原生数据库，这俩词在数据库的宣传册上往往是同时出现的，但细究下来是有区别的。

云原生的一般是分布式的，毕竟要做高可用、存算分离、分区分片。而分布式则不一定，像传统方案里给 MySQL 做分库分表也是分布式，但要说它是云原生就太牵强了。还有一类是 shard-nothing 的架构，每个节点保存一部分数据分片，虽然性能会更好，但运维起来会很复杂，最典型的例子是早期的 ClickHouse。

说了这么多有些抽象，举个例子会更容易理解：

例如，AWS Aurora。如下两张图所示传统数据库的使用本地磁盘，可以进行硬件层面的适配，性能极高但是存储计算绑定扩展性不佳，而 Aurora 使用了远程磁盘，可以做到跨数据中心同步，数据可用性更高。同时 Aurora 在设计上支持多节点读写，所以服务可用性、扩展性更强。

Aurora 同时支持 MySQL 和 PostgreSQL 的协议，所以能让用户无缝迁移过来。这也是很多云用户困惑的地方，为什么云厂商上面既卖 MySQL 又卖 Aurora for MySQL，这就是两者的区别。

Vol.3

作为一个数据行业的从业者，其实云出现前后的挑战会有很大的不同。

OLAP 产品上云整体比较积极，OLAP 的场景对于延迟、并发要求没那么高，一般秒级延迟、百级别的并发就能满足绝大部分场景，也不用考虑事务性、原子性的问题，更多还是成本的考虑。目前最成功的就是 Snowflake 和 Databricks，开源界的 ClickHouse 和 Doris 也积极推出了自己的云服务。

很多 OLAP 产品，天生就是只有计算层根本没有存储，所以存算分离在架构上不是大障碍，OLAP 上云最大的难点在云存储到计算节点之间的网络延迟。目前有很多缓存方案可供选择，根据 ClickHouse 上云的实践，经过针对性优化的对象存储读取性能也不差，详见链接。还有一个难点在于怎么做极致的弹性来节约成本，OLAP 的负载特点在于查询复杂资源消耗多，在合理的时间里用更小的成本查出结果比极致的性能更重要。

对于 OLTP 产品而言，上云则是件非常难的事情。单说存算分离这一件事，就非常困难，很多传统数据库根本改不了，比如存储引擎中的写入日志(WAL)就是延迟非常敏感的组件，只使用对象存储根本做不了，势必需要其他技术作为补充。

按照阿里云设计 PolarDB 的经验（架构图如下），先得设计一套吞吐性能好、高可用、面向云的分布式存储引擎，再把原先混在一起架构按照 proxy、database cluster、distributed FS 三层解耦，中间通过 RDMA、Data Router 实现高性能的远程文件读写，其次是存储层面的优化使用网络磁盘一定比直接读写本地 SSD 慢，需要通过网络、内存、IO 管理等手段优化，减小其中的 gap，然后是分布式层，要做到要做跨可用区的高可用，还有存储引擎优化，涉及到事务管理、冷热分层存储，甚至还用到了 FPGA 加速 LSM-Tree 的 compaction。

通过阿里云的例子不难看出想做好一款云原生的 OLTP 数据库还挺难的，数据库要与云基础设施深度绑定，换个环境基本就跑不起来。再说到国内 2B 的特点，OLTP 上云好像也没那么紧迫，毕竟主要的金主爸爸们大部分还在使用物理机+私有化部署，有的甚至还有在使用软硬一体的方案。所以不少 OLTP 数据库，号称是云原生，但其实很大的精力在做私有化部署+信创场景，云原生则是存在于销售 PPT 里的噱头。

OLTP 碰到的问题，在很多 NoSQL 数据库中也不是太大的问题，一方面是 NoSQL 没有那么多历史包袱，只要能解决用户的问题就好，采用什么架构，是不是使用 SQL 接口都不是大问题；另一方面，近 10 年诞生的产品（一门心思搞信创的除外）把上云卖产品作为最高优先级，还有云原生的一些坑被前辈们趟得差不多了，直接参考着用就好。所以，创业公司从新兴的 NoSQL 切入，把市场定位在全球，在云上卖产品，是个很好的选择。

Vol.4

DBA 作为公司里对数据库负责的人，在技术选型时对技术先进性没那么关心，更多的关注点在于稳定性、能不能解决业务的问题、出了问题能不能快速解决、运维便捷度这些问题，性能、扩展性是很重要的角度但不是决定性的。

如果一款数据库性能业界无敌、使用了非常先进的架构、扩展性做到了极致、成本只有其他竞品的一半，但是只能做到 2、3 个 9 的稳定性，在前两轮技术选型的时候就会被刷掉。这也是现在云原生数据库遇到的最大的困境，这些数据库的年龄最老的也就是十岁上下，跟传统数据库动辄三四十年的生产实践完全没法比，无论是人才、生态工具、社区、文档、最佳实践等都差得很远，最重要的稳定性也不是很过关。

另一个角度是，如果选择了云原生数据库，技术绑定怎么解决。对于支持标准 SQL 接口的数据库还好说（但是哪款数据库没点 SQL 方言呢），但如果是某个云厂商独有的 NoSQL 数据库，一旦上了“贼船”想要下去就难了。

同时使用数据库不是只有增删改查，还有大量的运维场景，包括备份、监控、自动化运维、高可用建设等工具集成，这些工具各个产品都是不同的，云原生的数据库都还很年轻没人能保证几年之后该产品是否还活着，如果真的停止维护了，已经深度绑定的业务该怎么办。

Vol.5

云计算在技术上是个无可争议的正确方向，就算是逐渐下云的公司，也会使用 k8s、对象存储、存算分离等面向云的产品，云数据库也一定是在逐渐落地的事实，但任重而道远。作为数据库研发出于长期的职业生涯角度考虑，也应该优先选择云原生的产品，而作为公司的架构师、DBA则要根据自身业务特点、长期规划判断使用哪种产品。目前光国内就有将近三百款数据库，其中号称云原生的至少三成，究竟是李逵还是李鬼，朋友们还需擦亮眼睛、仔细甄别。

引用

• https://www.xenonstack.com/insights/cloud-native-databases

• https://docs.oracle.com/en-us/iaas/Content/cloud-adoption-framework/cloud-native.htm

• https://dl.acm.org/doi/10.14778/3352063.3352141

• https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html

• https://bytehouse.cloud/blog/shared-everything-vs-shared-nothing

• https://www.pingcap.com/blog/why-distributed-sql-databases-elevate-modern-app-dev/

• https://clickhouse.com/blog/building-clickhouse-cloud-from-scratch-in-a-year

• https://www.youtube.com/watch?v=gA5U6RZOH_o&list=PL0Z2YDlm0b3iNDUzpY1S3L_iV4nARda_U&index=15