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是啥,解决啥问题,这次终于懂了。

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值