《一种no sql数据库-google big table的综述》由会员分享，可在线阅读，更多相关《一种no sql数据库-google big table的综述（9页珍藏版）》请在金锄头文库上搜索。
1、一种No SQL数据库-Google Big Table的综述赵小溪 经管会计 201411036022摘要 本文对一种主流No SQL数据库，即Google的BigTable进行了综述。对其实现细节进行了表述，深入了解了BigTable的架构，介绍了其读写操作，并提出了其存在的几个问题并给出了解决办法。对BigTable进行了总结和展望。并对No SQL数据库的发展现状和趋势作了简单介绍。引言 出现于1998年的No SQL是Carlo Strozzi开发的一个轻量、开源、不提供SQL功能的关系数据库。在2009年，Johan Oskarsson发起了一次关于分布式开源数据库的讨论，来自Ra
2、ckspace(全球三大云计算中心之一)的Etic Evans再次提出了No SQL的概念，这时的No SQL主要指非关系型、分布式、不提供ACID的数据库设计模式。2009年在亚特兰大举行的no：sql(east)讨论会是一个里程碑，会上对No SQL最普遍的解释是非关系型的，强调键一值对存储和文档数据库的优点，而不是单纯的关系型数据库。 No SQL是Not Only SQL的简写，其含义是“不仅是结构化查询”，是不同于传统的关系型数据库的数据库管理系统的统称。No SQL与SQL的最显著的区别是No SQL不使用SQL作为查询语言，其数据存储不需要固定的表格模式，也避免使用SQL的JOI
3、N操作，具有水平可扩展性。CAP、BASE和最终一致性是No SQL数据库存在的3大基石。No SQL存储满足了数据存储的横向伸缩性的需求。No SQL以其运行在PC服务器集群上，突破了性能瓶颈，没有过多的需求，支持者源于社区，弹性扩展，大数据量，灵活的数据模型，经济效率高等特点为大数据的存储、传输与处理创造了生态环境，并逐渐走向成熟并广泛应用。Big Table作为一种非关系型数据库，是一个稀疏的、分布式的、持久化存储的多维度排序映射。Big Table能可靠处PB级的数据，并且能够部署到上千台机器上。Big Table具有适用性广泛、可扩展、高性能和高可用性。BigTable简述及其关键技
4、术 Bigtable分布式存储系统是Google开发的第三项云计算关键技术，用于管理Google中的结构化数据。很多 Google的应用程序都需要存储海量数据，比如Google地球、Google分析和网络搜索等，解决方案之一是Google文件系统(GFS），它具有很好的可扩展性，很多的GFS集群可以扩展到300Terabytes，但是GFS用文件的方式来存储数据具体来说，这些数据文件存储在Linux的文件系统里，而且用GFS来存储的数据是非结构化的数据。为了解决这个问题，Google的软件开发工程师研发了BigTable，并于2005年4月投入使用。Bigtable 具备广泛的适用性、高可扩展
5、性、高性能和高可用性，已经在超过60个Google 的产品和项目上得到了应用。Bigtable借鉴了并行数据库和内存数据库的一些特性，但 Bigtable 提供了一个完全不同接口。Bigtable 不支持完整的关系数据模型，而是为用户提供了简单的数据模型，使客户可以动态控制数据的分布和格式。对Bigtable而言，数据是没有格式的，用户可以自定义Schema。BigTable数据模型 Bigtable是一个稀疏、分布式、持久化存储的多维有序映射表，表的索引是行关键字、列关键字和时间戳。Bigtable 中存储的表项都是未经解析的字节数组，其数据模型如下：(row:string, column:
6、string,time:int64)-string选定该数据模型，是在仔细分析了Bigtable系统的种种用途之后决定的。比如一个存储了大量网页及其相关信息的表 Webtable，Webtable 使用URL作为行关键字，使用网页的某些属性作为列名，网页的内容存入 contents列中，并使用获取该网页的时间戳标识同一个网页的不同版本。在 Bigtable中，Webtable的存储范例如图一所示。图一 Webtable范例片段1.行关键字行关键字可以是任意字符串，目前最大支持 64KB。Bigtable按照行关键字的字典序组织数据，利用这个特性可以通过选择合适的行关键字，使数据访问具有良好的局
7、部性。如 Webtable中，通过将反转的 URL 作为行关键字，可以将同一个域名下的网页聚集在一起。表的行区间可以动态划分，每个行区间称为一个子表。子表是 Bigtable 数据分布和负载均衡的基本单位，不同的子表可以有不同的大小。为了限制移子表的移动和恢复成本，每个子表默认的最大尺寸为200MB。2. 列族 列关键字一般都表示一种数据类型，列关键字的集合称作列族，列族是访问控制的基本单位。存储在同一列族下的数据属于同一种类型，列族下的数据被压缩在一起保存。数据在被存储之前必须先创建列族，并且表中的列族不宜过多，通常几百个，但表中可以有无限多个列。在Bigtable 中列关键字的命名语法为：
8、“列族：限定词”，列族名称必须是可打印的字符串，限定词则可以是任意字符串。如 Webtable 中名为 anchor 的列族，该列族的每一个列关键字代表一个锚链接；anchor 列族的限定词是引用网页的站点名，每列的数据项是链接文本。3. 时间戳 Bigtable中的表项可以包含同一数据的不同版本，采用时间戳进行索引。时间戳是 64 位整型，既可以由系统赋值也可由用户指定。表项的不同版本按照时间戳倒序排列，即最新的数据排在最前面。为了简化多版本数据的管理，每个列族都有两个设置参数用于版本的自动回收，用户可以指定保存最近 N 个版本，或保留足够新的版本 (如最近 7 天的内容)。在 Webtab
9、le 的例子中，contents 列族存储的时间戳是网络爬虫抓取页面的时间，表中的回收机制是保留任一页面的最近三个版本。 BigTable的稀疏性尽管列聚簇是静态的，而且一旦创建就不得更改，但是列本身却是很灵活的.在图二BigTable数据模型中添加一行包含不同列标示符”ColumnFamily:IdentifierZ”，如图三所示，图二 BigTable的数据模型图三 添加一行包含不同列标识符”ColumnFamily:IdentifierZ”与rowA相比，rowZ包含一个不同的列标识符”ColumnFamily:IdentifierZ”。如图 三中所示，BigTable的稀疏性具有两重意
10、思：第一，在BigTable中，每一行可以拥有0个或多个列；第二，不同的行可以包含不同的列，例如 rowA和 rowZ。BigTable的分布性BigTable的数据结构是排序的map，并且是分布式存储的具体来说，BigTable之所以能够提供高效的海量数据查询能力，是因为每个Table都可以根据行分割成多个 tablets，每tablet又可以分配到一个独立的数据服务器（tablet server）上。BigTable架构与实现BigTable架构Bigtable 是在 Google 的其他基础设施之上构建的，它使用 Work Queue 负责故障处理和监控，使用 GFS 存储日志文件和数据
11、文件，依赖 Chubby 存储元数据和进行主服务器的选择。Bigtable 主要由链接到每个客户端的库、主服务器和多个子表服务器组成，其架构如图四所示。为了适应工作负载的变化，可以动态地向集群中添加或删除子表服务器。图四 BigTable架构1.ChubbyBigtable 依赖于 Chubby 提供的锁服务，如果 Chubby 长时间不能访问，Bigtable也会无法使用。Bigtable 使用 Chubby 完成以下任务： 确保任意时间只有一个活跃的主服务器副本；存储 Bigtable 中数据的引导位置；查找子表服务器，并在子表服务器失效时进行善后；存储 Bigtable 的模式信息，即表
12、的列族信息；存储访问控制列表。2. 主服务器主服务器主要用于为子表服务器分配子表、检测子表服务器的加入或过期、进行子表服务器的负载均衡和对保存在 GFS 上的文件进行垃圾收集。主服务器持有活跃的子表服务器信息、子表的分配信息和未分配子表的信息。如果子表未分配，主服务器会将该子表分配给空间足够的子表服务器。3. 子表服务器每个子表服务器管理一组子表，负责其上子表的读写请求，并在子表过大时进行子表的分割。与许多单一主节点的分布式存储系统一样，客户端直接和子表服务器通信，因此在实际应用中，主服务器的负载较轻。 4. 客户端程序库 客户端使用客户端程序库访问 Bigtable，客户端库会缓存子表的位置
13、信息。当客户端访问 Bigtable 时，首先要调用程序库中的 Open()函数获取文件目录，然后再与子表服务器通信。读写操作Bigtable 内部采用 SSTable 的格式存储数据，子表的持久化状态信息保存在GFS 上。Bigtable 中的读写操作流程如图五所示，当写操作到达子表服务器时，首先将事务信息记录在日志中，成功写入日志后将记录插入 Memtable 有序内存缓冲区中。由于内存空间有限，当 Memtable 大小达到阈值时就会被冻结，新的Memtable 被创建；冻结的 Memtable 被转化为不可更改的 SSTable，并写入 GFS。因为一次写操作仅涉及一次磁盘顺序写和一次
14、内存写入，所以 Bigtable 的写操作速度很快。日志文件在系统中的作用主要是为了防止系统崩溃时所导致的数据丢失。如果没有日志文件，由于写入的记录开始是保存在内存中的，一旦系统崩溃而内存中的数据还没有刷写到磁盘，数据就会丢失。因此，Bigtable 在写入内存之前将操作记录到日志文件中，然后再写入内存，这样即使系统崩溃也可以从日志文件中恢复内存中的 Memtable，不会造成数据丢失。图五 读写操作流程 由于 SSTable 一旦被写入磁盘就只能进行读操作，不能被改变，因此数据的更新和删除操作不能通过操作 SSTable 实现。在 Bigtable 中更新操作通过简单地向Memtable 中
15、存储一个更新后的值来实现，删除操作在 Memtable 中是作为插入一条记录实现的，但会在该记录上添加一个墓碑标志。由于 Bigtable 是按序检查索引的，后续的读操作会获取到更新后或有墓碑标志的记录，而不会获取到旧值。真正的删除和更新操作都是 Lazy 模式，会在系统定期执行合并 SSTable 的操作时，覆盖或删除掉旧的数据。由于 Memtable 中的键值对是根据键的大小有序存储的，而用户写入的数据并不一定会按照键值有序排列，所以 Memtable 采用跳表结构来保证新纪录会插入到合适的位置上。 对子表服务器进行读写操作时，服务器会检查操作格式是否正确，以及操作发起者是否有执行该操作的
16、权限。写操作可以通过从 Chubby 文件中读取具有写权限的操作者列表，进行权限验证；读操作需要读取 SSTable 和 Memtable 上的数据，由于 SSTable 和 Memtable 是按字典序排列的数据结构，所以能够高效地生成合并视图。图六 子表的实际组成 如前文所述，当写操作到达子表服务器时，子表服务器会首先将写操作写入日志文件中。如果每个子表服务器都维护一份日志文件的话，每次到达不同子表服务器的写操作都会引起一次磁盘访问，将记录写入日志文件并存入 GFS 中。由于磁盘每秒最多进行几百次访问，这必然会限制 Bigtable 的写操作速度。因此，Bigtable 仅维护一份经过性能优化的日志文件，日志文件中的每一行数据都按照表名、行名和日志序列号进行排序。Bigtable 子表
