|
从侃哥的文章中了解到一些Google的经典论文，简要的看了一下其中一篇“Bigtable: A Distributed Storage System for Structured Data”简介如下。
我的理解BigTable应该是同关系型数据库并列的概念。与微软这样的技术大鳄相比，Google的产品线略显单一，例如MS的SQL Server就是Google所没有的，为了可以以类似关系数据库的方式操纵海量的网页信息，Google在产品中抽象了这个模块。不过反过来说，SQL Server这样的通用数据库应对搜索引擎的需求，除了价格昂贵之外，可能既不能scale又不容易调优，大概不是好的选择。
1.Table
上图是BigTable中类比关系数据库的table概念，是一个三维概念。一维是Web Page的URL，对应的是某个Web页面。一维是该Page的属性，例如使用了什么编码方式，被那些网页引用。一维是时间戳，也就是同一个网页以及属性的多个时间的不同版本，例如新浪首页就常常变化。这是个稀疏存储矩阵，稀疏的含义，我的理解就是某些属性例如编码方式在所有的cache版本中只有一个值，不会变化。
其实上述概念，如果不考虑冗余，也可以用一个关系数据表来表示。这里同关系数据库table之间的差别我认为是没有强制关联关系，每个table独立存在。
2.Tablet
是BigTable的Table的一个子集，也就是table的row的一个集合，是数据层面调度、分发和负载均衡的单位。个人理解，引入的原因在于Table太大了，以至于一台设备放不下。划分为Tablet类似于操作系统的Cache概念，这样对于局部操作易于命中。这种东西在关系数据库中或有类似概念，但是被屏蔽，对于用户应该是透明的。在BigTable中用户可见。
3.API操作
其实就是增、删、改、查询等等，功能远远不及SQL语句。为了简化开发人员工作（我认为），google支持使用Sawzall语言（google内部语言）实现的脚本，对于bigtable的table进行复杂操作，实现例如过滤汇总等功能。个人感觉，类似商用数据库的存储过程。
4.底层依赖
运行在单一机器中的数据库系统，依赖OS提供的lock、FS在google的分布式应用中也有对应的概念。BigTable基于Google的GFS以及Lock service等底层应用。
大体就是这些，这篇论文在06年公布，之后据说国内有些厂家也照单实现了，不知道用的怎么样，欢迎描述一些心得体会。例如，为什么采用这种简单的模型，可否有办法improve等（相比Google没有这么好心，公布的技术应该相对落后）。
|
