3

我正在研究一种设计，其中数据的二级索引将使用键中的所有信息构建，在价值方面不需要任何东西。这可能会导致问题吗？

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

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

  • 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 = 单词出现的计数，或者如果扫描大 blob 成本高，则可能是偏移列表
4

2 回答 2

2

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

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

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

于 2012-05-29T17:56:18.100 回答
1

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

于 2013-09-04T23:04:00.237 回答