NoSQL 群侠传：当数据库江湖不再只有 SQL 一种武功-开发者社区

NoSQL 群侠传：当数据库江湖不再只有 SQL 一种武功

2022 年 7 月，我在一个深夜打开了 MongoDB 的官网，然后陷入了沉思：为什么存个数据，还要学一门新的查询语言？

序章：一个被 SQL 折磨的深夜

2022 年 7 月，天气热得不像话。

我坐在电脑前，正在设计一个"用户行为日志"的数据库表。需求是这样的：

每个用户有不同的事件类型。
每种事件有不同的字段。
字段还会随着业务变化不断新增。

我画了第一版 ER 图，三张表。画完发现不够，改成五张。改完发现还不够，最后变成八张表、四个外键关联。

然后我盯着屏幕问自己：我到底是在存数据，还是在解数学题？

就在那个深夜，我第一次认真打开了 MongoDB 的官网。

第一章：关系型数据库——江湖的"名门正派"

在聊 NoSQL 之前，得先说说它的对手：关系型数据库（RDBMS）。

MySQL、PostgreSQL、Oracle、SQL Server——这四位是数据库江湖的"名门正派"，统治了几十年。

它们的核心武功是：

表（Table）：数据存在表格里，行列分明。
Schema：每张表的字段和类型，建表时就得定死。
SQL：一门统一的查询语言，SELECT、JOIN、GROUP BY。
ACID：原子性、一致性、隔离性、持久性——事务的四道护身符。
sql

SELECT u.name, o.order_no FROM users u JOIN orders o ON u.id = o.user_id WHERE o.created_at > '2022-07-01'

这套武功的优点很明显：严谨、可靠、生态成熟。

但缺点也明显：你得先设计好 Schema，才能存数据。字段变了，得改表。数据量大了，得加索引、分库分表。

而 2000 年代后，互联网的数据变了。

第二章：互联网的"新需求"——NoSQL 的诞生

2000 年代中期，Google、Amazon、Facebook 这些公司遇到了一个难题：

数据量太大、增长太快、格式太乱。

Google 要存整个互联网的网页。
Amazon 要存海量商品和订单。
Facebook 要存几亿人的社交关系。

用 MySQL？分库分表到崩溃。

于是，一批"新派武功"诞生了。它们统称：NoSQL（Not Only SQL）。

注意：NoSQL 不是"No SQL"，而是"不只是 SQL"。它不是说 SQL 不好，而是说"除了 SQL，还有别的选择"。

第三章：NoSQL 四大门派

NoSQL 不是一个东西，而是一群东西。它们分四大门派。

门派一：文档型——MongoDB

代表：MongoDB、CouchDB

核心思想：数据以"文档"存储，像 JSON。

json

{ "_id": "abc123", "name": "张三", "age": 18, "hobbies": ["篮球", "编程"], "address": { "city": "上海", "district": "浦东" } }

你看到的这个结构，就是 MongoDB 存数据的样子。

优点：

Schema 灵活：今天存 {name, age}，明天存 {name, age, hobby}，不用改表。
嵌套自然：地址、爱好直接嵌在文档里，不用拆表。
开发快：存什么就是什么，不用先设计 ER 图。

缺点：

不适合复杂事务：跨文档的 ACID 事务支持较晚（4.0 才有）。
JOIN 弱：MongoDB 有 $lookup，但不如 SQL 的 JOIN 强大。
容易"设计失控"：因为太灵活，容易把数据存得乱七八糟。

适合场景：日志、内容管理、用户画像、快速迭代的产品。

门派二：键值型——Redis

代表：Redis、Memcached

核心思想：就是一个巨大的哈希表。

text

SET user:1:name "张三" GET user:1:name # "张三"

优点：

极快：内存存储，读写都是微秒级。
用途广：缓存、计数器、排行榜、消息队列、分布式锁。

缺点：

数据在内存：贵，断电可能丢。
不适合复杂查询：只能按 key 查。

适合场景：缓存、会话、实时排行榜。

门派三：列族型——HBase、Cassandra

代表：HBase、Cassandra

核心思想：按列存储，适合海量数据。

优点：

超大规模：能存 PB 级数据。
高写入吞吐：适合日志、监控、时序数据。

缺点：

查询能力弱：不适合复杂查询。
运维复杂：集群部署、调优门槛高。

适合场景：大数据、物联网、时序数据。

门派四：图型——Neo4j

