Citadel 如何仅使用 BerkeleyDB 键/值存储来构建数据？答案

【问题标题】：How does Citadel structure it's data using only the BerkeleyDB key/value store?Citadel 如何仅使用 BerkeleyDB 键/值存储来构建数据？
【发布时间】：2012-09-10 16:01:05
【问题描述】：

我正在阅读Citadel 文档，它通过mented that it used BerkeleyDB 来存储数据。由于 BerkeleyDB 是一个键/值存储，我想知道他们如何使用如此简单的数据模型来管理所有数据关系（因为 Citadel 做了很多事情）。

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

这让我有机会最终看到使用 NoSQL 数据库建模的完整应用程序。然而，我找不到任何关于他们如何做到这一点的文档。

那么，Citadel 如何仅使用 BerkeleyDB 键/值存储来构建其数据？

它如何将电子邮件映射到用户？
用户与其他用户的关系如何？
如何存储联系人？
如何找到相关的电子邮件回复？
电子邮件如何标记为已查看？

名单还在继续……

【问题讨论】：

@Charles，上面的链接指向 citadel.org。我也只是链接了Citadel这个词。

标签： database-design nosql key-value berkeley-db

【解决方案1】：

相当多的 NoSQL 数据库，就其裸露形式而言，可与文件系统相媲美。给定一个键（=路径），你会得到一个数据块（=文件内容）。其余的大致归结为调整和额外功能；

一个命名空间中有很多（数十亿）键？（HBase、Riak、BerkeleyDB、...）
是否支持多 TB 值？ (Amazon S3) 或针对许多较小的 (Zookeeper) 进行调整
不透明的值？有些数据库不查看它们（HBase、BerkeleyDB），有些则查看（CouchDB）。

目前似乎最流行的事情是进行键扫描（HBase、Cassandra、CouchDB，我相信还有 BerkeleyDB），您可以在其中请求您感兴趣的键间隔，例如。 “从foo@bar:emails:folderName:00000000 到foo@bar:emails:folderName:999999999”。这通常会返回在两者之间的 ASCIIbetic 间隔中的键和/或值的列表。因此，您可以在平面命名空间中模拟类似文件的层次结构。

下一个问题是并发性。非常简而言之，大多数 NoSQL 数据库都放弃了 ACID，以支持可扩展性和/或可用性。查看CAP Theorem了解更多详情。

总而言之，在这么短的时间里很难做到主题公正，所以我真的建议你自己研究一下。

挑选一些开源项目（OpenTSDB 以一种有趣但显而易见的方式做事）。或者自己在 NoSQL 上构建一些东西。

【讨论】：

是的，我最感兴趣的是您的 key:0 to key:999 示例。获得一系列键是一个有趣的想法。 Redis 等系统也支持映射、哈希和列表。另一个实际使用 key->value 的例子是为每个用户帐户创建两个值，例如 user:99 => user@email.com 和 user:user@email.com => 99，以便您可以根据 ID 或电子邮件找到用户（在现实生活中您会拥有更多）。基本上，我只是好奇 Citadel 如何使用这样的简单商店来模拟来自给定用户的所有电子邮件等复杂关系。

【解决方案2】：

我不久前研究了 Amazon Simple DB，我怀疑 BerkleyDB 的做法可能有些类似。

键和值都是 BLOBS。基本上你可以在那里存储任何东西。让我们根据您列出的一些观点/问题举个例子。

我将介绍的要点如下：

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

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

示例可能如下所示：

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 的强大之处在于可以存储任何内容，并且行与行的结构也可以不同。这也是不利的一面。由于没有适当的文档就无法解释数据，因此从结构的角度来看，这些类型的数据库很难理解。它们实际上可以包含任何内容。

希望它现在在某种程度上有意义。

【讨论】：