首页 > 代码库 > 回顾一下著名的BigTable论文
回顾一下著名的BigTable论文
GFS解决了某些业务场景对分布式文件系统需求，很自然的，也有某些业务仅仅靠文件系统用起来还是不那么方便，它们需要分布式数据库系统。BigTable就是Google为了解决内部对大规模结构化数据处理的需求而产生的。论文摘要涉及的“关键”字为：
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没有提供的。
绝大多数实际系统都不是从零开始的，而是要站在巨人的肩膀上。分布式文件系统有很多是建立在本地文件系统之上的，数据库很多是把数据存在文件里头的。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. 恢复等等。
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. 恢复等等。
这里头涉及到的细节比较多，需要慢慢的品味。而一涉及性能优化，就会比较发散到压缩、布隆过滤器等等比较通用的算法/技术。有些东西没有做过，理解得还比较肤浅，留待后面继续学习。。。。。
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。