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原子性、一致性、隔离性、持久性——事务的四道护身符。sqlSELECT 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分库分表到崩溃。于是一批新派武功诞生了。它们统称NoSQLNot 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核心思想就是一个巨大的哈希表。textSET user:1:name 张三 GET user:1:name # 张三优点极快内存存储读写都是微秒级。用途广缓存、计数器、排行榜、消息队列、分布式锁。缺点数据在内存贵断电可能丢。不适合复杂查询只能按 key 查。适合场景缓存、会话、实时排行榜。门派三列族型——HBase、Cassandra代表HBase、Cassandra核心思想按列存储适合海量数据。优点超大规模能存 PB 级数据。高写入吞吐适合日志、监控、时序数据。缺点查询能力弱不适合复杂查询。运维复杂集群部署、调优门槛高。适合场景大数据、物联网、时序数据。门派四图型——Neo4j代表Neo4j、JanusGraph核心思想数据是节点和边专门处理关系。cypherMATCH (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. 他没听懂但数据跑得挺快。
