#cursor #node #traits #group #implemented #local

fog-db-traits

雾数据库实现所需的数据库特性

3 个版本

0.0.2 2023年8月11日
0.0.1 2023年8月7日
0.0.0 2023年8月5日

#1987数据库接口

MIT/Apache

54KB
679

雾数据库接口

实现雾数据库有多种方式,此 crate 致力于创建一个用于处理雾数据库的通用 API。它定义了

  • 用于同时、流式导航本地和远程数据库的游标 API。
  • 用于修改本地数据库的事务 API
  • 用于将访问策略设置到数据库中的证书和策略 API
  • 用于打开到远程数据库节点的连接组的组 API

lib.rs:

此 crate 定义了雾数据库(FogDB)的通用实现接口。

数据库

FogDB 数据库由一组不可变的文档集合组成,每个文档通过其哈希值引用。文档可以通过这些相同的哈希值链接到其他文档。数据库保持一组名为“根文档”的集合,并且任何可以通过从这些根文档通过哈希链接访问的文档也将保留在数据库中。换句话说,如果您可以从根文档访问一个文档,它将保留在数据库中。如果无法访问,它将从数据库中移除。这些链接也可以在事务中“弱化”,就像大多数引用跟踪垃圾收集器一样。

文档可以遵循一个 模式,该模式约束文档的格式并提供有关如何压缩以存储的提示。这些模式允许预先验证文档是否可以反序列化为数据结构,并让系统提前知道文档中的数据类型。

现在,如果数据库仅仅是不可变的文档,那么处理起来会非常困难。这就是为什么每个遵循模式的文档都可以有 条目,这些条目实际上是附加到父文档下的键前缀的小型文档。这些条目不是通过它们的哈希值查找,而是通过在父文档上运行 查询 来找到的 - 在 FogDB 中,此查询将返回匹配条目的序列,并且将在未来找到更多条目时保持活动状态。

条目格式也受父文档模式的约束,这使得它们在数据库中处于一个有趣的位置,也是FogDB多模态的原因。

  • 从文档导向的角度来看,它们是一组所有匹配相同模式的文档。
  • 从关系数据库的角度来看,父文档与条目键是表引用,条目是表中的记录(或条目,明白了吗?)。
  • 从图数据库的角度来看,文档是节点,条目是边。

而不是提供所有这些预期的访问API,FogDB提供了一个基础,可以在其上构建这样的API。

事务:修改数据库

数据库有三种修改它的方法

  • 通过改变名称到哈希映射来修改根命名文档集。
  • 通过添加或删除模式文档来修改存储的模式集。
  • 在数据库上执行事务

事务是更改数据库的最常见方式。它们遵循ACID属性,所以当一个事务被提交时,要么所有事务部分同时完成,要么整个事务被拒绝。最常见的是,如果在尝试删除已删除的条目时可能会失败 - 这就是如何在数据库上执行比较和交换类型事务的方式。

事务可以做以下事情

  • 将文档添加到数据库中
  • 弱化/强化文档哈希链接
  • 将条目添加到数据库中,可选地设置生存时间或访问策略
  • 修改条目的生存时间或其访问策略
  • 从数据库中删除条目

文档不能直接删除;相反,当它们从命名根文档中不可达时,它们会自动进行垃圾回收。

请注意,所有事务都仅在本地FogDB实例上执行;这遵循了系统只能修改自己的规则,而其他数据库节点如何修改自己以匹配它们所希望的则取决于它们自己。

游标:读取数据库

数据库通过[cursor][cursor]接口访问。游标可以打开在连接到其他数据库中或数据库上。游标必须从一个特定的文档开始,可以将其视为始终“在”一个文档上。每个文档都可以包含其他文档的哈希值;游标可以通过“前进”函数调用跟踪这些值。或者,可以“分叉”一个新的游标到链接的文档。通过这种方式,可以创建许多游标以更快地遍历文档树。

