MongoDB上限集合

Question

我不太确定问这个问题是否正确，实际上有两个问题。

1. 封顶收藏的潜在用途是什么？(除伐木外)
2. 无法分割上限集合，但可以复制它们。在网络分区和重新加入后，如何同步/合并上限集合？

Answer 1

封顶收藏的潜在用途是什么？(除伐木外)

在以下情况下，有上限的集合对于特定的用例非常有用：

• 您希望限制以FIFO (先入先出)顺序保留的数据量。
• 您希望确保数据按插入顺序存储。
• 您没有导致文档大小增加的更新。
• 您不需要手动删除文档。
• 您可能希望使用可裁剪光标来根据插入到集合中触发某些活动。

这些特性中有几个(例如，不允许文档的大小增长)听起来非常严格，但原始设计有几个重要的动机:为原始MMAP存储引擎启用尽可能高的插入率，并确保在复制时上限集合中的文档具有相同的大小。MMAP存储引擎为整个有上限的集合分配文件，以最小化存储碎片，并避免在集合达到其最大上限大小之前耗尽磁盘空间的担忧。

MongoDB 3.0添加了一个存储引擎API，在MongoDB 3.2中，用于新部署的默认存储引擎从MMAPv1更改为WiredTiger。所有存储引擎目前都支持上限集合作为MongoDB API的一部分，但是实现的内部和效率与原始的MMAP存储引擎不同。

由于有上限的集合实际上是大型的固定大小的循环缓冲区，最明显的用例与日志记录有关。通常，一定数量的“最近”数据需要以FIFO的方式保存和老化，而不是无限期地增长。

MongoDB依赖于一些内部用例的上限集合，如：

• local.startup_log是一个10 up的上限集合，它在启动时捕获一些关于本地mongod实例的诊断/环境信息。
• 复制操作日志，每个复制集成员用来记录本地应用的所有写入操作的幂等列表。默认的oplog尺寸基于空闲磁盘空间的%，但通常最高可达50 GB。
• 切分群集config.changelog，它是最近分片集群平衡活动的10 of上限集合。

可以想象，在希望数据自动老化(即FIFO缓存或队列)的情况下，可以使用有上限的集合，但是带有实时(TTL)索引的正常集合通常提供更大的灵活性以及对文档过期的控制。

无法分割上限集合，但可以复制它们。在网络分区和重新加入后，如何同步/合并上限集合？

切分跨多个服务器对集合进行分区，这与上面列出的几个上限集合设计目标背道而驰。复制是对副本集的所有成员进行写入操作的异步副本(但已排序)。

在复制集环境中，向有上限的集合写入与所有其他写操作相同的复制机制传播。根据复制延迟，次要文件上的数据最终是一致的，但仍然保留插入顺序和其他有上限的集合属性。副本集只允许单个主节点，因此，在网络分区的情况下，主节点将只为具有大多数健康节点的分区选择。分区少数部分上的任何孤立成员都将保持为只读次要文件，直到它们能够重新加入副本集并尝试恢复复制为止。