1. 云原生数据库概述：什么是云原生数据库、与传统数据库的对比、核心优势与挑战

大家好，我是这次课程的主讲。在开始之前，我想先问一个问题：你手头的数据库，真的「云原生了」吗？

很多朋友把数据库搬到云上，就觉得万事大吉。其实不然。把虚拟机从机房搬到云上，那不叫云原生，那叫「云托管」。真正的云原生数据库，从设计之初就是为云环境量身打造的。

1.1 什么是云原生数据库

云原生数据库，说白了就是「生在云里，长在云里」的数据库。它充分利用了云计算的弹性、分布式和自动化能力。

我个人习惯把云原生数据库拆成两个层面理解：

• 架构层面：计算与存储分离。这是最核心的特征。传统数据库的「存算一体」在云上很难弹性伸缩，而存算分离后，计算节点可以随时扩缩容，存储层则利用分布式文件系统保证数据安全。
• 运维层面：全托管、自动化。你不需要关心硬件故障、备份恢复、版本升级这些事情。云平台帮你搞定。

举个例子，像 Amazon Aurora、阿里云 PolarDB、Google Cloud Spanner，这些都是典型的云原生数据库。它们底层用的是分布式共享存储，上层计算节点可以做到秒级扩展。

1.2 与传统数据库的对比

这里我拿 MySQL 和 PolarDB 做个对比，你一看就明白了。

对比维度	传统数据库（如自建 MySQL）	云原生数据库（如 PolarDB）
架构	存算一体，单机或主从	存算分离，分布式共享存储
弹性	需要迁移数据，耗时数小时	秒级扩缩容，对业务无感
高可用	主从切换，有数据丢失风险	多副本强一致，RPO=0
运维	DBA 手动处理备份、监控、故障	全托管，自动故障恢复
成本	按峰值采购，资源浪费	按量付费，用多少花多少
扩展性	垂直扩展为主，水平扩展复杂	原生支持水平扩展

嗯，这里要注意一点：传统数据库不是不能用，而是要看场景。如果你的业务量稳定、对弹性要求不高，自建 MySQL 完全够用。但如果你遇到「双11」这种流量洪峰，传统数据库就有点力不从心了。

我记得有一次帮客户做迁移，他们自建 MySQL 集群在高峰期 CPU 跑到 95%，加机器要停机两小时。换成云原生数据库后，扩容只需要点几下鼠标，全程无感。那感觉，真香。

1.3 核心优势

云原生数据库的优势，我总结为四个字：快、稳、省、活。

• 快：弹性快、部署快、故障恢复快。我曾经在项目中测试过，PolarDB 的只读节点从创建到可用，只需要 30 秒。传统 MySQL 加个从库，至少半小时起步。
• 稳：底层分布式存储自带多副本，数据可靠性高达 99.9999999%（9个9）。你想想看，传统数据库能做到几个9？
• 省：按量付费，不用提前采购硬件。而且存算分离后，计算和存储可以独立扩缩容，不会出现「计算不够用、存储用不完」的尴尬。
• 活：支持多种引擎（MySQL、PostgreSQL、MongoDB 等），可以混合使用。而且云厂商会持续迭代新功能，你不需要自己升级。

1.4 面临的挑战

说了这么多好处，也得聊聊挑战。没有银弹，对吧？

• 网络延迟：存算分离后，计算节点和存储节点之间走网络。虽然现在有 RDMA 网络加速，但相比本地磁盘，延迟还是高一些。对延迟极度敏感的场景（比如高频交易），需要谨慎评估。
• 供应商锁定：每个云厂商的云原生数据库都有自己的 API 和特性。一旦选型，迁移到其他云平台成本很高。我建议你在选型时，优先考虑兼容开源协议的数据库（比如兼容 MySQL 协议的），这样未来还有退路。
• 成本不可控：按量付费虽然灵活，但如果业务流量波动大，月底账单可能会吓你一跳。我见过一个团队，因为忘记关测试环境的只读节点，一个月多花了 2 万块。
• 运维黑盒化：全托管意味着你失去了对底层的一些控制权。比如内核参数调优、慢查询分析，有些云平台提供的工具不够细粒度。这时候，你需要依赖云厂商的售后支持。

1.5 我的选型建议

最后，给正在选型的朋友一点个人经验：

1. 先看兼容性：你的应用用的是 MySQL 还是 PostgreSQL？选一个兼容现有生态的云原生数据库，迁移成本最低。
2. 再看弹性需求：业务流量波动大吗？如果一年只有一次大促，那弹性能力就是核心指标。
3. 最后看成本模型：算清楚按量付费和包年包月的差价。长期稳定的业务，包年包月更划算。

好了，这一章就到这里。下一章我们会深入聊聊云原生数据库的架构设计，包括存算分离到底是怎么实现的、分布式存储引擎的原理。到时候我会拿一个实际案例来拆解，保证让你听得过瘾。