当前位置: 首页 > 工具软件 > WiredTiger > 使用案例 >

WiredTiger 存储引擎

陶乐生
2023-12-01

从 MongoDB 3.2 开始,WiredTiger 存储引擎是默认存储引擎。对于现有部署,如果不指定 --storageEngine 或 storage.engine 设置,3.2+版本的 mongod实例可以自动确定用于在 --dbpath 或 storage.dbPath 中创建数据文件的存储引擎。

文档级并发

WiredTiger 使用文档级并发控制进行写入操作。因此,多个客户端可以同时修改一个集合的不同文档。

对于大多数读写操作,WiredTiger 使用乐观并发控制。WiredTiger 仅在全局、数据库和集合级别使用意图锁。当存储引擎检测到两个操作之间的冲突时,会引发写入冲突,导致 MongoDB 透明地重试该操作。

一些全局操作,通常是涉及多个数据库的短期操作,仍然需要全局“实例范围”锁。其他一些操作,例如collMod,仍然需要独占数据库锁。

快照和检查点

WiredTiger 使用多版本并发控制 (MVCC)。在操作开始时,WiredTiger 会为操作提供数据的时间点快照。快照呈现内存中数据的一致视图。

写入磁盘时,WiredTiger 将快照中的所有数据以一致的方式跨所有数据文件写入磁盘。现在持久的 数据充当数据文件中的检查点。检查点确保数据文件在最后一个检查点之前是一致的,包括最后一个检查点;即检查点可以充当恢复点。

从版本 3.6 开始,MongoDB 配置 WiredTiger 以每隔 60 秒创建检查点(即将快照数据写入磁盘)。在早期版本中,MongoDB 将检查点设置为在 WiredTiger 中以 60 秒的间隔或在写入 2 GB 的日志数据时发生在用户数据上,以先发生者为准。

在写入新的检查点期间,之前的检查点仍然有效。因此,即使 MongoDB 在写入新检查点时终止或遇到错误,在重新启动时,MongoDB 也可以从最后一个有效检查点恢复。

当 WiredTiger 的元数据表被原子更新以引用新的检查点时,新的检查点变得可访问和永久。一旦可以访问新的检查点,WiredTiger 就会从旧的检查点中释放页面。

使用 WiredTiger,即使没有日志,MongoDB 也可以从上一个检查点恢复;但是,要恢复在最后一个检查点之后所做的更改,请使用journaling运行。

从 MongoDB 4.0 开始,您不能为使用 WiredTiger 存储引擎的副本集成员指定–nojournal选项或storage.journal.enabled: false。

Journal

WiredTiger 使用预写日志(即日志)结合 检查点来确保数据的持久性。

WiredTiger 日志保留检查点之间的所有数据修改。如果 MongoDB 在检查点之间退出,它会使用日志重放自上一个检查点以来修改的所有数据。有关 MongoDB 将日志数据写入磁盘的频率的信息,请参阅Journaling Process。

WiredTiger 日志使用 snappy压缩库进行压缩。要指定不同的压缩算法或不压缩,请使用该 storage.wiredTiger.engineConfig.journalCompressor设置。有关更改日志压缩器的详细信息,请参阅 更改 WiredTiger 日志压缩器。

如果日志记录小于或等于 128 字节( WiredTiger 的最小日志记录大小),WiredTiger 不会压缩该记录。

您可以通过设置 storage.journal.enabled = false 为来禁用独立实例的日志 ,这可以减少维护日志的开销。对于独立实例,不使用日志意味着,当 MongoDB 意外退出时,您将丢失最后一个检查点之后的所有数据修改。

从 MongoDB 4.0 开始,您不能为使用 WiredTiger 存储引擎的副本集成员指定--nojournal选项或storage.journal.enabled: false

压缩

使用 WiredTiger,MongoDB 支持所有集合和索引的压缩。压缩以增加 CPU 为代价最大限度地减少了存储使用。

默认情况下,WiredTiger 使用 snappy 压缩库对所有集合使用块压缩,对 所有索引使用前缀压缩 。

对于集合,还可以使用以下块压缩库:

  • zlib
  • zstd(从 MongoDB 4.2 开始可用)

要指定替代压缩算法或不压缩,请使用该storage.wiredTiger.collectionConfig.blockCompressor 设置。

对于索引,要禁用前缀压缩,请使用该 storage.wiredTiger.indexConfig.prefixCompression设置。

在收集和索引创建期间,压缩设置也可以在每个集合和每个索引的基础上进行配置。请参阅 指定存储引擎选项和 db.collection.createIndex() storageEngine 选项。

对于大多数工作负载,默认压缩设置会平衡存储效率和处理要求。

WiredTiger 日志也​​是默认压缩的。有关日记压缩的信息,请参阅日记。

内存使用

借助 WiredTiger,MongoDB 同时利用了 WiredTiger 内部缓存和文件系统缓存。

从 MongoDB 3.4 开始,默认的 WiredTiger 内部缓存大小是以下两者中的较大者:

  • 50% of (RAM - 1 GB), or
  • 256 MB.

例如,在一个总共有 4GB RAM 的系统上,WiredTiger 缓存将使用 1.5GB 的 RAM ( 0.5 * (4 GB - 1 GB) = 1.5 GB)。相反,总共有 1.25 GB RAM 的系统将分配 256 MB 给 WiredTiger 缓存,因为这是总 RAM 减去 1 GB ( 0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB) 的一半以上。

在某些情况下,例如在容器中运行时,数据库的内存限制可能低于系统总内存。在这种情况下,这个内存限制,而不是总系统内存,被用作最大可用 RAM。

默认情况下,WiredTiger 对所有集合使用 Snappy 块压缩,对所有索引使用前缀压缩。压缩默认值可在全局级别配置,也可以在集合和索引创建期间基于每个集合和每个索引进行设置。

WiredTiger 内部缓存与磁盘格式中的数据使用不同的表示形式:

  • 文件系统缓存中的数据与磁盘格式相同,包括对数据文件进行任何压缩的好处。操作系统使用文件系统缓存来减少磁盘 I/O。
  • 在 WiredTiger 内部缓存中加载的索引与磁盘格式的数据表示不同,但仍可以利用索引前缀压缩来减少 RAM 使用。索引前缀压缩从索引字段中删除了公共前缀的重复数据。
  • WiredTiger 内部缓存中的集合数据未压缩,并使用与磁盘格式不同的表示。块压缩可以显着节省磁盘存储空间,但必须解压缩数据才能被服务器处理。

通过文件系统缓存,MongoDB 自动使用 WiredTiger 缓存或其他进程未使用的所有空闲内存。

要调整 WiredTiger 内部缓存的大小,请参阅 storage.wiredTiger.engineConfig.cacheSizeGB和 --wiredTigerCacheSizeGB。避免将 WiredTiger 内部缓存大小增加到其默认值以上。

 类似资料: