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. 恢复等等。
这里头涉及到的细节比较多，需要慢慢的品味。而一涉及性能优化，就会比较发散到压缩、布隆过滤器等等比较通用的算法/技术。有些东西没有做过，理解得还比较肤浅，留待后面继续学习。。。。。
回顾一下著名的BigTable论文,布布扣,bubuko.com