如果值为空且只有一个键，leveldb 是不是存在结构问题？

Posted 2023-02-23

【中文标题】如果值为空且只有一个键，leveldb 是不是存在结构问题？

【英文标题】：Does leveldb have structural problems if values are blank and there's just a key?如果值为空且只有一个键，leveldb 是否存在结构问题？

【发布时间】：2012-05-25 23:47:58

【问题描述】：

我正在进行一项设计，其中数据的二级索引将使用键中的所有信息构建，而在值方面不需要任何内容​​。这可能会导致问题吗？

我不问是否技术上可以有一个空白值。是否有任何结构后果，例如：添加排序键会使某些树结构失衡？ （我不是说 leveldb 使用树，只是想一个类比 ;-)）

ie：说“主记录”看起来像（空值作为分隔符）

key = uniqueTableID \0 uniqueRowID 值 = 一些字段集合

典型单值字段的二级索引如下所示：

key = uniqueFieldID \0 keyValue \0 uniqueRowID

允许通过部分键 [uniqueFieldID \0 keyValue] 进行迭代，并且如果主记录被删除或键值更改，它还可以轻松找到这些键并删除它们，从主记录的 uniqueRowID 开始工作。因此，可能有多个键值以相同的 uniqueRowID 结尾，但对于以 uniqueFieldID 开头并以 uniqueRowID 结尾的特定组合只能是一个键

唯一的一点是，我不需要在对的值侧放置一个值。

我对这个概念设计非常满意，只是看看是否有人能发现其中的漏洞。例如，如果它会扭曲 leveldb 内部结构导致性能问题。

我预计在一个特定的应用程序中会有数万个这样的键。

作为我们可能想要存储的值的示例，文本字段的辅助词索引可能如下所示：

key = uniqueFieldID \0 keyValue \0 GUID value = 单词出现的计数，或者如果扫描大 blob 的成本很高，则可能是偏移列表

【问题讨论】：

我很好奇当主记录更改或删除时，您如何清理陈旧的二级索引条目。您是否总是在更新或删除之前获取现有记录？

等着看书（开个玩笑）。不，我在决定是否需要在更新时更新二级索引之前比较值。显然，他们需要更新大多数删除（我根据“记录”值检查可选的辅助键是否应该存在）。

什么书（我很感兴趣）？要比较这些值，您是否首先获取旧记录？即使在删除时，您似乎也需要知道字段/值对才能删除相应的索引条目。

Packt 即将推出的 LevelDB 入门。实际上，对于如何存储记录，您可以采用多种不同的方法，尝试对它们进行严格描述的可能性会成倍增加（恼怒的叹息）。例如，假设您将整个“记录”存储在一个主值中，其中“主键”作为其键。如果您当前正在 GUI 中编辑该记录，则将其加载为当前记录，因此无需在删除之前阅读。但是，如果您要进行批量删除，那么是的，您需要读取记录以获取要删除的辅助键。

一定要去看看这本书。第一次读取记录时不会失去原子性吗？

【参考方案1】：

LevelDB 中的键和值是不透明的数组，快速查看constructor of a Slice 的文档会显示如何创建空切片：

// Create an empty slice.
Slice() : data_(""), size_(0)

这对于您没有任何值数据的情况非常有用。

【讨论】：

谢谢。我并没有问这在技术上是否可行，因为这会导致数据存储出现问题，我会尝试在问题中添加细节以进行澄清。

到目前为止，我们还没有发现任何问题，并且我们的数据库中有数百万个没有值的条目。此外，所有存储都是基于键的，并且在大多数情况下会忽略值。 LevelDB 考虑该值的唯一“重要”时间是当它用完特定存储桶中的空间时（因为这些值占用了太多空间）。如果有的话，在大型数据库中使用空值会执行得更快，因为 LevelDB 可以在单个文件中容纳更多键，因此它管理的文件更少。

因为上面评论中的答案打勾！

【参考方案2】：

应该没问题，因为即使 leveldb 也将删除存储为没有值的键。内部 leveldb 对每个 SST 中的键使用和前缀长度编码，这将有助于进一步减少特定情况下的键大小。在您的情况下，唯一的偏差是索引大小。通常，索引大小将是数据块的一小部分（假设键较小且值相对较大），而在您的情况下，索引可能相对较大，因为索引为每个数据块存储一个键。