徐老师好，在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操作，怎么能差出一个数量级？