知识卡片
Document级并发控制：把锁粒度下沉到真正冲突的最小单元
内容
MongoDB早期的并发控制粒度非常粗——先是instance-level锁，后来收窄到database-level锁，这种粗粒度锁意味着同一个数据库（甚至同一个实例）内的所有写操作都要相互排队等待，一些团队为了绕开这个瓶颈，甚至把数据人为拆成一堆独立的小数据库来分散锁竞争，如果没有配套的自动化运维能力，这种拆分本身又会带来沉重的运维负担。WiredTiger存储引擎把锁的粒度进一步下沉到document级别，并引入类似关系数据库MVCC（多版本并发控制）的机制为同一份数据维护多个版本，让同一行（文档）的读操作和写操作之间也能并发进行，不再互相阻塞。这个演进路径给出一条通用启示：并发能力的提升，很多时候本质是不断把锁的粒度从”影响面很大的整体资源”收窄到”真正冲突的最小单元”，粒度收窄到什么程度，直接决定了系统并发能力的上限。
参考来源
- 位置：《高可用架构（第1卷）》第6章《大数据与数据库》"6.11 MongoDB2015回顾：全新里程碑式的WiredTiger存储引擎"节，"6.11.1 存储引擎的发展"（源文件：_epub-src/OEBPS/Text/Chapter6_11_2.xhtml）
- 结论依据：原文说明"MongoDB早期的锁粒度是简单粗暴的，instance-level、database-level也一直被吐槽；有一些场景为了适应这么粗粒度锁拆了一堆数据库出来……而document-level并发控制的引入使得MongoDB的并发能力得到极大的释放。这里的数据也是存多版本的，有些类似RDBMS中的MVCC"，直接支撑本卡片结论。
- 原始内容：MongoDB早期的锁粒度是简单粗暴的，instance-level、database-level也一直被吐槽……而document-level并发控制的引入使得MongoDB的并发能力得到极大的释放。这里的数据也是存多版本的，有些类似RDBMS中MVCC（multi version concurrency control）。