数据库历史

1970年，数据史IBM的库历工程师Edgar F. Codd发表了一篇论文，提出用关系模型来组织数据。数据史当时主流做法是库历层次模型和网状模型——数据像一棵树或一张网，指针满天飞，数据史程序员得记住每条路径怎么走。库历Codd的数据史想法很不一样：把数据放进一张张二维表里，用集合论和谓词逻辑来查询。库历IBM内部起初没当回事，数据史觉得这玩意性能不行。库历结果呢，数据史几十年后，库历几乎所有数据库都长成了他画的数据史样子。

关系模型真正落地要等到1979年。库历Oracle发布了第一个商用SQL数据库，数据史拉里·埃里森拿着IBM的论文抄了作业，抢在IBM自己的System R之前上市。这事挺讽刺的——发明者没赚到钱，跟风的发了大财。SQL本身也不是Codd设计的，是IBM的Chamberlin和Boyce搞出来的，Codd后来一直抱怨SQL偏离了他的关系代数，比如允许重复行、用NULL表示缺失值，这些都是他眼里的“污染”。

八十年代到九十年代，关系数据库一统天下。Oracle、DB2、SQL Server、Sybase打得头破血流。银行转账、库存管理、ERP系统，全跑在关系表上。ACID——原子性、一致性、隔离性、持久性——成了铁律。那时候你要是跟人说“我用键值对存数据”，对方会觉得你在开玩笑。但互联网来了，事情开始变味。

2000年代中期，Google发了Bigtable论文，Amazon出了Dynamo。这些系统不追求强一致性，不要JOIN，甚至不要求固定表结构。为什么？因为数据量太大了。一个社交网络的用户关系图，用关系数据库做多表连接，磁盘I/O能把机器拖死。于是NoSQL运动兴起，MongoDB、Cassandra、Redis各占山头。开发者突然发现，放弃一部分一致性，换来的是线性扩展能力。这背后是CAP定理在起作用——一致性、可用性、分区容忍性，三选二。

但NoSQL也不是万能药。很多团队跟风上了MongoDB，结果发现事务支持弱，报表查询复杂，最后又搬回PostgreSQL。2010年代后期出现了一个回摆：NewSQL。Google Spanner、CockroachDB、TiDB这些系统试图在分布式架构上重新实现ACID。Spanner甚至用GPS和原子钟做时间同步，就为了给全球分布的数据一个一致的快照。你看，绕了一大圈，又回到了Codd最初强调的“一致性”上，只是这次要跨数据中心。

我自己的观察是，数据库的历史不是线性进步，更像钟摆。关系模型赢了，NoSQL挑战它，NewSQL又把它请回来。每次摇摆都跟硬件和负载变化有关——单机性能不够了，就分布式；分布式太复杂了，就加抽象层。今天你打开任何一个云厂商的控制台，关系型、文档型、图型、时序型、宽列型，全都有。没人再争论“哪个是未来”，因为场景决定选型。

还有一个细节值得玩味。SQL诞生快五十年了，被唱衰过无数次，说它过时、笨重、不适合现代开发。结果呢？连MongoDB都加了SQL支持，Spark用Spark SQL，Flink有Flink SQL。为什么？因为声明式查询太符合人类直觉了——你告诉系统“要什么”，而不是“怎么拿”。这跟Codd当年的洞见一模一样。底层存储引擎换了一茬又一茬，B树、LSM树、列存、向量化执行，但接口层还是那张表、那个SELECT。挺神奇的。

最后说个具体案例。2017年，Uber把它的核心行程数据库从PostgreSQL迁到了自己写的Schemaless（基于MySQL）。不是因为PostgreSQL不好，而是写入量太大，单机扛不住。但迁移之后，他们发现跨行事务没了，得在应用层补。于是又搞了一套补偿逻辑。这说明什么？数据库选型从来不是纯技术问题，是工程权衡。你省了数据库的麻烦，就得在代码里还回来。