BigTable 有什么值得称道(牛)的地方?

BigTable 是 Google 在许多产品中使用的一种分布式结构化数据存储系统,被设计用来处理海量数据。
关注者
524
被浏览
23856

9 个回答

Bigtable 论文已经十年了。论文的第一大贡献是编程模型方面,当时大家都还在摸索在这种大 PC 机群环境下存储系统应该提供怎样的编程模型,要简单易理解,满足产品开发需求,又要在实现上能水平扩展支持海量存储。Bigtable 的「排序大表 + Column Family」在当时就不是什么新东西,但被证明了是一个非常成功的设计,能概括从线上到线下很多的业务需求,并且有很好的灵活性和扩展性。到今天 Bigtable 还有极广泛的应用,之后 MegaStore(公开版本是 AppEngine 上的 DataStore) 直接基于 Bigtable 构建,再后来的 Spanner 在单 tablet 上的存储干脆复用了 Bigtable 的版本。

在当时,人们对这种大规模分布式系统环境的认识还并不系统,谈得最多的是 CAP —— CAP 不可兼得是一个定律,但它没有告诉你应该怎么根据业务特点取舍。当时另一个有趣的项目是 Amazon 的 Dynamo, 它基于不同的取舍方向,追求 A 和 P(Bigtable 的 A 并不是特别好),让程序员自己动手解决写冲突问题。从今天看,就不及 Bigtable 的模型成功。(私货:我一直不看好 Cassandra)

在实现上,Bigtable 的另一点贡献是把 LSM (Log-Structured Merge) Tree 这种古老的技术带回前台。它和当时全部机械硬盘的现状以及 GFS 的编程模型极搭。把随机写全部转化为顺序写,实现了非常好的吞吐和即使对线上应用也可以接受的延迟(有坑,论文里就隐藏了坑),只读 SSTable dump 极大简化了设计。用 GFS 解决底层存储备份一系列问题,也大大简化了 Bigtable 自身的实现。SSTable + LSM Tree 这一部分的成果开源在了 LevelDB, 有广泛的应用,也启发了其他的很多开源项目。

Jeff Dean 自己对 Bigtable 最不满意的是没有提供跨行事务支持。这个故事很有趣:跨行事务天生是不可扩展,你没它办法,Bigtable 一开始并没有提供跨行事务就是这个原因。但是,它不可扩展是个实现问题,业务就是需要啊,你不提供官方实现,业务就会在上层企图自己搞事务,不出所料绝大部分分布式事务实现都是错的。Jeff Dean 后来实在看不过去在 Spanner 提供了官方分布式事务支持。

Bigtable 论文出来后不久,国内应该不止一个团队在企图复制它。当时 Bigtable 论文给我的感受倒不是它有多大创新,而是它在有机群管理软件(当时还不知道它叫 borg)有 GFS 有 Chubby 做基础,实现起来并不困难(论文里说了大概就10万行C++),有了 Bigtable 的基础,Google 实现其他的东西可以更快更得心应手。这是拿机群当操作系统做的思路,这种打法,你想要跟着打,会追得很辛苦,你想要走捷径取得局部成果,又必然后劲不足。稍微有点毁三观,这么多年之后我不用翻原文都能记起 Bigtable 等老三篇的细节,就是那时被碾压的印记。

我09年底的时候在珠三角技术沙龙有个分享 slideshare.net/kyhpuddi 记录了当时我对这类分布式存储系统的总结和思考,很多观点今天看来依然适用。
lsm tree的应用,tablet的meta表和root表两级索引设计,按列存储对查询和压缩的优化,这几项对后面分布式kv或数据库系统设计的影响很大

不足之处是与GFS的两级级结构,看起来优雅,实际上对可用性和性能的牺牲非常大,且比较难实现完整的多机房副本,也很难支持读取副本