定位是 分布式数据库. 特点: 提供 hashed/ordered tables. 中心化管理、地理位置复制、自动负载均衡.

record 级别的 master-follow replica机制. 列举了 应用的不同一致性模型: read-any, read-critical, read-latest, write, test-and-set-write(乐观锁),

支持 Bundled updates, notification,

热点问题如何解决?

系统架构

tablet controller、router、storage unit.

router: 1. 维护 record -> tablet -> storage unit 的 internal mapping. 无论是 hash 还是 ordered 都是转换成 tablet. internal map 从 tablet controller 获取. soft state. 2. 包含 scatter-gather engine, 负责处理 multi-record, 并行将多个 record 发送到多个 storage unit. 采用stream模式. (服务端模式, 而不是客户端模式, 因为链接的资源消耗). 以及 topK 的实现. 但是不支持 join/aggeration 等这些复杂的操作 tablet controller: 负载均衡 tablet, active/standby.

region 为单位进行管理. 基于 pub/sub 进行弹性容错和复制. data tables 数据分片组织成 tablet, 每个server有 上千个 tablet, 在region 范围内 tablet 只会存储在一个 server上, 每个tablet只有 几百MB 或者 几GB(包含几千个记录), tablet会进行 rebalance.

ordered tables 使用 MySQL(innodb) 实现, hash tables 使用基于 unix fs-based hash tables. 更新 只需要 写入到message broker 就算成功. 复制通过 message broker 实现异步复制. 复制流程是 ack-all 模式. 跨dc. record 通过 per-record master replica 实现 timeline 有序 (所有的更新都经过 master replica 写入 broker).

比较有意思的是, 每个tablet可能包含 多个集群的key, 通过 per-record 的 master replica 降低延迟. tablet master 负责存储

支持 notification, 通知外部 关于内部状态的变更, 不过是对 table 维度的所有topic 进行订阅

注意, per-record 是为了实现 record 的 timeline 有序, tablet master 是为了保证存储的唯一性.

容灾

tablet controller 会从远程复制迁移, 配合 checkpoint, checkpoint 之后的更新 都会发送过去. 支持 split.

tablet 恢复流程:

  1. tablet controller 向 远程副本(source tablet) 请求copy
  2. checkpoint 发送到 ymb, 保证复制点之后 后续未完成 的 更新 都会同步到 source tablet
  3. source tablet 复制到 目标region

在恢复的过程 也要保证 后续更新同步

问题:

  • pnuts 是几几年的论文, 和 google 对比呢 ?

总结

仅仅支持 hashtable 和 ordered tables 两种, 比较有意思的是, 当时 ordered tables 采用的是 mysql innodb. tablet 以及 tablet controller 的概念 现在看 已经是标配了. 同时支持两种模式, 对于 基于codis 开发分布式kv的小伙伴 可以考虑下. 在测试中, ordered table 的整体延迟都比 hashed table 低

range scan 功能上, mysql innodb 比 rocksdb 更好吗?

bundle updates(社交图谱上的朋友关系的维护), 这个貌似没有更多的展开相关的解决方案, 看上去就是异步两次成功

Epidemic replication ？ 不懂

参考