引言：被忽视的技术基石
去年是一个特殊的年份——2024年恰好是IBM研发世界上第一个关系数据库（Relational Database）50周年。1974年，IBM不仅创造了这项革命性的技术，还首次将SQL语法投入实际应用。如今，Oracle、Microsoft SQL Server、MySQL、PostgreSQL等数据库巨头全部基于关系数据库架构，可以说RDB是几乎每个程序员在几乎每一个项目中都会接触的技术。
然而，这样一个基础且重要的技术，却往往是大家最不上心的。年轻开发者们更愿意追逐新兴技术，而不愿意深入了解RDB和SQL。在项目中，数据库通常只有运维或DBA会关注，开发者们似乎更热衷于各种号称"未来数据库"的新兴框架。
挑战者们的兴衰史
Key-Value数据库：简单但有局限
Key-Value数据库（KVS）是最简单的数据库类型，每条数据独立存在，通过key查询对应的value。Redis和Memcached等KVS产品在缓存场景中确实拥有绝对优势，得益于其简单的数据结构和内存存储特性，它们在读写速度上有着天然的数量级优势。
但是，当开发者试图让KVS承担更复杂的业务逻辑时，问题就开始显现。我曾在一个物联网项目中选择Redis作为终端系统的数据库，理由是它简单且支持内存读写，适合SD卡存储环境。然而，随着项目复杂度的增加，特别是在处理网络中断、电源故障等异常情况时，管理组件状态变得异常困难。
在Redis中管理一个组件的任务运行状态，需要定义多个array、set、hash map等数据结构，而在关系数据库中一个简单的table和事务就能完成的事情，在Redis中却变得异常复杂。这直接导致了我们遇到的bug中有一半以上都源自这些定制的Redis数据结构。
教训：不要试图用KVS做缓存以外的事情。为了让几十块钱SD卡的读写寿命增加一年，我们付出的开发和维护成本远远超过了收益。
MapReduce：大数据时代的幻象
MapReduce严格来说不是数据库，而是一种分布式数据处理方式，起源于Google在2003年发表的论文。它的核心思想是将传统SQL中的where和order by（map过程）以及group by（reduce过程）在分布式环境中实现。
Apache Hadoop基于MapReduce技术，在那个Google光环最鼎盛的时代，即使你的数据规模比Google低几个数量级，不使用Hadoop似乎都无法向老板交代。
但MapReduce的问题不仅在于"高射炮打蚊子"。在MapReduce中查询数据需要使用分布式写法，即使是简单的SELECT * FROM table，也需要编写几百行Java代码。当需要进行join、window、partition等有逻辑依赖的操作时，编写难度更是难于上青天。
这导致了Apache Hive的出现——一个叠在Hadoop上面的"套壳SQL"，让开发者能够用传统SQL语法来表达查询需求。Hive出现后，手写MapReduce代码几乎绝迹，到头来顶层还是回归了SQL。
更致命的是性能问题。根据"速度金字塔"理论，服务器间的数据传递总是比本地慢几个数量级。而且由于所有操作都需要master节点统筹，系统反应也很慢。当系统灵活度的重要性超越性能重要性时，特别是在性能对比不明显的情况下，MapReduce的劣势就暴露无遗。
有趣的是，Google这个始作俑者早在2010年就在内部系统中抛弃了MapReduce，而业界对Hadoop的追捧还在继续好几年。
图数据库：理想很丰满，现实很骨感
图数据库（Graph Database）以图形式存储数据，每个节点是一个数据实体，边表示数据间的关系。相比平面化的关系数据库，图数据库理论上具有更高的自由度，可以表现更复杂的多维关系，看似是RDB的上位替代品。
但现实很残酷。除了Neo4j还在苦苦支撑，其他图数据库基本都已消失。作为曾经的使用者，我认为图数据库失败的核心原因是长期缺乏标准查询语言。
在关系数据库中，图结构数据通常被拆分为以点或边为单位的更小单元，以传统结构存储，因此可以直接使用SQL查询。但在图数据库中，图以其本身结构存储，查询语法完全取决于各厂商的设计，没有统一标准。
以Neo4j为例，它最初只提供Java API，后来支持Gremlin语言，再后来开发了自己的Cypher语言，再后来开源Cypher并组建标准委员会制定GQL。当GQL正式发布时，距离Neo4j发布已经过去了17年！
更根本的问题是，图数据库把图数据存储和图算法混为一谈。在实际业务中，我们需要的是各种图算法，而经过半个多世纪的发展，用高级编程语言表达的图结构和算法已经非常成熟和高效。但在图数据库中，算法被强制捆绑在查询语句中，受到接口层语法和数据库读写能力的双重约束，这本身就是一个伪命题。
列式数据库：看起来很美好
列式数据库（Column Database）又称Wide Column Store，以能存储大量列为卖点。Apache Cassandra是其代表产品，我在毕业设计项目中首次使用了它。
列式数据库的核心思想是将各种metadata直接存储在主表中，每个key作为一个column，避免复杂的join操作。这样的表格可能有成千上万个列，大部分位置都是空的，但通过底层存储设计可以压缩这些空置位置。
然而，我始终没能理解这种做法的真正意义。为了省几个join操作，却让schema变得极其混乱。当时我为了给column命名，把英语词典都翻了好几遍，到后面都搞不清楚每个column的用途了。
虽然列式数据库没有成功取代关系数据库，但作为至今活得最滋润的新数据库类型，它自然有其存在价值，只是我至今仍未完全理解。
文档数据库：营销的胜利与技术的失败
文档数据库以文档为单位存储数据，MongoDB是其最著名的代表。作为数据库行业的"头号诈骗犯"，MongoDB的成功更多是营销的胜利而非技术的进步。
MongoDB的营销策略很明确：攻击关系数据库的优点，将Transaction、Join、Schema、SQL等特性贴上"性能不佳"的标签，声称在互联网和大数据时代，这些都是瓶颈。相对地，MongoDB没有这些"约束"，因此是"web scale"的未来数据库。
这套说辞确实迷惑了很多中层领导和技术不扎实的开发者。直到几年后MongoDB陆续爆出数据丢失问题，被测出没有实现基本的ACID特性，人们才纷纷觉醒，"web scale"也成为了嘲讽词汇。
NoSQL理念本身就是伪命题。它的核心是摆脱schema约束，但schema从来不是目的，只是特定场景下的中间手段。在我的第一个项目中，由于HTTP日志不规则且分析需求不明确，我们选择了MongoDB。但当具体分析场景确定后，发现在无schema数据堆中进行筛选、计算和聚合都非常麻烦。
道理很简单：前期的收集和存储可以是无规则的，但最终的查询必然是有规则的，而没有什么数据库比关系数据库更懂规则表达。
各大关系数据库厂商很快意识到这个需求，纷纷开始支持JSON格式。现在的PostgreSQL几乎每年都会大幅提升JSON功能，可以说是"走MongoDB的路，让MongoDB无路可走"。
向量数据库：新瓶装旧酒
当前最火的向量数据库（Vector Database）搭上了AI热潮的快车，服务于LLM的向量结构数据。它们的营销手法与当年的MongoDB如出一辙：用错误的论点论证错误的结论。
向量数据库的支持者声称，LLM是未来所有软件的终点，我们不再需要复杂的应用逻辑和数据结构，一切都可以让LLM处理。因此，传统数据库没有价值，专门管理LLM的向量数据库将是未来唯一需要的数据库。
这个逻辑的问题在于，这些人完全不了解实际软件系统开发的需求。以电商平台的搜索功能为例，搜索不仅要考虑用户输入的关键词，还要结合大量业务逻辑：用户地区与商品可售地区的匹配、用户会员等级对价格和排序的影响等等。
用户输入的关键词和商品描述可以用大模型转换成向量进行相似度搜索，但其他业务逻辑无法用向量表达，它们都是典型的决策树逻辑。如果一边做向量匹配，另一边做条件匹配，最后合并结果，这将是"史诗级的屎代码"，运行效率也会低到谷底。
在真正的项目中，这种高度定制化的业务逻辑充斥各个角落，它们才是数据库应该应对的主要问题。向量数据只是特殊场景中的特殊数据结构，就像JSON数据一样。
关系数据库厂商这次反应更快，几乎在一两年内就纷纷加入了对向量格式的支持。PostgreSQL提供了从内置的TSVector类型到官方认可的PGVector插件等多种处理向量的手段，让你可以将向量像JSON一样直接存储，并与其他数据在同一查询语句中进行查询。
为什么关系数据库依然是王者？
回顾这些关系数据库的挑战者，它们的问题不是有短板，而是只有一个长板。而且它们的长板也不是具有高护城河的技术，充其量只是率先挖掘出了某个市场需求。但它们没有抓好先发优势，只给出了一个全是短板和漏洞的答案。
相反，关系数据库总能迅速填补这些需求，而且因为更扎实的基础，能够做出更好的整合效果。关系数据库的优势在于：
稳定性和可靠性：经过50年的发展和验证，关系数据库在数据一致性、事务处理、并发控制等方面已经非常成熟。
标准化：SQL作为标准查询语言，学习成本低，迁移成本也低。开发者掌握了SQL，就能应对绝大多数数据库场景。
生态成熟：从开发工具到监控运维，从性能优化到数据备份，关系数据库拥有最完善的生态系统。
适应性强：关系数据库不断进化，能够吸收新技术的优点。从支持JSON到支持向量，从单机到分布式，关系数据库总能找到适合的解决方案。
业务逻辑表达能力强：SQL在表达复杂业务逻辑方面无可替代，特别是涉及多表关联、条件筛选、聚合计算等场景。
结语：拥抱不变的变化
技术世界总是充满变化，新的数据库技术还会不断出现。但正如过去50年的历史所证明的，关系数据库不仅没有被淘汰，反而在竞争中变得更加强大。
每一次挑战都让关系数据库学会了新的技能：从NoSQL浪潮中学会了灵活的数据结构支持，从大数据时代学会了分布式架构，从AI时代学会了向量处理。这种学习和适应能力，正是关系数据库能够屹立50年不倒的根本原因。
因此，对于每一个软件开发者来说，深入学习和掌握关系数据库不是可选项，而是必需品。它将伴随你的整个职业生涯，从初级开发者到资深架构师，从传统企业到互联网公司，从小型项目到大规模系统。
过去的50年是关系数据库的，未来的50年也还会是关系数据库的。让我们与RDB一起成长，一起变老，让关系数据库再次伟大！
