问题标签 [lsm-tree]

We can create a collection with WiredTiger engine and type=lsm, but this feature is not mentioned in MongoDB documents:

Once insert some documents and add an index, it seems WiredTiger really creates LSM files.

Collection and index value_1 seem like LSM-Tree, but index _id_ still seems like B-Tree.

How can I change engine type of index _id?

我正在阅读 HBase: The Definitive Guide 一书，其中提到，虽然传统的关系数据库以查找速率（B 树）执行更新/删除，但 HBase 以传输速率（LSM 树）执行更新/删除。

我知道 LSM 树是如何工作的，尽管我不明白为什么作者声称更新是以传输速率发生的。当客户端发出特定的更新操作时，相应的条目将被写入内存中的 memstore，并且还将有一个条目将附加到 WAL。memstore 将定期与存储在磁盘上的 HFile 合并。

这如何转化为 HBase 以传输速率执行更新/删除？

RocksDB 级别 1 中的所有键都已排序。因此，我们可以在这个级别快速获得关键。为什么rocksDB还需要将level 1的文件压缩到level 2？

我在 LevelDB 的文档上找到了一个解释：如果同一目录中有太多文件，则在一个目录中打开文件很慢。但是，正如文档中提到的，我们可以使用分片来解决这个问题。我认为分片比压缩容易得多。我对吗？

提前致谢！

在Designing Data Intensive Applications中，Martin 介绍了一种称为 LSM-trees 的数据结构。

主要有 3 个部分：内存中的 memtable（通常是红黑树）、内存中的稀疏索引和磁盘上的 SSTable（又名段）。他们像这样一起工作：

• 当写入发生时，它首先进入内存表，当它变满时，所有数据都被刷新到一个新的段中（所有键都已排序）。

• 当发生读取时，它首先查找内存表。如果该键不存在，它会查找稀疏索引，以了解该键可能驻留在哪个段。见图 1。

• 定期地，压缩发生，将多个段合并为一个。见图 2。

从图 2 可以看出，键在段内排序，但键不在段之间排序。这让我想知道：我们如何保持索引中的稀疏索引 st 键具有增加的偏移量？