为什么数据库的挑战者们都没好下场
从 Redis 到 Hadoop 再到 GraphDB，我用过所有想取代关系数据库的技术。最后发现，都是在给自己找麻烦。
1974 年，IBM 捣鼓出了世界上第一个关系数据库。
50 年过去了，Oracle、MySQL、PostgreSQL 这些 RDB 依然霸榜。年轻程序员嘴上喊着 “SQL 太土”，项目里该用还是用。
有意思的是，每隔几年就冒出一堆"未来数据库"来挑战 RDB 的地位：Key-Value Store、MapReduce、Hadoop、图数据库、向量数据库……
我都用过。所以我知道为什么它们最后都凉了。
Redis：我踩过最贵的坑
Redis 是 KVS 的典型代表，用 Key 找 Value，简单粗暴。
缓存用它，完美。问题是做开发的总有点执念，非要把缓存以外的事情也塞给它。
我当年做物联网项目就载过这个跟头。
当时选 Redis 考虑两个因素：一是物联网系统里大部分是文件，数据库只管组件状态；二是终端用 SD 卡，磁盘 IO 寿命短，想省着用。
结果第三个月就开始出问题了。
物联网环境里，网络和电源都不可靠，随时可能断电断网。每一个组件的状态管理变得极其复杂——在 Redis 上，你要用 Array、Set、HashMap 来描述一个简单的"任务运行状态"，换成 SQLite 的话，一个表加几条 SQL 就搞定了。
最后项目里一半以上的 Bug 都跟这个定制 Redis 数据结构有关。就在写这篇文章的时候，我们还在修一个诡异的 Bug：终端下载视频时遇到网络问题，紧接着又断电，Redis 里的任务信息不完整，视频永远下不下来。
你说这值不值？
为了省 SD 卡那点读写寿命，被折腾了好几年。
第一个 KVS 是 AT&T 在 1979 年发布的，叫 DBM。发明者？又是那个男人。
Hadoop：我学了个寂寞
MapReduce 不是数据库，是 Google 提出的一种分布式数据处理思路。
Map 对应 SQL 里的 WHERE + ORDER BY，Reduce 对应 GROUP BY。说白了就是把 SQL 的逻辑拆到多台服务器上跑。
当年这概念火得不行，Apache Hadoop 一度要取代 RDB。你数据规模小？不存 Hadoop 里都不好意思跟人打招呼。
但问题很快暴露了：
写个简单的 SELECT + GROUP BY，得搞几百行 Java 代码。后来出了 Apache Hive，总算能用 SQL 了——我们再也没手写过 MapReduce。
到头来还是回到 SQL。
更扎心的是，Google 2010 年就在内部放弃 MapReduce 了。等我们这波人学会、进入职场、踩完坑，黄花菜都凉了。
Hadoop 的生态最后也被拆解了：HDFS 被 S3 取代，YARN 被 Kubernetes 取代，MapReduce 被 Spark 和 Flink 取代。
底层负责数据存储和管理的，还是那个 RDB。
GraphDB：看起来很美
图数据库用节点和边来表达数据关系，比平面化的 RDB 更灵活。
Neo4j 2007 年发布，是第一个满足 ACID 要求的图数据库，一度被认为是 RDB 的上位替代。
现在呢？
活下来的图数据库只有 Neo4j 一个，还靠投资人硬撑。
为什么图数据库凉了？这个问题说起来复杂，但核心问题可能是：它解决的痛点太小众，而引入的复杂度太大。
大多数业务场景里，RDB 的 JOIN 已经够用了。图数据库那些炫酷的查询语法，学起来不比 SQL 简单。
结论
说了这么多，不是说这些技术完全没用。
Redis 做缓存，Hadoop 处理大数据备份，图数据库做社交关系分析——都有它们的场景。
但如果你想用它们取代 RDB 来做核心业务数据管理，大概率是在给自己挖坑。
RDB 能在 50 年里稳坐钓鱼台，不是因为没人挑战过。是因为它解决的是最通用的问题，而那些"挑战者"们，大多数只是在解决一个问题的同时引入更多问题。
下次有人跟你说 “SQL 太老了，我们要用 XX 数据库颠覆传统”，你可以先问他：你们团队有没有专职 DBA？
没有的话，建议老实点。
相关阅读：