mil*_*anw 5 indexing key-value openldap kyotocabinet leveldb
因为下面有点长:这是tl; dr; version:快速键和值查找是否存在现有键/值最佳实践,类似于具有持久索引的基于哈希的集合？
我对键值数据库的世界感兴趣,到目前为止还没有弄清楚如何有效地实现以下用例:
假设我们想要序列化一些数据,并通过持久的唯一整数索引在其他地方引用它们.例如:Key = unsigned int,Value = MyData.
数据库应具有快速键查找并确保MyData是唯一的.
现在,当我向数据库插入一个新值时,我可以为它分配一个新的索引键,例如数据库的当前大小,或者为了防止在删除项目后发生冲突,我可以在外部保留一些计数器.
但是,我如何确保不将相同的MyData值插入数据库？到目前为止,它看起来好像这对于键值数据库来说无法有效实现 - 这是正确的吗？即我不希望遍历整个数据库只是为了确保MyData的价值并不在那里已经...
那么实施这个的最佳实践是什么？
对于背景:我在KDevelop上工作,我们使用上面的代码分析缓存.我们实际上有一个上述用例1的自定义实现.如果您对内部感兴趣,请搜索Bucket和ItemRepository,并参阅2以了解ItemRepository的示例用法.
但你可能会同意,这段代码很难理解,因而难以维护.我想将其性能与可能导致更简单代码的替代解决方案进行比较 - 但前提是它不会导致严重的性能损失.考虑到围绕OpenLDAP MDB,Kyoto Cabinet和LevelDB等键值存储性能的炒作,这是我想要开始的地方.
我们在KDevelop中所拥有的 - 据我所知 - 基本上是一种混合磁盘/内存中的哈希映射,它会定期保存到磁盘上(当然,在崩溃的情况下会导致严重的数据损坏等). ).项目基于它们的散列值存储在一个位置,当然,只要散列函数很快,它们也允许相对快速的值查找.增加的扭曲是您还获得某种持久性数据库索引,可用于非常有效地查找项目.
所以 - 长话短说 - 如何用一个关键/价值数据库如LevelDB,Kyoto Cabinet,OpenLDAP MDB来做到这一点 - 你说出来了吗？
听起来您想要做 OpenLDAP 对其平等索引所做的事情。也许这和OrientDB的例子是一样的，我没读过。
主表通过单调递增的整数键（称为entryID）进行索引，并存储数据值。相等索引通过值的散列来索引，并存储与散列匹配的entryID列表。由于散列可能存在冲突，因此相等索引中条目的存在并不能证明唯一性或重复。您仍然需要检查实际值。
如果您使用 MDB、BDB 或其他支持重复键的数据库，一种更快/更简单的方法是仅保留一个表，使用哈希作为键。在 MDB 和 BDB 中都有一个 GET_BOTH 请求，它匹配键和数据以执行获取。如果成功，那么您就可以确定该值已经存在。否则，它允许您保存任何数据值，而不必担心是否存在哈希冲突。
这里需要注意的是，在使用重复键的 MDB 中，值的大小限制为小于磁盘页面的一半。