回顾一下著名的BigTable论文

版权声明:Copyright by zedware. New site https://zedware.github.io https://blog.csdn.net/zedware/article/details/35875485
GFS解决了某些业务场景对分布式文件系统需求,很自然的,也有某些业务仅仅靠文件系统用起来还是不那么方便,它们需要分布式数据库系统。BigTable就是Google为了解决内部对大规模结构化数据处理的需求而产生的。论文摘要涉及的“关键”字为:
1. 结构化数据
2. 数据量大
3. 典型应用:Web索引,Google Earth,Google Finance
4. 批处理和实时需求

5. 数据模型

首先,需要注意的是,这里所谓的结构化数据和做DBMS的说的结构化数据不完全是一回事。后者定义的结构化数据都是数值、字符串等确实比较结构化的数据,而且长度也不会很大;采用的数据模型大多指的就是关系模型。其次,数据量大和此前做DBMS的人喜欢说的海量数据库也不是一个数量级。海量只不过是TB,而这里的大怎么着也是PB甚至以上了(这个大概和做OLAP的人说的量级差不多)。既然如此,典型的那些应用显然也超出了传统关系数据库能够摆平的范围了。
对于批处理业务,可以理解为其处理时间需要的比较多,至少不是秒级的响应时间。而对于实时需求,应该也不是实时操作系统,怎么也应该是毫秒甚至秒级别的响应时间吧。从上面这些简单的分析可以看出,很多术语的准确含义是需要上下文才可以对比,否则容易望文生义。
数据模型相对比较好理解,既然BigTable宣称是个数据库,那最核心的逻辑概念就是支持的数据模型是什么。第二节说“大表”是个稀疏的、分布的、持久化的、多维的、有序的Map。那它就不是关系模型,也不是对象模型或其他各种传统的数据模型了。这个定义有点啰嗦,但准确的描述了BigTable的特征。

对于一个大型的数据管理软件,我们要关心的问题是有一定通用性的。例如:
1. 数据模型
2. 编程接口
3. 依赖的基础设施/组件
4. 实现中的优化
5. 性能数据以及典型场景
这也是论文的后续章节主要介绍的内容。

在学习BigTable的数据模型/实现时,不妨带着与关系模型/实现的类比去思考以下问题:
1. 它和关系模型的区别
2. 它支持ACID吗
3. 数据的组织和Heap、Cluster B+树类似吗
4. 它有索引吗
5. 模式定义
6. 数据的分区(垂直分区和水平分区)
7. 权限控制
8. 行的多版本等等
更重要的,它的并发控制机制是什么?如果它和传统数据库在这些基本问题上差别/差距越大,那就可以说它越不像一个数据库:-)。

对于数据管理系统而言,支持的操作/API至少应该包括:
1. 模式定义(建表、改表、删表)
2. 数据操纵(增删改查)
3. 权限控制(权限的授予和回收)
要不用户怎么用啊?这些API里头最复杂和最有搞头的当属查数据了:
1. 全表扫描
2. 点查询
3. 范围查询
读第三节的时候,我们可以带着上述这些问题去思考哪些有交集,哪些是传统DBMS没有提供的。

绝大多数实际系统都不是从零开始的,而是要站在巨人的肩膀上。分布式文件系统有很多是建立在本地文件系统之上的,数据库很多是把数据存在文件里头的。BigTable也不例外。只不过它依赖的基础设施/组件比我想象的要多,而且多出来的那些组件一个比一个重要:GFS用来存数据文件和日志文件,集群管理系统用来调度作业、管理资源、处理故障等,SSTable定义了文件格式(Sorted String Table),Chubby提供分布式锁服务。Chubby是如此的重要和复杂,需要单独写篇论文来描述它。

有了数据模型,定义了编程接口,准备好了基础设施。后续的重要工作就是系统实现和优化了。BigTable有三个组要的模块:客户端/函数库、Master server、Tablet servers。详细内容需要阅读第五节。这里列出需要注意的问题:
1. Master的职责
2. Tablet的职责
3. tablet的位置管理(为什么是3层,定位的效率)
4. Master怎么track各个tablet的死活?
5. 元信息的特殊处理
6. tablet的增减、合并
7. 日志
8. 三种compaction
9. 恢复等等。

这里头涉及到的细节比较多,需要慢慢的品味。而一涉及性能优化,就会比较发散到压缩、布隆过滤器等等比较通用的算法/技术。有些东西没有做过,理解得还比较肤浅,留待后面继续学习。。。。。


展开阅读全文

没有更多推荐了,返回首页