“我应该用 SQL 还是 NoSQL?B 树还是 LSM 树?”
如果你曾经为选择合适的数据库而感到不知所措,其实你并不孤单。每个数据库的背后都有一个由存储引擎和事务协议组成的丰富生态系统。
正确的选择可能意味着是极速性能还是令人头疼的瓶颈。
在这篇文章中,我们通过故事的视角进入数据库内部的世界,并探索 MySQL、MongoDB、Cassandra 和 PostgreSQL 等系统在底层是如何工作的。
请允许让我给大家讲一个故事。
这一切始于我为一款快速发展的电商应用设计后端系统的时候。它需要处理数千个并发用户,实时更新产品库存,提供个性化推荐,以及一个更新速度比“缺货”还快的仪表盘。和许多之前的开发者一样,我遇上了这样一个问题:
“我应该使用哪种数据库?”
接下来是对数据库内部的深入探究——在这个世界里,存储引擎相互冲突,事务以微妙的同步进行,选择并不总是黑白分明的。
这篇文章就是我经历的那段旅程。也许,它会帮助现在的你找到自己的答案。
接下来,我们的旅程真正开始了。
请各位想象一下,一座宏伟的古老图书馆,里面的书架整齐排列,抽屉也都贴有标签,这就是 B /B+树的原型。
高效、有序且久经考验。每次插入都知其所在。每次查询都能快速找到所需内容。
它的工作原理如下:
O(log n)
)MySQL(InnoDB)和PostgreSQL等数据库都喜欢 B 树。当你需要强一致性、快速查找和ACID 事务时,B 树非常可靠。
然后你会遇到 LSM 树,数结构合并树。
这个版本不进行就地更新。它先将所有内容写入内存,然后以排序好的块(称为SSTable)的形式刷新到磁盘。它会不时地通过合并进行清理——这个过程称为压缩。
这就像在便笺簿上写笔记,然后稍后编写一本干净的笔记本。
结果如何?超快的写入性能。非常适合日志、指标、物联网流和其他写入密集型系统。
LSM Trees 为Cassandra、RocksDB、HBase甚至MongoDB的部分提供支持。
B+ 树 | LSM 树 |
---|---|
读取频繁 | 写入频繁 |
需要遵循 ACID | 最终一致性是可以的 |
OLTP 类型的事务 | 流或时间序列数据 |
但这些还没有完。一个好的数据库不仅仅包括读或写。
这便是事务。你需要你的操作具备原子性、一致性、隔离性和持久性——也就是ACID。
在 MySQL 或 PostgreSQL 等系统中,这是通过以下方式处理的:
一切都被锁定、跟踪且可逆。
相比关系型数据库之下,Cassandra 和 DynamoDB 等系统更倾向于最终一致性,它们追求BASE(基本可用、软状态、最终一致性)。
它们的工作方式类似于最终同步的笔记本:更新在一个节点上进行,其他节点在后台同步。
速度快、分布式,但不那么严格。
使用LSM 树,它更加无锁:
这就像将银行金库与旋转门系统进行比较一样。
在当今的现实世界中,不存在一个万能的数据库。
一些系统开始结合两者的优点:
选择正确的数据库并不关乎趋势,而关乎权衡。
问问自己:
一旦你回答了这些问题,选择合适的存储引擎的答案立即会喷涌而出。
还记得你源代码里那一行小小的“INSERT USER”?它开启了跨越数十年的逻辑和工程智慧的瀑布。
了解数据库内部结构,这会使我们成为一名更好的后端工程师——希望现在它也能为你做同样的事儿。
祝各位编码快乐!
作者:鲁肃
本文为 @ 场长 创作并授权 21CTO 发布,未经许可,请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。
该文观点仅代表作者本人,21CTO 平台仅提供信息存储空间服务。