Citadel如何仅使用BerkeleyDB密钥/值存储来构造它的数据？

Question

我正在阅读城堡文档，它是用来存储数据的它使用了BerkeleyDB。由于BerkeleyDB是一个关键/值存储，我想知道他们如何使用这样一个简单的数据模型来管理所有的数据关系(因为Citadel做了很多事情)。

CREATE TABLE citadel (
  key LONGBLOB INDEX,
  data LONGBLOB
);

这给我提供了一个机会，让我终于可以看到一个使用NoSQL数据库建模的完整应用程序。然而，我没有找到任何关于他们是如何做到这一点的文档。

那么，如何使用仅使用键/值存储的BerkeleyDB构造它的数据呢？

• 它如何将电子邮件映射给用户？
• 用户与其他用户的关系如何？
• 联系人是如何存储的？
• 如何找到相关的电子邮件回复？
• 电子邮件是怎么标记成假的？

名单还在继续，然后.

Answer 1

相当多的NoSQL数据库以其简单的形式与文件系统相媲美。给定一个键(=path)，您将得到一小块数据(=文件内容)。其余的大致归结为调优和额外的功能；

• 一个名称空间中的大量(数十亿和数十亿)键？(HBase，Riak，BerkeleyDB，.)
• 支持多TB值？(亚马逊S3)或调到许多较小的(动物园管理员)
• 不透明的值？有些数据库不看它们(HBase、BerkeleyDB)，而其他数据库则不看(CouchDB)。

目前看来最流行的方法是做键扫描(HBase，Cassandra，CouchDB，以及，我相信，BerkeleyDB)，在这里你需要一个你感兴趣的键的间隔，例如。“从foo@bar:emails:folderName:00000000到foo@bar:emails:folderName:999999999”。这通常返回一个键和/或值的列表，这些键和/或值位于两者之间的ASCIIbetic间隔中。因此，您可以在平面命名空间中模拟类似文件的层次结构。

下一个问题是并发性。非常简单，大多数NoSQL数据库都放弃ACID，以支持可伸缩性和/或可用性。有关更多细节，请查看帽定理。

总之，在这么短的篇幅内很难做到主题公正，所以我建议你自己去研究。

分开选择一些开源项目(OpenTSDB以一种有趣而又明显的方式做一些事情)。或者自己在NoSQL上构建一些东西。

Answer 2

不久前，我使用了Amazon，我怀疑BerkleyDB可能正在做一些类似的事情。

关键和价值都是小问题。基本上你可以在里面储存任何东西。让我们以你列出的一些观点/问题为例。

我将讨论以下各点：

• 它如何将电子邮件映射给用户？
• 用户与其他用户的关系如何？

与关系数据库一样，键值必须是唯一的，因此让我们假设用户id/用户名是唯一的。因此，我们可以有一个键值，如admin、jdoe、serviceadmin等作为键。因为我们可以在value字段中存储任何内容，所以我们可以存储一个XML文档，例如在value字段中。

一个示例可能如下所示：

Key:
    admin
Value:
     <user>
           <emaillist>
                <email>admin@server.com</email>
           </emaillist>
           <relatedusers>
                 <relateduser>
                          <name>jdoe</name>
                          <relationship>someidentifier</relationship>
                 </relateduser>
                 <relateduser>
                          <name>serviceadmin</name>
                          <relationship>someidentifier</relationship>
                 </relateduser>
           </relatedusers>
      </user>

由于XML可以以多种方式描述数据，这可能是一个非常简单的例子，说明可以实现什么。但是，您可以在其中存储一些二进制数据格式，这种格式与XML非常相似，可以以某种方式检索和整数。类似位1是用户的活动状态，等等。

NoSQL的强大之处在于它可以存储任何东西，而且每一行的结构也可能不同。这也是不利的一面。由于没有适当的文档就无法对数据进行集成，所以从结构的角度来看，这些类型的数据库很难理解。它们可以包含任何东西。

希望这在某种程度上是有意义的。