Google bigtable
bigtable数据库简介
BigTable数据库概况摘要Bigtable是一个分布式的结构化数据存储系统，它被设计用来处理海量数据，通常是分布在数千台普通服务器上的PB级的数据。
Google的很多项目使用Bigt able存储数据，包括Web索引、Google Earth、GoogleFinance。
这些应用对Bigtable提出的要求差异非常大，无论是在数据量上（从URL 到网页到卫星图像）还是在响应速度上（从后端的批量处理到实时数据服务）。
尽管应用需求差异很大，但是，针对Google的这些产品，Bigtable还是成功的提供了一个灵活的、高性能的解决方案。
本论文描述了Bigtable的特点、发展史、目前应用现状、数据库存储技术、存储架构及查询、更新技术。
1 介绍BigTable是非关系的数据库，是一个稀疏的、分布式的、持久化存储的多维度排序Map。
Bigtable的设计目的是可靠的处理PB级别的数据，并且能够部署到上千台机器上。
Bigtable已经实现了下面的几个目标：适用性广泛、可扩展、高性能和高可用性，且已经在超过60个Google的产品和项目上得到了应用，包括Goog le Analytics、Google Finance、Orkut、Personalized Search、Writely和Google Earth。
这些产品对Bigtable提出了迥异的需求，有的需要高吞吐量的批处理，有的则需要及时响应，快速返回数据给最终用户。
它们使用的Bigtable集群的配置也有很大的差异，有的集群只有几台服务器，而有的则需要上千台服务器、存储几百TB的数据。
在很多方面，Bigtable和数据库很类似。
它使用了很多数据库的实现策略。
并行数据库和内存数据库已经具备可扩展性和高性能，但是Bigtable提供了一个和这些系统完全不同的接口。
Bigtable不支持完整的关系数据模型。
与之相反，Bigtable为客户提供了简单的数据模型，利用这个模型，客户可以动态控制数据的分布和格式，用户也可以自己推测底层存储数据的位置相关性。
谷歌BigTable数据库
谷歌BigTable数据库Bigtable包括了三个主要的组件：链接到客户程序中的库、一个Master服务器和多个Tablet服务器。
针对系统工作负载的变化情况，BigTable可以动态的向集群中添加（或者删除）Tablet服务器。
Master服务器主要负责以下工作：为Tablet服务器分配Tablets、检测新加入的或者过期失效的Table服务器、对Tablet服务器进行负载均衡、以及对保存在GFS上的文件进行垃圾收集。
除此之外，它还处理对模式的相关修改操作，例如建立表和列族。
每个Tablet服务器都管理一个Tablet的集合（通常每个服务器有大约数十个至上千个Tablet）。
每个Tablet服务器负责处理它所加载的Tablet的读写操作，以及在Tablets过大时，对其进行分割。
和很多Single-Master类型的分布式存储系统【17.21】类似，客户端读取的数据都不经过Master服务器：客户程序直接和Tablet服务器通信进行读写操作。
由于BigTable的客户程序不必通过Master服务器来获取Tablet的位臵信息，因此，大多数客户程序甚至完全不需要和Master服务器通信。
在实际应用中，Master服务器的负载是很轻的。
一个BigTable集群存储了很多表，每个表包含了一个Tablet的集合，而每个Tablet包含了某个范围内的行的所有相关数据。
初始状态下，一个表只有一个Tablet。
随着表中数据的增长，它被自动分割成多个Tablet，缺省情况下，每个Tablet的尺寸大约是100MB到200MB。
我们使用一个三层的、类似Ｂ+树[10]的结构存储Tablet的位臵信息(如图4)。
第一层是一个存储在Chubby中的文件，它包含了Root Tablet的位臵信息。
Root Tablet包含了一个特殊的METADATA表里所有的Tablet 的位臵信息。
METADATA表的每个Tablet包含了一个用户Tablet的集合。
Google云计算原理
1、Google 云计算文件系统GFS/GFSIIGFSII cell 是Google 文件系统中最基础的模块。
任何文件和数据都可以利用这种底层模块。
GFSII 通过基于Linux 分布存储的方式，对于服务器来说，分成了主服务器（Master Servers）和块存储服务器（Chunk Servers），GFS上的块存储服务器上的存储空间以64MB为单位，分成很多的存储块，由主服务器来进行存储内容的调度和分配。
每一份数据都是一式三份的方式，将同样的数据分布存储在不同的服务器集群中，以保证数据的安全性和吞吐的效率提高。
当需要对于文件、数据进行存储的时候，应用程序之间将需求发给主服务器，主服务器根据所管理的块存储服务器的情况，将需要存储的内容进行分配，并将可以存储的消息（使用那些块存储服务器，那些地址空间），有应用程序下面的GFS 接口在对文件和数据直接存储到相应的块存储服务器当中。
块存储服务器要定时通过心跳信号的方式告知主服务器，目前自己的状况，一旦心跳信号出了问题，主服务器会自动将有问题的块存储服务器的相关内容进行复制。
以保证数据的安全性。
2、Google 并行计算构架–Mapreduce有了强大的分布式文件系统，Google 遇到的问题就是怎么才能让公司所有的程序员都学会些分布式计算的程序呢？于是，那些Google 工程师们从lisp和其他函数式编程语言中的映射和化简操作中得到灵感，搞出了Map/Reduce 这一套并行计算的框架。
Map/Reduce 被Google 拿来重新了Google Search Engine的整个索引系统。
而Doug Cutting同样用Java 将这一套实现和HDFS合在一起成为Hadoop的Core。
MapReduce是Google 提出的一个软件架构，用于大规模数据集（大于1TB）的并行运算。
概念“Map（映射）”和“Reduce（化简）”，和他们的主要思想，都是从函数式编程语言借来的，还有从矢量编程语言借来的特性。
Google的十个核心技术
Google的十个核心技术曾任职于IBM中国研究院，从事与云计算相关研究的CSDN博客专家吴朱华曾写过一篇文章《探索Google App Engine背后的奥秘(1)--Google的核心技术》，对Google 的核心技术和其整体架构进行详细的分析，现转载于此，供大家学习。
本篇将主要介绍Google的十个核心技术，而且可以分为四大类：1.分布式基础设施：GFS，Chubby和Protocol Buffer。
2.分布式大规模数据处理：MapReduce和Sawzall。
3.分布式数据库技术：BigTable和数据库Sharding。
4.数据中心优化技术：数据中心高温化，12V电池和服务器整合。
分布式基础设施GFS由于搜索引擎需要处理海量的数据，所以Google的两位创始人Larry Page和Sergey Brin在创业初期设计一套名为“BigFiles”的文件系统，而GFS（全称为“Google File System”）这套分布式文件系统则是“BigFiles”的延续。
首先，介绍它的架构，GFS主要分为两类节点：1.Master节点：主要存储与数据文件相关的元数据，而不是Chunk（数据块）。
元数据包括一个能将64位标签映射到数据块的位置及其组成文件的表格，数据块副本位置和哪个进程正在读写特定的数据块等。
还有Master节点会周期性地接收从每个Chunk节点来的更新（”Heart- beat”）来让元数据保持最新状态。
2.Chunk节点：顾名思义，肯定用来存储Chunk，数据文件通过被分割为每个默认大小为64MB的Chunk的方式存储，而且每个Chunk有唯一一个64位标签，并且每个Chunk都会在整个分布式系统被复制多次，默认为3次。
下图就是GFS的架构图：图1. GFS的架构图接着，在设计上，GFS主要有八个特点：1.大文件和大数据块：数据文件的大小普遍在GB级别，而且其每个数据块默认大小为64MB，这样做的好处是减少了元数据的大小，能使Master节点能够非常方便地将元数据放置在内存中以提升访问效率。
Google_云计算三大论文中文版
Google_云计算三大论文中文版Google公司是全球最大的搜索引擎和云计算服务提供商之一。
Google的云计算架构和算法在业界受到广泛关注，其通过一系列论文来介绍这些技术，并分享了它们的最佳实践。
本文将针对Google公司发表的三篇云计算论文（论文名称分别为《MapReduce：Simplified Data Processing on Large Clusters》、《The Google File System》、《Bigtable: A Distributed Storage System for Structured Data》），进行分类讲解，以帮助读者更好地了解云计算领域的相关技术。
一、MapReduce：Simplified Data Processing on Large ClustersMapReduce论文是Google公司云计算领域中的重要代表作之一，它的作者是Jeffrey Dean和Sanjay Ghemawat。
MAPREDUCE是一种大规模数据处理技术，其主要目的是在一个大型集群中分Distribute and Parallel Execution（分布式和并行执行）处理任务。
MapReduce将计算逻辑分解成两个部分- Map阶段和Reduce阶段。
在Map阶段，数据被按键提取；在Reduce阶段，数据被收集以计算结果。
这两个阶段可以在许多物理节点上并行执行，大大提高了计算效率。
此外，该论文引入了GFS分布式文件系统，为MapReduce提供了强大的文件系统支持。
二、The Google File SystemGFS是由Sanjay Ghemawat、Howard Gobioff和Shun-TakLeung共同编写的一篇论文。
它旨在解决分布式文件系统上的问题，以应对Google的大规模数据集和两台甚至三台以上的机器发生故障的情况。
GFS可以处理超过100TB以上的数据集，加速数据读取和写入，处理大规模数据存储集群。
Google Bigtable系统的可信性研究
Google Bigtable系统的可信性研究
魏兵;姚敏;沈志荣
【期刊名称】《信息网络安全》
【年(卷),期】2011(000)012
【摘要】Bigtable作为Google云计算的一项关键技术,在需要海量的存储要求的Google地图、GoogleEarth、Gmail、Youtube等上面得到了成功的应
用.Bigtable是基于GFS和Chubby开发的分布式存储系统,能够处理Google中海量繁杂的数据类型,也能够将不同应用的数据分布地存储到数千台服务器上.文章介绍了Bigtable的数据模型、设计和实现,并引入了随机Petri网对Bigtable系统的可信性进行模拟和量化分析,提出了云计算环境下Key/value存储系统的发展趋势,并从理论上得出Bigtable系统的高可用性和高可靠性.
【总页数】5页(P27-30,39)
【作者】魏兵;姚敏;沈志荣
【作者单位】清华大学,北京 100084;清华大学,北京 100084;清华大学,北京100084
【正文语种】中文
【中图分类】TP393.08
【相关文献】
1.基于 Google Bigtable 的海量数据存储探索 [J], 李红
2.Bigtable系统主服务器检查点的实现 [J], 王金锁;康林;费江涛;齐学玲
3.分布式海量数据管理系统Bigtable主服务器设计 [J], 张晓清;费江涛;潘清
4.Bigtable系统的负载平衡技术研究 [J], 王映东;匡艺;费江涛
5.可信性概念与可信性计算系统的研究 [J], 袁由光;李海山
因版权原因，仅展示原文概要，查看原文内容请购买。
常用列式数据库
常用列式数据库常用列式数据库概述列式数据库是一种基于列而非行的数据存储方式，它将同一列的数据存储在一起，而不是将整行数据存储在一起。
这种存储方式可以提高查询效率，并且适用于大型数据集和复杂的分析查询。
本文将介绍几种常用的列式数据库，包括Apache Cassandra、Google Bigtable、Amazon Redshift和Vertica。
Apache CassandraApache Cassandra是一个开源分布式NoSQL数据库系统，最初由Facebook开发。
它使用了类似于Google Bigtable的数据模型，并且具有高可扩展性和高可用性。
特点：1. 分布式架构：Cassandra可以在多个节点上运行，并且支持自动分2. 数据复制：Cassandra可以自动将数据复制到多个节点上，以提高可用性和容错性。
3. 数据模型：Cassandra使用了类似于Google Bigtable的数据模型，即键值对+列族。
每个键值对都包含一个主键和多个列族。
4. 支持ACID事务：Cassandra支持原子性、一致性、隔离性和持久性（ACID）事务。
5. 灵活的查询语言：Cassandra支持类似于SQL的查询语言（CQL），同时还支持更灵活的查询方式，如范围查询和分页查询。
Google BigtableGoogle Bigtable是一个高性能、高可扩展性的分布式列式数据库系统，用于存储大型数据集。
它最初由Google开发，并且作为Google Cloud Platform的一部分提供。
特点：1. 分布式架构：Bigtable可以在多个节点上运行，并且支持自动分片2. 数据模型：Bigtable使用了类似于哈希表的数据模型，即键值对+列族。
每个键值对都包含一个行键、一个列族和一个时间戳，而每个列族包含多个列。
3. 高性能：Bigtable具有高性能的读写能力，并且可以处理大量并发请求。
4. 可扩展性：Bigtable可以轻松地扩展到数百甚至数千台服务器，以适应不断增长的数据集。
Google云计算的关键技术(一)
Google云计算的关键技术（一）Google云计算的关键技术主要包括：Google文件系统GFS、分布式计算编程模型MapReduce、分布式锁服务Chubby和分布式结构化数据存储系统BigTable等。
其中：1）GFS提供了海量数据存储和访问的能力；2）MapReduce使得海量信息的并行处理变得简单易行；3）Chubby保证了分布式环境下并发操作的同步问题；4）BigTable使得海量数据的管理和组织十分方便。
●GFSGFS是一个面向海量数据密集型应用的、可伸缩的分布式文件系统，它为Google云计算提供了海量存储的能力，处于整个Google云计算技术体系的最底层。
GFS使用廉价的商用机器构建分布式文件系统，将容错的任务交由文件系统来完成，利用软件的方法解决系统可靠性的问题，不但使得存储的成本成倍下降，更是很好地在频繁的故障中确保了数据存储的安全和数据存储服务的连续性，从整体上确保了整个系统的可靠性，进而可以为大量客户机提供高性能的服务。
一、架构一个GFS集群包含一个单独的Master逻辑节点、多台Chunk服务器，并且同时被多个客户端访问，如下图所示。
GFS存储的文件都被分割成固定大小的Chunk。
在Chunk创建的时候，Master服务器会给每个Chunk分配一个不变的、全球唯一的64位的Chunk标识。
Chunk服务器把Chunk以linux文件的形式保存在本地硬盘上，并且根据指定的Chunk标识和字节范围来读写块数据。
出于可靠性的考虑，每个块都会复制到多个块服务器上。
缺省情况下，我们使用3个存储复制节点，不过用户可以为不同的文件命名空间设定不同的复制级别。
Master节点管理所有的文件系统元数据，在逻辑上只有一个。
这些元数据包括名字空间、访问控制信息、文件和Chunk的映射信息、以及当前Chunk的位置信息；Master节点还管理着系统范围内的活动，比如Chunk在Chunk服务器之间的迁移等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Building Blocks
• • • • Scheduler (Google WorkQueue) Google Filesystem Chubby Lock service Two other pieces helpful but not required
– Sawzall – MapReduce (despite what the Internet says)
6 of 19
Data model: a big map
•<Row, Column, Timestamp> triple for key - lookup, insert, and delete API •Arbitrary “columns” on a row-by-row basis •Column family:qualifier. Family is heavyweight, qualifier lightweight •Column-oriented physical store- rows are sparse! •Does not support a relational model •No table-wide integrity constraints •No multirow transactions
Index
8 of 19
Tablet
• Contains some range of rows of the table • Built out of multiple SSTables
Tablet
64K block Start:aardvark 64K block 64K block End:apple SSTable 64K block 64K block 64K block SSTable
Google Bigtable
Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber Google, Inc. UWCS OS Seminar Discussion Erik Paulson 2 October 2006
Index
Index
9 of 19
Table
• Multiple tablets make up the table • SSTables can be shared • Tablets do not overlap, SSTables can overlap
Tablet aardvark apple Tablet apple_two_E boat
• BigTable: build a more application-friendly storage service using these parts
4 em
• Large-scale distributed “filesystem” • Master: responsible for metadata • Chunk servers: responsible for reading and writing large chunks of data • Chunks replicated on 3 machines, master responsible for ensuring replicas exist • OSDI ’04 Paper
– Couldn’t afford it if there was one – Might not have made appropriate design choices
• Firm believers in the End-to-End argument • 450,000 machines (NYTimes estimate, June 14th 2006
5 of 19
Chubby
• {lock/file/name} service • Coarse-grained locks, can store small amount of data in a lock • 5 replicas, need a majority vote to be active • Also an OSDI ’06 Paper
7 of 19
SSTable
• Immutable, sorted file of key-value pairs • Chunks of data plus an index
– Index is of block ranges, not values
64K block 64K block 64K block SSTable
• Intersection of databases and distributed systems • Will try to explain (or at least warn) when we hit a patch of database • Remember this is a discussion!
See also the (other)UW presentation by Jeff Dean in September of 2005 (See the link on the seminar page, or just google for “google bigtable”)
Before we begin…
2 of 19
Google Scale
• Lots of data
– Copies of the web, satellite data, user data, email and USENET, Subversion backing store
• Many incoming requests • No commercial system big enough