NoneSQL数据库的开发体验至上
MySQL、MongoDB、Firebase、Spanner：在任何复杂度或规模的层面，对于数据库用户来说现在都可能是最好的时代。然而，这些数据库之间存在一个共通点——它们的重心仍然集中在基础设施上，而非开发者体验（DevEx）。本文将尝试论证一个观点：数据库的内部实现从长远来看将变得不那么重要，而开发者体验将成为区分各类数据库产品的关键。
现今的数据库产品仍以内部实现为重点
为了看清数据库中正在发生的转变，有必要回顾数据存储的三个时代（至少从本文的视角来看）。它们的共同点在于，改进始终集中在基础设施上，而不是开发者体验。
1. 初始阶段：关系型数据库的时代
数据库的早期历史超出了本文讨论范围，但可以肯定地说，在头二十年的发展里，数据库几乎是关系型数据的代名词。MySQL 的首次发布是在 1995 年（距今已有 26 年历史），Postgres 的首次发布比它晚了一年，是在 1996 年。这两个数据库实际上至今仍是全球范围内最流行的数据库，这其中可能蕴含着一些值得深思的经验，不过本文暂不展开讨论。
从根本上来说，SQL 是关于数据的严格性和事务完整性（即 ACID 的特性）——尽管今天很多人用它来查询较为非结构化的数据。在 OLAP 流行之前，关系型数据库优先考虑的是确保读写操作的干净和可靠性，即使是每一次插入操作的新数据，也是没有任何例外的。因此，为了实现上述目标，你需要提前设计好数据库的 Schema（模式）。这一点在当时来说是合理的。但问题从规模化开始变得复杂了。
注：虽然 SQL 指的是一种查询关系型数据库的语言，但多年来，它已经成为固定模式和关系型数据概念的代名词，因此才有“SQL 数据库”的名称。
2. 非关系型数据库的成熟
MongoDB 和大多数非关系型数据库的问题在于它们并非完全遵守 ACID 原则（根据 CAP 定理，它们是“最终一致性”模型），而开发者实际上常常更喜欢像 SELECT * 这样的查询，而不是类似 .findOne() 的方法。如果你未来需要在应用程序其他部分分析相同的数据，那么预定义 Schema 的刚性模式可以提供一致的结果。
小型非关系型数据库逐渐成熟。它们开始支持事务（某种时间范围内的一致性）以及总体更加稳定。但经过几年与“灵活性”数据库打交道后，越来越清楚的是，“初期的刚性”反而可以带来“后期的灵活性”。如果你决定从不同角度或情境分析数据，现有 Schema 可以帮助获取可靠的查询结果。
3. 新的趋势：SQL 扩展性数据库
接下来是数据库领域的新趋势，被称作 SQL 扩展性数据库——一种兼具事务性刚性且能够横向扩展的关系型数据库。例如，Google 开发的 Spanner（论文链接：Spanner论文）声称可以进行水平无限扩展（如跨分片的事务），AWS 的 Aurora 也声称其分布式架构比传统的 MySQL 更快速。此外还有 Vitess（我们在 PlanetScale 使用的产品之一），它是一种针对 MySQL 的编配层。
数据库的内部实现将会变得无关紧要
我认为，数据库将会跟随通用计算领域的发展路径，底层实现将越来越商品化，而数据库产品之间的竞争将基于开发者体验进行区分。我们正在形成一种共识：在具备可靠性的同时，优先快速开发比管理底层基础设施更重要——前提是扩展能力尚未成为问题。这是整个基础设施发展的方向。同时，这也是一种开发者主导的 SaaS（如 Stripe、Twilio）的趋势。
基础设施与开发者体验区别
以下是基础设施任务与开发者体验（DevEx）任务的一种分类模型：
| 基础设施任务 | 开发者体验任务 |
|---|---|
| 实例的规模化选择 | Schema/迁移 |
| 满足扩展需求 | 版本控制 |
| 成本优化 | CLI 交互改进 |
| 性能优化 | 用户管理 |
| 升级与补丁管理 | IDE/客户端 |
| 网络配置 | 数据分支管理 |
可以看到许多基础设施任务现在已经可以通过 DBaaS（例如 AWS RDS）实现自动化，但仍存在部分操作需要手动处理——例如手动扩展实例或自行通过 Lambda 分配内存。
未来数据库的3个领域 将集中于：
- 数据交互（更简洁的 API、认证更易用）
- 工作流环节（迁移与版本控制的创新方式）
- 价格透明的弹性扩展。
未来的数据库变革将围绕着简化开发、降低学习门槛以及提升对不同变式的兼容性，同时摆脱过于烦琐的基础结构配置。你怎么看待未来五年云数据库开发体验的发展方向？
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
