09 | Bigtable（二）：不认识“主人”的分布式架构

徐老师好，在Bigtable论文的第 7 部分“性能评估”里写道： Each random read involves the transfer of a 64 KB SSTable block over the network from GFS to a tablet server, out of which only a single 1000-byte value is used…… Random and sequential writes perform better than random reads since each tablet server appends all incoming writes to a single commit log and uses group commit to stream these writes efficiently to GFS. 随机写和顺序写的性能旗鼓相当，不仅在单台tablet server上表现类似，在tablet server集群上表现也几乎一样。原因是它们都会先写commit log，同步修改内存中的数据，异步修改SSTable中的数据。随机写和顺序写的差异在于SSTable的变更，由于这个操作被异步执行，所以它们的性能没有差异。 如果SSTable的不缓存在tablet server上，随机读的性能非常差，比写入操作几乎慢一个数量级。原因是不管要实际需要多小的数据，都需要从GFS上加载64k的SSTable块数据。它的瓶颈不在于tablet server的多少，而在于从GFS上读取数据。 我在学习今天的课程和阅读Bigtable论文的时候，有三个疑问： 1.课程中提到通过外部服务去监控Master的存活，可能会导致系统中出现两个Master，那么GFS没有这个问题吗？如果有的话不会造成严重的后果吗？ 2.当我向bigtable写入数据时，metadata的三层结构会如何变更？变更的过程如何避免加锁？如果需要全局锁的话，我想读写性能肯定上不去。 3.随机读比写入操作慢一个数量级我还是很惊讶，因为写入操作的commit log需要写入GFS，同样有GFS操作，怎么能差出一个数量级？

METADATA 的一条记录，大约是 1KB，而 METADATA 的 Tablet 如果限制在 128MB，三层记录可以存下大约 (128*1000)2=234 个 Tablet 的位置，也就是大约 160 亿个 Tablet =============================================》 这个是如何算出来的？

问老师： 10多年前的Bigable架构是否是一种符合当下潮流的“存储和计算分离”的架构？存储GFS做得够了，就用GFS单独存，前面哪个tablet压力大可以调度出来多一点。 当下则是objcet storage又便宜又可靠，不要share nothing本机再做一遍存储了，都交给object storage

Bigtable数据随机读写慢，我想到的原因是：其一是个三层 Tablet 信息存储的架构，读写有多次网络请求。其二是tablet的分裂和合并，使数据产生迁移。

感觉这一片的三层结构的插图有点抽象，希望老师能够再解释一下

3层b+tree结构的metadata存储tablet个数的计算: 1. 第1层为根节点，第2层每个元素指向的是一个tablet，因此总存储tablet个数实际上是2层b+tree存储元素的总个数。 2. 一个tablet元素个数 = (128 * 1024KB) / 1KB = 2 ^ 17，即根节点可以存储这么多元素 3. 根节点的每个元素又指向了一个tablet，因此2层b+tree存储个数= 2^17 * 2^17 = 2 ^ 34

随机读，最差情况下，要网络走查元数据+从gfs读出来，gfs一读一block就是64mb，一个key value大小往往远小于这个数字。写的话就没这个问题，读内存也会快，顺序读的话key排序+ gfs支持得本来也好。相比之下，随机读显得很糟糕了

随机读最后只落在一台sever上，不能并行，再加上一次读取转换成了串行的三次读，自然相较而言是慢的。

描述方式太过抑扬顿挫了，结构感不够。

tablet迁移是怎么搞的？ 迁移会带来短时间不可以用吧？