为什么这么设计（Why’s THE Design）是一系列关于计算机领域中程序设计决策的文章，我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。如果你有想要了解的问题，可以在文章下面留言。

我们在这一系列前面的文章曾经分析过为什么 MySQL 使用 B+ 树，有读者在文章下面留言，希望能出一个为什么 MongoDB 使用 B 树的对比文章，这是一个比较好的问题，MySQL 和 MongoDB 两种不同类型的数据库使用了相似却不同的数据结构，为什么 MySQL 选择使用 B+ 树而 MongoDB 使用 B 树呢？

概述

MongoDB 是一个通用的、面向文档的分布式数据库¹，这是官方对 MongoDB 介绍。区别于传统的关系型数据库 MySQL、Oracle 和 SQL Server，MongoDB 最重要的一个特点就是『面向文档』，由于数据存储方式的不同，对外提供的接口不再是被大家熟知的 SQL，所以被划分成了 NoSQL，NoSQL 是相对 SQL 而言的，很多我们耳熟能详的存储系统都被划分成了 NoSQL，例如：Redis、DynamoDB² 和 Elasticsearch 等。

sql-and-nosq

NoSQL 经常被理解成没有 SQL（Non-SQL）或者非关系型（Non-Relational）³，不过也有人将其理解成不只是 SQL（Not Only SQL）⁴，深挖这个词的含义和起源可能没有太多意义，这种二次解读很多时候都是为营销服务的，我们只需要知道 MongoDB 对数据的存储方式与传统的关系型数据库完全不同。

MongoDB 的架构与 MySQL 非常类似，它们底层都使用了可插拔的存储引擎以满足用户的不同需求，用户可以根据数据特征选择不同的存储引擎，最新版本的 MongoDB 使用了 WiredTiger 作为默认的存储引擎⁵。

mongodb-architecture

作为 MongoDB 默认的存储引擎，WiredTiger 使用 B 树作为索引底层的数据结构，但是除了 B 树之外，它还支持 LSM 树作为可选的底层存储结构，LSM 树的全称是 Log-structured merge-tree，你可以在 MongoDB 中使用如下所示的命令创建一个基于 LSM 树的集合（Collection）⁶:

JavaScript

db.createCollection(
    "posts",
    { storageEngine: { wiredTiger: {configString: "type=lsm"}}}
)

我们在这篇文章中不仅会介绍 MongoDB 的默认存储引擎 WiredTiger 为什么选择使用 B 树而不是 B+ 树，还会对 B 树和 LSM 树之间的性能和应用场景进行比较，帮助各位读者更全面地理解今天的问题。

设计

既然要比较两个不同数据结构与 B 树的差别，那么在这里我们将分两个小节分别介绍 B+ 树和 LSM 树为什么没有成为 WiredTiger 默认的数据结构：

作为非关系型的数据库，MongoDB 对于遍历数据的需求没有关系型数据库那么强，它追求的是读写单个记录的性能；
大多数的数据库面对的都是读多写少的场景，B 树与 LSM 树在该场景下有更大的优势；

上述的两个场景都是 MongoDB 需要面对和解决的，所以我们会在这两个常见场景下对不同的数据结构进行比较。

本文转载自Draveness技术博客。

原文链接：https://draveness.me/whys-the-design-mongodb-b-tree

创作场景

为什么 MongoDB 使用 B 树 （一）

为什么 MongoDB 使用 B 树（一）