分布式存储图解_常见分布式基础设施系统设计图解（二）：分布式数据库

从大致的非功能需求角度来说，作为一般的分布式持久化存储系统，这样三个需求从重要性依次排列：

Durability > Availability > Performance

即最重要的是，数据绝对不能丢失，其次是要一直提供服务，最后才是要保持一定的性能。当然，有了上述基础以后，我们还可以谈论任何分布式存储系统都涉及的重要特性，比如一致性。最后，作为特定的存储系统——“数据库”，我们还常常谈论一些特定的特性，比如权限管理和事务控制等等。

下面拿的是 Bigtable 来举例的，它建立在 GFS 这样的分布式文件系统上面，有一定代表性。

图中展示的是一个简单的写数据的流程，虚线是控制流，实线是数据流。

客户端先去 Lock Service 获取写锁，如果获取到了，一并也会获得 Tablet Server 的地址等 metadata，接着就往 Tablet Server 里面写数据。

数据的持久化和冗余，是通过 GFS 的 Chunk Server 来实现的，也就是说，Tablet Server 持有 GFS 的客户端来实现对文件系统的读写。客户端不合 GFS 直接打交道，而 GFS 并不关心 Bigtable 层面的概念，只关心文件 block 的读写。图中我省掉了 GFS 的 Master 结点。

在数据写入完成后，客户端告诉 Lock Service 释放锁。

Bigtable 的数据分成这样几种存放形式：一种是稳定的、有序的数据，sharding 后存放在 SSTable(Sorted String Table)，每一个 SSTable 有自己的 index 和 bloom filter，前者用来加快数据定位，后者用来快速存在性判断(尤其是它判断得到不存在的结果的话，它的正确率是 100%)。Tablet Server 的内存中也会有部分 index 和全部 bloom filter 的拷贝，以提高数据定位的效率。第二种是由于数据增加、修改等原因，未和上述一起排序的 “额外” 的数据，这些数据一开始是存放在 Tablet Server 的内存中的，使用一个 Skip List 来维护，它们定期归并到上述的 SSTable 中去。为了防止这些数据丢失，需要使用 WAL(Write Ahead Log)持久化到 GFS 中，这个过程是很快的。这样这些后来的新增和修改操作既保证了效率，又不丢失持久性。

由于 GFS 的特性，对数据追加的操作可以高效完成，但是数据修改却往往不是(比如某个值的修改导致其占用的空间增大，原地修改将导致整个文件的数据从该值的位置开始向后平移)。这个限制非常关键，Bigtable 的数据修改一般都是通过追加写操作来完成，于是一条记录可能存在多个版本，在内存中和多于一个的 SSTable 中都存在，但只有最新的一条才作数。因此对于某条数据的读取，是有可能从多个地方读取的，即 Tablet Server 的内存和多个 SSTable。每隔一定时间，这些 SSTable 可以做一次归并整理，剔除过期数据。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat