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，颠覆了分层架构的本质？》