17611538698
webmaster@21cto.com

数据库正确的选型艺术

数据库 0 71 11小时前
图片

“我应该用 SQL 还是 NoSQL?B 树还是 LSM 树?” 

如果你曾经为选择合适的数据库而感到不知所措,其实你并不孤单。每个数据库的背后都有一个由存储引擎和事务协议组成的丰富生态系统。

正确的选择可能意味着是极速性能还是令人头疼的瓶颈。

在这篇文章中,我们通过故事的视角进入数据库内部的世界,并探索 MySQL、MongoDB、Cassandra 和 PostgreSQL 等系统在底层是如何工作的。

请允许让我给大家讲一个故事。

这一切始于我为一款快速发展的电商应用设计后端系统的时候。它需要处理数千个并发用户,实时更新产品库存,提供个性化推荐,以及一个更新速度比“缺货”还快的仪表盘。和许多之前的开发者一样,我遇上了这样一个问题

“我应该使用哪种数据库?”

接下来是对数据库内部的深入探究——在这个世界里,存储引擎相互冲突,事务以微妙的同步进行,选择并不总是黑白分明的。

这篇文章就是我经历的那段旅程。也许,它会帮助现在的你找到自己的答案。

数据库系统的幕后


乍一看,数据库很简单。你插入数据,查询数据,也许更新或删除几行。但在数据库引擎下,它是一台整机,包括如下层组成:


  • 传输:你的查询如何传输到服务器
  • 查询解析器和优化器:你的 SQL 实际上变成了什么
  • 执行引擎:一切完成的地方
  • 存储引擎:核心、保险库、使一切成为可能的东西


接下来,我们的旅程真正开始了。

🍊 存储引擎对决:B 树 vs LSM 树

🎓 经典英雄:B 树


请各位想象一下,一座宏伟的古老图书馆,里面的书架整齐排列,抽屉也都贴有标签,这就是 B /B+树的原型。

高效、有序且久经考验。每次插入都知其所在。每次查询都能快速找到所需内容。

它的工作原理如下:

  • 你的数据存储在已排序的块中
  • 每次读取都很快(O(log n)
  • 更新发生在原地——这意味着一些随机的磁盘 I/O,但这对 OLTP 系统来说没问题


MySQL(InnoDB)PostgreSQL等数据库都喜欢 B 树。当你需要强一致性快速查找ACID 事务时,B 树非常可靠。

🔥 年轻的颠覆者:LSM 树


然后你会遇到 LSM 树,数结构合并树。

这个版本不进行就地更新。它先将所有内容写入内存,然后以排序好的块(称为SSTable)的形式刷新到磁盘。它会不时地通过合并进行清理——这个过程称为压缩

这就像在便笺簿上写笔记,然后稍后编写一本干净的笔记本。

结果如何?超快的写入性能。非常适合日志、指标、物联网流和其他写入密集型系统。

LSM Trees 为CassandraRocksDBHBase甚至MongoDB的部分提供支持。

⚖️ 当我们必须做出选择时


在做选择时,我感觉自己就像置身于一场西部大决战之中:


B+ 树LSM 树
读取频繁写入频繁
需要遵循 ACID最终一致性是可以的
OLTP 类型的事务流或时间序列数据


但这些还没有完。一个好的数据库不仅仅包括读或写。

🔐 数据库交易特性


还记得一些警匪抢劫电影中“时机就是一切”的那个时刻吗?


这便是事务。你需要你的操作具备原子性一致性隔离性持久性——也就是ACID

✪️ SQL 数据库(关系型)


在 MySQL 或 PostgreSQL 等系统中,这是通过以下方式处理的:

  • 撤消日志
  • WAL(预写日志)
  • MVCC(多版本并发控制)


一切都被锁定、跟踪且可逆。

🌐 NoSQL 数据库


相比关系型数据库之下,Cassandra 和 DynamoDB 等系统更倾向于最终一致性,它们追求BASE(基本可用、软状态、最终一致性)。

它们的工作方式类似于最终同步的笔记本:更新在一个节点上进行,其他节点在后台同步。

速度快、分布式,但不那么严格。

🧵 关于并发的讨论


并发使得事情变得更加麻烦和棘手。使用B 树,可以通过仔细的锁定来控制并发性:


  • 共享锁、排他锁、甚至更新锁
  • B-Link 树(一种巧妙的增强功能)让读取在写入过程中也能流畅进行


使用LSM 树,它更加无锁

  • MemTables 并发写入
  • SSTable 是不可变的
  • 压缩是后台工作


这就像将银行金库与旋转门系统进行比较一样。

🧬 混合时代


在当今的现实世界中,不存在一个万能的数据库。

一些系统开始结合两者的优点:

  • MySQL有RocksDB插件
  • MongoDB切换到类似 LSM 的引擎(WiredTiger)
  • Aurora将 SQL 兼容性与 NoSQL 性能融为一体


🧠 记住选择


选择正确的数据库并不关乎趋势,而关乎权衡

问问自己:

  • 你的工作量是阅读还是写操作重
  • 你需要严格的交易吗,还是速度更重要
  • 你是否正在处理结构化业务数据数百万个流事件


一旦你回答了这些问题,选择合适的存储引擎的答案立即会喷涌而出。

✍️ 结语


还记得你源代码里那一行小小的“INSERT USER”?它开启了跨越数十年的逻辑和工程智慧的瀑布。

了解数据库内部结构,这会使我们成为一名更好的后端工程师——希望现在它也能为你做同样的事儿。

祝各位编码快乐!

作者:鲁肃

评论