mongodb - WiredTiger和就地更新

Question

我有一组用户。每个用户都有一个经常更新的字段“地理位置”（每次用户显著移动）。由于我希望在更新时在文档级别而不是集合级别上实现并发，因此我使用的是wiredtiger存储引擎。
我了解到，使用wiredtiger，文档中的每个更新都会创建一个新文档：
http://learnmongodbthehardway.com/schema/wiredtiger/
WiredTiger不支持就地更新
不过，本文还指出，“尽管[wiredtiger]不允许进行就地更新，但它在许多工作负载下的性能仍然可能优于mmap”。这是什么意思？当我使用wiredtiger时，我必须知道的确切含义是什么？例如，如果没有适当的更新，数据库的大小会快速增长吗？还有其他事情需要注意吗？
我还了解到，mongodb 3.6中的wiredtiger增加了存储delta的功能，而不是重新编写整个文档（https://jira.mongodb.org/browse/DOCS-11416）。这到底是什么意思？
注：另外，我不明白的是，现在大多数（如果不是全部）硬盘驱动器的扇区大小为4096字节，因此您不能只向硬盘驱动器写入4字节（例如），而必须写入4096字节的整个块（因此，请先读取，更新其中的4字节，然后再写入）。由于大多数文档通常小于4096字节，这是否意味着在任何情况下都需要重新编写整个文档（即使使用mmap）。我错过了什么？

Answer 1

在mmapv1存储引擎中，由于文档的索引直接指向文件位置和偏移量，就地更新经常作为优化策略突出显示。将文档移动到一个新的存储位置（特别是在有许多索引项要更新的情况下）对于mmapv1的开销要比只需更新已更改字段的就地更新多。见：Record Storage Characteristics in MMAPv1。
wiredtiger不支持就地更新，因为它在内部使用MVCC (Multiversion concurrency control)，即commonly used by database management systems。与mmap中的简单视图相比，这是一个重大的技术改进，并允许构建更高级的特性，如isolation levels和事务。wiredtiger的索引有一个间接的级别（引用内部记录id而不是文件位置和偏移量），因此在存储级别上的文档移动不是一个明显的痛点。
不过，本文还指出，“尽管[wiredtiger]不允许进行就地更新，但它在许多工作负载下的性能仍然可能优于mmap”。
这意味着，尽管mmapv1可能有一个更有效的就地更新路径，但wiredtiger还有其他优点，如压缩和改进的并发控制。您也许可以构建一个工作负载，它只包含对一些文档的就地更新，这些文档在mmapv1中可能执行得更好，但实际工作负载通常更为多样。确认对给定工作负载的影响的唯一方法是在具有代表性的环境中进行测试。
但是，如果您想为将来做计划，mmapv1与wiredtiger的一般选择是没有意义的：wiredtiger自mongodb 3.2以来一直是默认的存储引擎，mmapv1不支持某些较新的产品功能。例如，mmapv1不支持Majority Read Concern，这意味着它不能用于Replica Set Config Servers（mongodb 3.4+中的分片需要）或Change Streams（mongodb 3.6+）。MMAPv1 will be deprecated在MongoDB（4.0）的下一个主要版本中，当前计划在MongoDB 4.2中删除。
当我使用wiredtiger时，我必须知道的确切含义是什么？例如，如果没有适当的更新，数据库的大小会快速增长吗？
存储结果取决于几个因素，包括模式设计、工作负载、配置和MongoDB服务器的版本。mmapv1和wiredtiger使用不同的记录分配策略，但都将尝试使用标记为自由/可重用的预分配空间。一般来说，wiredtiger在利用存储空间的同时效率更高，并且具有对数据和索引进行压缩的优点。mmapv1allocates additional storage space尝试优化就地更新并避免文档移动，但您可以为工作负载不会随时间改变文档大小的集合选择“无填充”策略。
自从wiredtiger首次在mongodb 3.0中引入以来，在针对不同工作负载改进和调整它方面进行了大量投资，因此我强烈建议使用最新的产品发布系列进行测试，以获得最佳结果。如果您对模式设计和存储增长有特定的问题，我建议您在dba stackexchange上发布详细信息以供讨论。
我还了解到，mongodb 3.6中的wiredtiger增加了存储delta的功能，而不是重新编写整个文档（https://jira.mongodb.org/browse/DOCS-11416）。这到底是什么意思？
这是一个实现细节，它改进了wiredtiger在某些用例中的内部数据结构。尤其是mongodb 3.6+中的wiredtiger可以更有效地处理大文档的小更改（与以前的版本相比）。wiredtiger缓存需要能够返回多个版本的文档，只要这些文档被打开的内部会话（如前所述，mvcc）使用，因此对于具有小更新的大型文档，存储delta列表可能更有效。但是，如果积累了太多的delta（或者delta正在更改文档中的大多数字段），这种方法的性能可能不如维护完整文档的多个副本。
当数据通过检查点提交到磁盘时，仍然需要写入文档的完整版本。如果您想了解更多关于内部的信息，在MongoDB 4.0中，有一系列MongoDBPath To Transactions的视频在开发支持多文档事务的特性之后。
另外，我不明白的是，现在大多数（如果不是全部）硬盘驱动器的扇区大小为4096字节，因此您不能只向硬盘驱动器写入4字节（例如），而必须写入4096字节的整个块（因此，首先读取它，更新其中的4字节，然后写入它）。由于大多数文档通常小于4096字节，这是否意味着在任何情况下都需要重新编写整个文档（即使使用mmap）。我错过了什么？
在不深入了解实现细节并试图解释所有涉及的移动部分的情况下，考虑不同的方法如何应用于正在更新许多文档（而不是在单个文档级别）的工作负载，以及对内存使用的影响（在文档之前写入磁盘）。根据文档大小和压缩等因素，单个I/O块可以表示从文档的一小部分（最大大小16MB）到多个文档的任何位置。
在mongodb中，一般的流程是在内存视图（例如wiredtiger缓存）中更新文档，并在periodically flushed to the data files之前以快速追加日志格式将更改持久化到磁盘。如果o/s只需写入已更改的数据块，那么触摸较少的数据块就需要较少的总体i/o。