您的位置:首页 > 编程语言 > Go语言

Google BigTable到底解决什么问题?

2020-11-10 19:48 1001 查看

搞架构的人,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,颠覆了分层架构的本质?》

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: