搞架构的人，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 => $countPV和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是啥，解决啥问题，这次终于懂了。
很多时候，定义清楚问题比解决问题更难。
架构师之路-分享可落地的技术文章
