GFS捕捉一些业务场景的分布式文件系统的需求。很自然。此外还有一些与他们一些业务或依赖于文件系统是不那么容易，他们需要一个分布式数据库系统。
1. 结构化数据
2. 数据量大
3. 典型应用：Web索引，Google Earth，Google Finance
4. 批处理和实时需求
对于批处理业务，能够理解为其处理时间须要的比較多，至少不是秒级的响应时间。而对于实时需求，应该也不是实时操作系统。怎么也应该是毫秒甚至秒级别的响应时间吧。
数据模型相对照较好理解，既然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没有提供的。
绝大多数实际系统都不是从零開始的，而是要站在巨人的肩膀上。分布式文件系统有非常多是建立在本地文件系统之上的。数据库非常多是把数据存在文件中头的。
有了数据模型。定义了编程接口，准备好了基础设施。兴许的重要工作就是系统实现和优化了。
1. Master的职责
2. Tablet的职责
3. tablet的位置管理（为什么是3层，定位的效率）
4. Master怎么track各个tablet的死活？
5. 元信息的特殊处理
6. tablet的增减、合并
7. 日志
8. 三种compaction
9. 恢复等等。
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. 恢复等等。
这里头涉及到的细节比較多，须要慢慢的品味。
而一涉及性能优化，就会比較发散到压缩、布隆过滤器等等比較通用的算法/技术。有些东西没我完成了，了解也比较浅，留下来继续学习。。。。。
版权声明：本文博主原创文章，博客，未经同意不得转载。