为什么数据库的挑战者们都没好下场

Thu, 02 Apr 2026 21:30:00 +0800

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。发明者？又是那个男人。

MapReduce 不是数据库，是 Google 提出的一种分布式数据处理思路。

Map 对应 SQL 里的 WHERE + ORDER BY，Reduce 对应 GROUP BY。说白了就是把 SQL 的逻辑拆到多台服务器上跑。

Thu, 02 Apr 2026 15:47:00 +0800

用了 MySQL 好几年，最近深入研究 PostgreSQL，才发现自己一直在将就。

不是 MySQL 不好，而是 PostgreSQL 在太多地方更胜一筹。这篇文章从四个维度把它说清楚：索引、数据一致性、性能、扩展性。

两者的基础索引都是 B+ 树，但 PostgreSQL 的花样也太多了。

MySQL（InnoDB）是聚簇索引：数据按主键顺序存在叶子节点上，查主键很快，但非主键字段要先查二级索引再回表查一遍。

PostgreSQL 的所有索引都是非聚簇索引：数据单独存放在堆表里，索引只存指针。主键和普通索引没区别，插入数据直接追加到末尾，不用担心页分裂。

PostgreSQL 的 GIN 索引简直是 JSON 数据的克星：

1
2


CREATE INDEX idx_attr ON products USING GIN (attributes);
SELECT * FROM products WHERE attributes @> '{"color": "red"}';

一句 @> 操作符就能查包含特定键值对的记录。MySQL 根本不支持。

GiST 是一个索引框架，任何数据类型实现了接口就能用。

地理坐标、时间范围、IP 区间……这些用 PostgreSQL 原生的 daterange 加上 GiST 索引，查询重叠和距离效率极高。

1

SELECT * FROM reservations WHERE daterange '[2026-01-08,2026-01-13]' @> '2026-01-10'::date;

MySQL 也不行。