代表：Neo4j、JanusGraph

核心思想：数据是"节点"和"边"，专门处理关系。

cypher

MATCH (a:Person)-[:FRIEND]->(b:Person) WHERE a.name = '张三' RETURN b.name

优点：

关系查询极快：查"朋友的朋友的朋友"，图数据库一秒钟，SQL 要 JOIN 到崩溃。
天然适合社交网络：推荐、反欺诈、知识图谱。

缺点：

不适合非关系数据：存日志、存订单，用图数据库是杀鸡用牛刀。

适合场景：社交网络、推荐系统、反欺诈。

第四章：2022 年 7 月，数据库江湖的格局

回到 2022 年 7 月，数据库江湖的格局大概是这样的：

关系型仍是主流

MySQL、PostgreSQL 依然是大多数项目的默认选择。

PostgreSQL 尤其风光——它既能做关系型，又能存 JSON，还能做全文搜索、地理查询，被称为"最像 NoSQL 的关系型数据库"。

MongoDB 成为文档型王者

MongoDB 在 2022 年已经是文档数据库的绝对王者。它的 Atlas 云服务、聚合管道、事务支持，让它从"小玩具"变成了"生产级数据库"。

但它的争议也一直存在：有人爱它的灵活，有人骂它的"无 Schema 等于无设计"。

Redis 无处不在

Redis 已经不只是一个缓存了。它成了"数据结构服务器"——计数器、队列、发布订阅、地理位置、流，什么都能干。

云原生数据库崛起

2022 年，云原生数据库开始爆发：

Amazon DynamoDB：全托管的键值数据库。
Google Firestore：面向移动端的文档数据库。
阿里云 Lindorm：多模数据库。
TiDB：兼容 MySQL 的分布式数据库。

数据库不再只是"装数据的软件"，而是"云上的服务"。

第五章：选型——到底该用哪个？

这是所有开发者最纠结的问题。

我的经验是：别问"哪个最好"，问"哪个最合适"。

选 MySQL / PostgreSQL 如果：

数据结构清晰、关系复杂。
需要强事务（金融、订单）。
团队熟悉 SQL。

选 MongoDB 如果：

数据结构灵活、经常变。
数据有嵌套关系。
想快速迭代，不想被 Schema 束缚。

选 Redis 如果：

需要极快读写。
做缓存、计数器、排行榜。
数据可以容忍丢失。

选 HBase / Cassandra 如果：

数据量极大（PB 级）。
写入吞吐要求极高。
能接受运维复杂度。

选 Neo4j 如果：

数据核心是"关系"。
需要做推荐、反欺诈、知识图谱。

最真实的场景是：一个系统同时用多个数据库。

MySQL 存订单。
MongoDB 存日志。
Redis 做缓存。
Elasticsearch 做搜索。

这叫"多模架构"，也是 2022 年后的主流。

第六章：MongoDB 初体验——我的第一个文档

回到那个深夜。

我最终决定用 MongoDB 存用户行为日志。

在 MySQL 里，我需要：

events 表：id、user_id、event_type、created_at。
event_properties 表：event_id、key、value。
查询时还得 JOIN。

在 MongoDB 里，我只需要：

json

{ "_id": ObjectId("..."), "userId": "user_123", "eventType": "click", "properties": { "page": "/home", "button": "signup" }, "createdAt": ISODate("2022-07-15T10:00:00Z") }

一个文档，所有信息都在里面。不用 JOIN，不用建关联表。

那一刻，我理解了为什么有人说：“MongoDB 让数据存储变得像写代码一样自然。”

终章：数据库江湖，没有"最好"

写完这一圈，我最大的感悟是：

数据库江湖，没有"最好"，只有"最合适"。

关系型数据库的严谨，是它的优点，也是它的束缚。
NoSQL 的灵活，是它的优势，也是它的风险。
图数据库的强大，是它的专长，也是它的局限。

至此，我学会了一件事：

别把自己绑死在一种数据库上。真正的高手，是根据问题选武器，而不是拿着锤子找钉子。

数据库只是工具，解决问题才是目的。

P.S. 写完这篇文章后，我的项目里同时跑了 MySQL、MongoDB 和 Redis。老板问我为什么用三个数据库，我说：“因为问题有三个。”

P.P.S. 他没听懂，但数据跑得挺快。

NoSQL 群侠传：当数据库江湖不再只有 SQL 一种武功