mongodb - Mongodb 中的 MMAP 存储引擎

Question

存储引擎充当 mongo db 服务器和物理磁盘之间的接口(interface)，决定需要多少内存，还支持集合级别锁定。我的问题是3.0版本之前发生了什么？谁在存储引擎之前分配内存？而M MAP之前的锁定机制是如何工作的

Answer 1

我们称其为 MMAPv1 - MongoDB 的原始存储引擎，因为它内部使用 mmap 调用来实现存储管理。让我们看看 MMAP 是什么？系统调用看起来像。在 Linux 上，它讨论内存分配，或者将文件或设备映射到内存。导致页面起始地址并持续最多长度字节从文件描述符描述的对象映射到某个偏移量。那么，这实际上意味着什么呢？

嗯，MongoDB 实际上需要一个放置文档的地方。它将文档放入文件中。为此，它首先分配一个大文件。假设它在磁盘上分配了一个 100GB 的文件。因此，我们最终在磁盘上得到了 100GB 的文件。磁盘在实际磁盘上可能物理上连续，也可能不连续，因为在该层之下存在一些算法来控制磁盘上的实际空间分配。但从我们的角度来看，它是一个 100GB 的连续文件。如果MongoDB调用mmap系统调用，它可以将这个100GB文件映射到100GB虚拟内存中。为了获得这么大的虚拟内存，我们需要在 x64 机器上。这些都是page-sized 。因此操作系统上的页面大小要么是 4k，要么是 16k。所以，100GB的虚拟内存里有很多这样的东西。操作系统将决定内存中可以容纳什么。所以，假设盒子的实际物理内存是32GB，那么如果我们去访问这个内存空间中的其中一个页面，它在任何给定时间都可能不在内存中。操作系统决定哪些页面将位于内存中。我们将内存中可用的显示为绿色。因此，当我们去阅读文档时，如果它到达内存中的页面，那么我们就得到了它。如果它到达不在内存中的页面(白色页面)，操作系统必须将其从磁盘中取出。

<子> source

MMAPv1存储引擎提供

1. 集合级并发(锁定)。 MongoDB 内的每个集合都是它自己的文件(可以在 ~\data\db 中看到)。如果在同一个集合上触发多个 write 操作，则必须等待另一个操作完成。这是一个多读者。特定集合一次只能进行一次写入。

2. 允许就地更新。因此，如果文档位于可用(绿色)页面之一中并且我们对其进行更新，那么我们将尝试就地更新它。如果我们无法更新它，那么我们要做的就是将其作为一个整体进行标记，然后将其移动到其他有空间的地方。最后我们将在那里更新它。为了使我们能够就地更新文档而无需移动它，我们使用

3. 2 大小的幂当我们为文档分配初始存储时。因此，如果我们尝试创建一个 3 字节的文档，我们将得到 4 字节。如果我们创建 7 个字节，则为 8 个字节。创建 19 字节文档时为 32 字节。这样，就可以将文档增长一点。那个空间打开了，我们可以更轻松地重复使用它。

   此外，请注意，操作系统决定内存中的内容和磁盘上的内容 - 我们对此无能为力。该操作系统对于内存管理来说足够智能。