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

Question

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

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

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

• key = uniqueTableID \ 0 uniqueRowID
• value =某些字段集合

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

• key = uniqueFieldID \ 0 keyValue \ 0 uniqueRowID

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

唯一的一点是，我没有必要在价值一侧设置价值。

我对这个概念设计非常满意，只是检查一下是否有人可以发现它的漏洞。例如，如果它会扭曲leveldb内部导致性能问题。

我希望在一个特定的应用程序中会有成千上万个这样的密钥。

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

• key = uniqueFieldID \ 0 keyValue \ 0 GUID
• value =单词出现的次数，或者如果扫描大斑点是昂贵的，可能是偏移列表

Answer 1

LevelDB中的键和值是不透明的数组，快速浏览constructor of a Slice的文档可以看出如何创建空切片：

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

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

Answer 2

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