回想一下著名的BigTable论题

GFS捕捉一些业务场景的分布式文件系统的需求。很自然。此外还有一些与他们一些业务或依赖于文件系统是不那么容易，他们需要一个分布式数据库系统。

BigTable那是，Google结构化数据处理的需求而产生的。

论文摘要涉及的“关键”字为：
1. 结构化数据
2. 数据量大
3. 典型应用：Web索引，Google Earth，Google Finance
4. 批处理和实时需求

5. 数据模型

首先，须要注意的是，这里所谓的结构化数据和做DBMS的说的结构化数据不全然是一回事。后者定义的结构化数据都是数值、字符串等确实比較结构化的数据，并且长度也不会非常大。採用的数据模型大多指的就是关系模型。其次，数据量大和此前做DBMS的人喜欢说的海量数据库也不是一个数量级。海量仅仅只是是TB，而这里的大怎么着也是PB甚至以上了（这个大概和做OLAP的人说的量级差点儿相同）。既然如此，典型的那些应用显然也超出了传统关系数据库可以摆平的范围了。

对于批处理业务，能够理解为其处理时间须要的比較多，至少不是秒级的响应时间。而对于实时需求，应该也不是实时操作系统。怎么也应该是毫秒甚至秒级别的响应时间吧。

从上面这些简单的分析能够看出，非常多术语的准确含义是须要上下文才干够对照。否则easy望文生义。
数据模型相对照较好理解，既然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有三个组要的模块：client/函数库、Master server、Tablet servers。

具体内容须要阅读第五节。

这里列出须要注意的问题：
1. Master的职责
2. Tablet的职责
3. tablet的位置管理（为什么是3层，定位的效率）
4. Master怎么track各个tablet的死活？
5. 元信息的特殊处理
6. tablet的增减、合并
7. 日志
8. 三种compaction
9. 恢复等等。

这里头涉及到的细节比較多，须要慢慢的品味。

而一涉及性能优化，就会比較发散到压缩、布隆过滤器等等比較通用的算法/技术。有些东西没我完成了，了解也比较浅，留下来继续学习。。。。。

版权声明：本文博主原创文章，博客，未经同意不得转载。