Reading

ByteGraph ByteGraph 是字节跳动开发的一个分布式图数据库。之前只是听说过图数据库，但并没有用过，因此在阅读的过程中难免对一些概念理解的不够深入。 为什么字节要开发图数据库呢？因为字节的产品都是社交App，因此用户，短视频，专注，点赞，粉丝所有的这些构成了一个巨大的图。 为什么现有的数据库无法满足呢？ 关系型数据库和文档型数据库显然不适合这样的应用场景，比如要获取两个用户之间的关系，即图中两个节点之间的路径，这个路径可以是关注，可以是都点赞了某个视频，关系型数据库无法满足性能需求。其他的图数据库有的是单机，有的是单 master，都不满足要求，因此需要造轮子。 字节的 Workload 分成了 3 种，比我平时听说的多了一种 OLTP，在线处理，比如一个用户发布了新文章，那么 (user,article),(user,tag), (article,tag) 这三条边就要被插入数据库。 OLAP，在线分析数据，一次需要查询大量数据做分析，比如做风险管理分析。 OLSP，这个第一次听说，Online Serving Processing。比如一个用户点赞了某个视频，那么后台需要实时计算他的喜好，然后推荐类似的视频。 整体架构如下所示： BGE, ByteGraph Execution Engine 负责执行 SQL 语句。 BGS, A cache layer in ByteGraph，负责存储相关。 底层的 KV Stroage 可以选用 RocksDB 或者 TerarkDB。 BGE 使用了 Gremlin 作为解析 query language 的解析器，这是一个专门用于图查询的工具。用户输入的查询语句经过 Gremlin 生成 execution plan 然后传给 BGE。 既然是查询引起，那么就涉及到分布式事务，BGE也是用了 2PC。 上图可以直观的显示 ByteGraph 数据库中所存的数据，可见 KV store 是比较适合存这类数据的，因此 BG 的最底层是 KV store。 ...

Introduction Spanner 数据库中的数据是分片(Shard)分散存储在多个数据中心的，数据是用 Paxos 算法(状态机)保证一致性。如果数据中心发生变化，Spanner 自动做 reshard。 Spanner 中的数据是存储在 schematized semi-relational table 上的。 在 commit 的时候把 timestamp 作为数据的 version。老版本的数据可以被垃圾回收，client 也可以读老数据。 Spanner 有两个特性是一般的分布式系统非常难实现的， 读和写操作的外部一致性。 在一个时间戳下，读操作是全局一致的。 能实现以上两点，是因为 Spanner 可以分配全球范围内保持一致的 commit timestamp。Spanner 的 timestamp 靠 TrueTime API 实现，甚至可以用 GPS 和原子钟来提高 TrueTime API 的精度。 Implementation 一个 Spanner 集群被称为一个 universe，如下图所示 Spanner 被组织成许多个 zone 的集合，zone 是管理部署的基本单元。一个数据中心可能会有多个 zone，zone 也是物理隔离的单元，例如，两个不同应用的数据就会被分散在两个 zone 上。 Zonemaster 把数据分配给 spanserver，spanserver 是真正存数据的地方 Client 从 location proxy 定位数据在哪个 spanserver 上 Universe master 主要是一个管理界面 Placement driver 周期性的与 spanserver 交互，进行负载均衡 Spanserver Software Stack 每一台 spanserver 上会存 100 到 1000 张表，每一张表上都有一个 Paxos 状态机，每一个 Paxos 状态机都会把自己的 metadata 和 log 存在 tablet 上。 ...