LSM 树查找时间答案

【问题标题】：LSM Tree lookup timeLSM 树查找时间
【发布时间】：2013-08-11 00:27:56
【问题描述】：

对于简单的搜索查询（例如查询单个 WHERE 子句），日志结构合并树的最坏情况时间复杂度是多少？

是 O(log N) 吗？ O(N*Log N)？还有什么？

对于多重查询，例如在键值数据库中搜索多个 WHERE 子句怎么样？

【问题讨论】：

我认为很难估计像 LSM 树这样的复杂数据结构的搜索复杂度，因为它有不同的组件，复杂度取决于您如何管理这些组件中的不同操作。例如，由于 LSM 具有多个层，并且每个层的大小各不相同。现在取决于您是喜欢检查每一层中是否存在密钥，还是使用其他数据结构（如布隆过滤器）进行成员资格测试，可能会使整体复杂性有所不同。
LevelDB（基于 LSM 的轻量级键值存储）具有 O(lg N) 搜索性能和非常大的分支因子。但是，我相信他们通过不同的优化实现了它。

【解决方案1】：

我也有同样的疑惑。

如果你有一系列的树，每次都变小一个常数因子，并且你需要在所有树中搜索一个键，成本似乎是 O(log(N)^2)。

假设第一个（二叉树）树需要 log_2(N) 个分支来到达一个节点。第二个可能是一半大小，并采用 (log_2(N) - 1) 个分支来查找节点。最小的树的大小将是一些 O(1) 常数，总共大约有 log_2(N) 棵树。对系列求和得到 O(log_2(N)^2)。

但是，我想知道是否有一些更聪明的方案，其中任意单键查找、插入或删除的摊销成本为 O(log(N))，但还没有找到答案.

【讨论】：

【解决方案2】：

对于由 LSM 树索引的简单搜索，它是 O(log n)。这是因为 LSM 树中最大的树是 B 树，即 O(log n)，其他树是 B 树的子集，或者在内存树的情况下，效率更高的树，并不比O(log n)。树的数量是一个常数，所以不会影响搜索时间的顺序。

【讨论】：