标签: lsm-tree

最近我一直在研究数据库中常见的索引结构，比如 B+-trees 和 LSM。我对点读/写/删除/压缩如何在 LSM 中工作有一个可靠的处理。

例如（在 RocksDB/levelDB 中），在点查询读取时，我们将首先检查内存索引（memtable），然后是从最近到最近的一些 SST 文件。在 LSM 的每个级别上，我们将使用二分搜索来帮助加快查找给定密钥的每个 SST 文件的速度。对于给定的 SST 文件，我们可以使用布隆过滤器快速检查密钥是否存在，从而节省更多时间。

我没有看到范围读取具体是如何工作的。LSM 是否必须在每个 SST 级别（包括 memtable）上打开一个迭代器，并在所有级别上同步迭代，以返回最终的排序结果？它是否仅作为一系列点查询实现（几乎绝对不是）。是否先拉出所有潜在的键，然后再排序？希望有人在这里有任何见解。

我无法找到有关该主题的太多文档，任何见解在这里都会有所帮助。

我们可以使用WiredTiger引擎创建一个集合type=lsm，但是MongoDB文档中没有提到这个功能：

db.createCollection(
    "test",
    { storageEngine: { wiredTiger: {configString: "type=lsm"}}}
)

一旦插入一些文档并添加索引，WiredTiger 似乎确实创建了 LSM 文件。

db.test.insert([
    { value: 1},
    { value: 2},
    { value: 3}
]) // Done in 16:04
db.test.createIndex(
    { value: 1 },
    { storageEngine: { wiredTiger: {configString: "type=lsm"}}}
) // Done in 19:59

$ ls -ltr
...
-rw-r--r--. 1 mongod mongod        16384 Jan 15 16:04 collection-0-1708338433081558809-000002.lsm
-rw-r--r--. 1 mongod mongod        16384 Jan 15 16:04 index-1-1708338433081558809.wt
-rw-r--r--. 1 mongod mongod        16384 Jan 15 19:59 index-3-1708338433081558809-000002.lsm

集合和索引value_1 …

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

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

提前致谢！