游标还可以用来执行查询,这会消耗游标并将其转换为CursorQuery(可以通过回滚来获取游标)。这会产生从游标所覆盖的文档中流出的条目。

查询只是一个带有可选首选排序顺序的fog-packQuery,用于返回的条目结果。如果条目有指向文档的哈希链接,可以使用包含的ForkSpawner来“分叉”新的游标。

这里变得有趣:如果在Group上打开了一个光标,那么任何满足该组要求的远程数据库也可以被光标读取。这样,可以同时使用多个数据库来检索文档和提供查询结果,这也是为什么每个查询结果都包括其来源数据库的原因。

这意味着,当本地数据库有文档时,文档检索几乎是瞬间的,但光标可以无限期地搜索远程数据库以找到具有请求文档的数据库。通过同时启动许多光标,网络可以使用整个远程数据库群来检索文档。

组:连接到其他数据库

每个FogDB实例作为一个单独的节点存在,它可以使用任何数量的网络协议与其他节点通信。这使得[cursor]接口可以同时使用多个远程数据库来检索文档和获取查询结果,并使数据库的部分可以依次暴露给其他节点。

通过使用打开一个组和使用组规范来连接到其他节点。这个规范限制了组将找到其他节点的网络类型,它如何找到和连接到它们,以及节点是否必须作为策略的一部分进行身份验证(参见策略和证书)。

节点发现可以限制在这些近似网络类别中

  • 机器:同一台计算机上其他运行中的FogDB实例之间的通信。
  • 直接:直接机器到机器的联网,没有交换机或路由器。主要例子是WiFi Direct。
  • 本地:本地网络。局域网、自组织网络和其他物理上接近的联网系统属于此类。
  • 区域:不是互联网的一组本地网络。校园网络和城域网属于此类。IPv6 "组织级"多播作用域也适用。
  • 全球:全球互联网。

一旦打开一个组,各种底层网络协议将尝试建立一组符合组规范的节点,并努力为该组设置和维护节点发现机制。

网关:使数据库远程可用

当一个组建立时,仅通过数据库节点进行通信是不够的。每个节点都必须选择要向远程节点暴露数据库的哪些部分,这是通过创建网关来完成的。网关允许远程节点在网关打开时从特定文档开始打开数据库光标。

网关提供了轻松访问数据库的手段:从起始文档可以到达的任何内容都可以被组中的远程节点访问。也可以在到达的文档上执行查询。条目可以具有节点必须匹配的附加访问策略才能获得条目;否则它将被跳过。

当通过网关对特定文档执行查询时,您可以可选地挂钩到查询并手动提供查询结果。这允许动态生成查询响应,并可用于从查询系统构建RPC-like机制。

策略和证书

策略是FogDB对数据库访问范围进行限制的方式,并利用雾包的身份来实现。身份是一个公钥和私钥的配对,可以用来签署文档和条目,通常用来建立唯一的身份。

节点可以使用这些长期签名密钥在网络中标识自己。完整的[节点地址][NodeAddr]由这样的长期密钥和一个在每次创建组时由每个网络协议重新生成的临时密钥对组成。并非所有节点都会拥有这些身份,但在加入任何实施策略的组时都是必需的。

身份可以用来签署一个特殊的文档,称为证书。证书通过其签署者、主题身份、作为上下文的哈希值和密钥字符串来识别。证书是不可变的,但可以使用相同的签署者/主题/上下文/密钥组合创建新的证书来替换旧的证书——这也被视为撤销证书的方式。有关更多信息,请参阅文档

证书本身没有任何作用,但与策略结合时,它们可以委派访问权限。策略可以像允许的身份证列表一样简单,但也可以包括策略链,这允许使用证书来建立权限。

策略和证书会自动在数据库中传播;它们必须作为网络协议的一部分积极检索或交换。FogDB没有指定任何特定的机制来处理此操作,将其留给应用程序和网络协议来传播证书和设置策略。假设在FogDB设置中,证书将被存储在数据库中并用于检查策略。

依赖项

~13MB
~255K SLoC