搞架构的人, 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 是啥, 解决啥问题, 这次终于懂了.
很多时候, 定义清楚问题比解决问题更难 .
来源: http://www.tuicool.com/articles/bYNnmiZ