Google BigTable 到底解决什么问题？

搞架构的人，Google的论文是必看的，但好像大家都不愿意去啃英文论文。故把自己的读书笔记，加入自己的思考，分享给大家。

第三部分，Google BigTable。

BigTable，很多人对它耳熟能详，但它究竟解决什么问题呢？这是今天要聊的话题。

什么是BigTable？

Google BigTable是一个分布式，结构化数据的 存储系统 ，它用来存储海量数据。该系统用来满足“ 大数据量、高吞吐量、快速响应 ”等不同应用场景下的存储需求。

画外音：本质上，BigTable是一个存储系统。

有BigTable之前，Google面临什么问题？

Google并不是一群人坐在办公室开会，想出来的系统，Google面临着很实际的业务问题。

画外音：

很多公司的基础架构部，是坐在办公室开会，想出来的东西，然后强推业务线使用；

脱离业务的技术，都是耍流氓。

典型场景一：网页存储

Google每天要抓取很多网页：

• 新出现的网页， 新URL

• 旧网页， 旧URL

对一个已抓取的网页，旧URL为啥要反复抓取？

因为， 网页会更新 ，例如新浪首页：

sina.com.cn/index.html

URL虽然没有变，但依然会抓取。

画外音：我去，相当于，被抓取的URL集合，只会无限增大，趋近无穷，这里面的技术难题，不知道大家感不感兴趣？

这里，对于 存储系统的需求 ，是要存储： 不同URL，不同时间Time，的内容Content 。

画外音：URL+”Content”+Time => Binary。

网页的实际内容Binary，是Spider抓取出来的。

典型场景二：Google Analytics

Google Analytics要给站长展示其网站的流量PV，独立用户数UV，典型访问路径等，以帮助站长了解站点情况，优化站点。

这里，对于 存储系统的需求 ，是要存储， 不同URL，不同时间Time，的PV和UV 。

画外音：

URL+”PV”+Time => $count

URL+”UV”+Time => $count

PV和UV的值，是MapReduce离线任务计算出来的。

不管是“网页存储”还是“站点统计”存储，它们都有几个共同的特点：

• 数据量极大 ，TB，PB级别

• 和时间维度相关

• 同一个主键，属性与值有映射

画外音：

主键是URL，属性是“Content”，值是网页Binary；

主键是URL，属性是“PV”和“UV”，值是计数count。

这是Google曾经遇到的难题，面对这些难题，典型的解决方案又有哪些呢？

画外音：不是一上来就搞新方案，最先肯定是想用现有的技术要如何解决。

最容易想到的主键，属性，值的存储系统是什么？

没错，就是关系型数据库：

如上图所示，用户表

User(uid PK , name, gender, age, sex)

就是一个典型的主键，属性，值的存储模型：

• 主键 ，不同用户的uid

• 属性 ，schema的列名

• 值 ，不同主键的各个列名，对应的值

使用excel来举例是很直观的，这是一个 二维table 。

画外音：屎黄色的主键是一个维度，橙色的属性是一个维度。

用二维table能不能解决Google网页存储的问题呢？

如上图所示， 如果没有时间维度Time，似乎是可以 的：

• 主键 ，使用URL

• 属性 ，schema的列名，例如content，author等

• 值 ，不同URL的内容与作者等值

但是，一旦加入时间维度Time，二维table似乎就不灵了。

画外音：

增加一个time属性是没有用的；

增加一个time属性，只能记录同一个URL，某一个time的content，不能记录多个time的多个content；

增加一个time属性，联合主键，URL就不是KEY了；

能不能用二维table存储三维数据呢？

似乎可以通过trick的手段，在key上做文章， 用key+time来拼接新key 来实现。

如上图所示，仍然是二维table，通过URL+Time来瓶装key，也能够实现，存储同一个URL，在不同Time，的不同content、author。

但是，这种trick方案存在的问题是：

• 没法实现URL查询

画外音： key上无法进行%like%查询。

• 大量空洞，浪费存储空间

这并不是一个好的方案。

况且，当数据量达到TB、PB级别时，传统单机关系型数据库，根本无法满足Google的业务需求。

BigTable解决什么问题？

传统二维small table，无法解决Google面临的存储问题，于是Google搞了一个big table来解决。

Google对这些业务模型进行分析，在二维table的基础上扩充，抽象了一个新的“ 三维table ”：

• 主键 ，使用URL

• 属性 ，schema的列名，例如content，author等

• 时间 ，timestamp

• 值 ，不同URL的内容与作者等值

如上图所示：

• 第一维：key（屎黄色）

• 第二维：属性（橙色）

• 第三维：time（蓝色）

同一个key，不同属性，不同时间，会存储一个value。

不像 以行为单位 进行存储的传统关系型数据库，这个三维的大表格BigTable是一个稀疏 列存储 系统。

画外音：能够压缩空间。

它的 数据模型 的本质是一个 map ：

key + column + time => value

的一个超级大map。

画外音：

很多业务符合这一个模型；

Google的东西能解决业务问题，所以用的人多，这一点很重要。

总结

BigTable是一个 稀疏的 、 分布式的 、 持久化的 、 多维度 排序 的 、 大数据量 存储系统 ，它能够解决符合上述map数据模型业务的存储问题。

画外音：

GFS是文件系统；

MapReduce是计算模型；

BigTable是存储系统。

BigTable是啥，解决啥问题，这次终于懂了。

很多时候， 定义清楚问题比解决问题更难 。

架构师之路-分享 可落地 的技术文章

相关推荐：

《 Google FileSystem架构启示 》

《 Google MapReduce解决什么问题？ 》

《 MapReduce，颠覆了分层架构的本质？ 》