2 个版本
0.0.2 | 2019 年 10 月 2 日 |
---|---|
0.0.1 | 2019 年 9 月 10 日 |
#14 in #foundation-db
在 2 个 crate 中使用
180KB
4.5K SLoC
Vinyl
FoundationDB Record Layer 之上的便利层。将允许
- 在代码中定义表和索引
- 查询和插入/删除的 protobuf 通信格式
- 用户账户管理
- 元数据缓存和元数据持久化
- 类似 CloudKit 的 http 层?
Record Layer 已经通过 record_metadata.proto 扩展添加了所有必要的元数据到解析的 protobuf 记录。我们可能需要将这种逻辑从每种语言中提取出来并重新实现,以便我们可以在任何地方使用相同的格式。现在我们只是定义了自己的元数据(作为一种便利),但这可能在将来会改变。
论文及其他地方的笔记
Record Layer 复杂且我在积极学习其结构和特性。这里的笔记旨在参考各种复杂性和考虑。其中一些正在实现,一些暂时被忽略。
确保描述符被验证
这在文档中提到 here。有验证描述符的一般想法。这无疑对可以创建哪些表以及它们如何随时间变化施加了约束。API 应该考虑到这一点
必须在调用 eval(FDBRecordStoreBase, EvaluationContext, FDBRecord) 之前调用 validate(Descriptors.Descriptor),否则可能会发生不良事件。
索引定义和维护
论文,第 5 节
相反,索引被禁用,重索引按第 6 节所述作为后台作业进行。
这是完全由客户端处理还是这里有一些需要考虑的行为。
在表关系中使用主键
所有主键都在同一个索引中。论文第 10.2 节
例如,所有记录类型都有一个单一的扩展,因为 CloudKit 有无类型的非表关联的外键引用。默认情况下,选择特定类型的所有记录需要全扫描,跳过其他类型的记录或维护二级索引。
对于不需要此共享扩展的客户,我们现在支持通过在主键中添加特定类型的前缀来为每种记录类型模拟单独的扩展。
很可能确保这是作为一个配置选项出现或默认支持
lib.rs
:
Vinyl是
依赖项
~5–15MB
~223K SLoC