FoundationDB Record Layer: A Multi-Tenant Structured Datastore

FoundationDB Record Layer: A Multi-Tenant Structured Datastore 是苹果公司在 SIGMOD 2019 上发表的一篇论文,介绍他们在 FoundationDB 之上建立的一层结构化存储。

FoundationDB 和 FoundationDB Record Layer 的代码都在 Github 上开源了。

TL;DR

  • FoundationDB 是苹果公司开源的一个分布式 KV,支持水平扩展高可用可串行化隔离级别的分布式事务
  • FoundationDB Record Layer 是建立在 FoundationDB 之上的类关系模型的结构化数据层,支持多租户,以 library 方式提供给应用。
  • Foundation Record Layer 并没有实现 SQL。论文提到,以后可能在 FoundationDB Record Layer 之上实现 SQL。

设计目标

FoundationDB Record Layer 的目标是:

  • 支持水平扩展(horizontal scalability)
  • 高可用(high availability)
  • 分布式事务( distributed transaction)
  • 多租户(multi-tenancy)
  • 类关系模型的结构化存储(structured data storage)

前三点其实都由 FoundationDB 实现了。所以,FoundationDB Record Layer 的重点是实现多租户类关系模型

整体架构和多租户

FoundationDB Record Layer 的架构(图片来自论文)

FoundationDB Record Layer 在设计上是完全无状态的(stateless),并且是以 library 的方式直接链接到应用程序中。

Providing isolation between record stores is key for multi-tenancy.

On the data level, the keys of each record store start with a unique binary prefix which defines a FoundationDB subspace.

FoundationDB Record Layer 的租户粒度是 logic database,也叫 record store,其实就是一段逻辑上连续(前缀一样)的 key-value。
如上图所示,FoundationDB Record Layer 的整体架构:

  • 应用程序(Application)通过 library 的方式使用 FoundationDB Record Layer。
  • 一个 record store 包含 record、indexes 和 metadata,它们都被编码成一段连续(前缀一样)的 key-value,存储在 FoundationDB。
  • MetaData Store 主要存储的是 schema 的定义,可以保存到 FoundationDB 或者其他存储。大部分情况下,这些数据都会被 cache 在 client。

CloudKit 的架构(图片来自论文)

论文中举了一个使用 FoundationDB Record Layer 的例子:苹果公司内部的 CloudKit 框架。
CloudKit 使用 FoundationDB Record Layer 管理数据:一个用户(User)的一个应用(Application)的数据被组织成一个 record store(租户)。所以,CloudKit 使用 FoundationDB Record Layer 维护的租户数量为:用户数 * 应用数,数量上大概在数十亿级别。

类关系模型

这一块的内容,介绍了 schema 的定义和维护,重点内容是和索引相关的,包括 FoundationDB Record Layer 实现的几种索引类型和提供给应用自定义索引的能力。

Schema 的定义和维护

Records in a record store are Protocol Buffer messages and a record type is defined with a Protocol Buffer definition.

FoundationDB Record Layer 通过 Protocol Buffer message 来定义 schema,同时支持多种内置的索引类型。为了适应各种业务需求,FoundationDB Record Layer 在设计上提供了一定的扩展性,应用可以通过类似插件的方式实现自己的索引类型。

在 FoundationDB Record Layer 里,“索引(index)”是一个更宽泛的概念。我们一般提到数据库索引,在 FoundationDB Record Layer 这里被成为 VALUE indexes。
为了实现各种类型的“索引”,FoundationDB Record Layer 引入了两个概念:key expression 和 index maintanance。

key expressions

Indexes are defined by an index type and a key expression which defines a function from a record to one or more tuples consumed by the index maintainer and used to form the index key. The Record Layer includes a variety of key expressions and also allows clients to define custom ones.

Index maintenance

Defining an index type requires implementing an index maintainer tasked with updating the index when records change.

简单来说,key expression 就是一个根据 record 生成 index-key 的生成器。而 index maintanance 是用来当 record 发生变化时维护对应的索引。
这两者类似一个拦截器,拦截每一个 record 的变化信息,生成相应的 key-value。只要经过 key expression 和 index maintanance 生成的 key-value,在 FoundationDB Record Layer 里都被称为“索引”。

Online index building

在一个 schema 新增一个索引之后,需要在线对旧的 record 生成对应的索引。
在线生成索引的逻辑分三步执行:

  1. 将索引的状态设置为"只写"。此时,所有前台的写操作(insert/update/delete)都会更新相应的索引。
  2. 后台任务异步更新旧记录的索引。
  3. 异步更新旧记录的索引完成之后,将索引设置为“读写”。

关于分布式数据库的在线 schema 变更,推荐一篇更详细的论文:Online, Asynchronous Schema Change in F1

索引类型

FoundationDB Record Layer 内部实现了 5 中类型的索引:VALUE Indexes,Atomic Mutation Indexes, VERSION Indexes, RANK Indexes 和 TEXT Indexs。此外,应该可以通过 FoundationDB Record Layer 提供的扩展机制实现自己的“特殊索引”。

VALUE Indexes

The default VALUE index type provides a standard mapping from index entry (a single field or a combination of field values) to record primary key.

其实 Value Indexes 就是我们日常经常提到的“索引”、“唯一索引”:(field0, field1 ... fileldN) -> (primary key)

Atomic Mutation Indexes

Atomic mutation indexes are implemented using FoundationDB's atomic mutations.

These indexes are generally used to support aggregate statistics and queries.

简单说,所谓“原子更新索引”,其实就是存储多了一个/多个 key -> 统计信息 的数据,这些信息使用了 FoundationDB 提供的原子更新能力来维护,用来支持简单的聚合查询。这些 key 可能成为热点数据,进一步成为系统性能的瓶颈。
FoundationDB Record Layer 支持的 Atomic Mutation Indexes 有:

  • COUNT - number of records
  • COUNT UPDATE - times of field has been updated
  • COUNT NOT NULL - records where a field isn't null
  • SUM - summation of a field's value across all records
  • MAX (MIN) EVER - max(min) value ever assigned to a field, over all records, since the index has been created

VERSION Indexes

VERSION indexes are similar to VALUE indexes in that each has an index entry that maps to a primary key. However, a VERSION index allows the index's key expression to include a special "version" field...

这类索引和 VALUE indexes(普通的索引、唯一索引)类似,不过索引上会增加多一个版本号。这个版本号是单调递增的。VERSION Indexes 向应用层暴露了 FoundationDB 集群的事务执行顺序。应用可以利用这个来实现 change-tracking。

RANK Indexes

The RANK index type provides efficient access to records by their ordinal rank (according to some key expression) and conversely to determine the rank of a field's value.

RANK indexes 是用来高效实现类似"第 k 个"这种查询的。

TEXT Indexes

The TEXT index enables full-text queries on the contents of string fields。

字符串类型字段的全文索引。

参考文章/推荐阅读

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,117评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,963评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 107,897评论 0 240
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,805评论 0 203
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,208评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,535评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,797评论 2 311
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,493评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,215评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,477评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,988评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,325评论 2 252
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,971评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,055评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,807评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,544评论 2 271
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,455评论 2 266

推荐阅读更多精彩内容