yunTableWord格式文档下载.docx

yunTableWord格式文档下载.docx

《yunTableWord格式文档下载.docx》由会员分享，可在线阅读，更多相关《yunTableWord格式文档下载.docx（11页珍藏版）》请在冰豆网上搜索。

接着是纵向的两层，主要是为横向的四层服务的：

1.管理层：

主要用于YunTable进程的起停和配置。

2.分布式层：

主要用于协调多个YunTable节点之间的管理和同步工作，而且由于此层牵涉的东西过多，所以在这一轮开发过程中，不会涉及。

开发计划

关于开发计划，其原则是“循序渐进，先难后易”，循序渐进是为了在开发工作中能稳定和不断地向目标逼近，而先难后易则为了先锤炼一下自己的C语言功底。

接下来是之后七个开发日的开发计划：

1.6-6周日：

主要完成接口层，编译层和研究BigTable的数据模型。

2.6-7周一：

主要完成管理层和研究HBase的实现。

3.6-8周二和6-9周三：

实现数据模型层。

4.6-12周六和6-13周日：

完成数据存储层。

5.6-14周一：

测试并上传v0.1版代码至GoogleCode上。

由于6-10周四和6-11周五将去北京参加2010IBM云计算高峰论坛，所以那两天的工作主要会以报道大会为主。

最后，希望大家能给我提一些建议，我在这里先谢谢了，还有，今后几天我会依据项目的进度来写项目的开发日记，希望大家能喜欢，并多多关注。

YunTable开发日记

（2）–前三天的总结

本来想周二写这篇开发日记，可惜一直抽不出时间，所以延到了周四。

在这篇日记中，会首先做一下前三天的开发总结，接着会解答博友的一些疑问。

前三天的开发总结

虽然在前三天花了很多时间在其它方面，比如写一些关于云计算的约稿等，但是基本完成了之前的计划，也就是实现了接口层和编译层，下面是YunTable一个非常简陋的截屏：

图1.YunTable的截屏

接下来，对已经涉及两层进行详述：

图2.YunTablev0.01架构图

接口层

在接口层这块，HBase的接口是以Shell和API形式为主，但我觉得Web接口在易用性方面更出色，所以我在接口层选用了LinuxSocket技术来开放YunTable的存储和查询能力。

编译层

这层大家疑问很多，有的同学觉得这层看起来有点多余，其实为了在初期提供友好的用户体验，准备支持最基本的SQL语句，也就是CRUD，所以编译层主要是为了解析用户从接口层输入的SQL语句，并将它们转译为相应的对数据模型的修改。

除了项目之外，更重要的是，通过这几天的C语言实践，我个人已经基本上掌握了C语言，特别是比较难缠的字符串处理部分，总的来说，C语言比Java灵活很多，在使用Java的时候，除了在编写多线程相关代码的时候，其它时刻大都能做到心中有数，而C语言呢，如果没有深厚的底层知识和丰富的经验，是很难做到随心所欲的。

估计，我在C语言方面的下两个挑战会是对内存的管理和与汇编的整合。

解答博友的一些疑问

这几天收到几位博友关于YunTable的一些问题，下面是对这些问题的回复，希望大家能满意。

为什么开发YunTable？

之前有一位博友向我提到既然在市面上已经出现了HBase和Hypertable这样的BigTable克隆，为什么我还要去开发？

首先，第一个原因当然是因为接下来准备进行内核层的开发，所以想先选择一个基于用户层的应用来练手。

其次，无论哪个行业，只有掌握最核心资源和技术才能处于最强势的地位和获取最高的利润，在云计算行业，什么是最核心的技术呢？

我认为主要有两个：

其一是虚拟机，相关的技术有开源的Xen和VMware的ESX，其二是分布式数据库，相关的技术有Google的BigTable，Apache的HBase和Facebook的Cassandra等，而且这两个技术在难度上也是最大的。

虽然这两种技术都有开源版本，但是如果我们能掌握其核心的实现方法，这样不仅能使我们有机会开始出在性能和用户体验这两方面更优越的版本，而且同时也能按照不同的业务需求来做相应的优化。

最后，就是我希望能通过YunTable这个项目结识一批具有实干精神的程序员。

为什么要写开发日记？

首先，当然是为了提升博客的人气，因为通过开发日记形式不仅能通过步步深入的方式将一个非常难懂的概念讲清，比如本系列将提供到的BigTable的数据模型和存储方式，还能通过开放整个实际的开发流程来帮助那些缺少产品开发经验的同学来理解一个在技术上有难度的产品是如何从无到有构建起来的。

其次，希望以博客形式代替传统的开发文档，也省了我相应的文本工作。

最后，我在考虑是不是将本系列作为工程实践部分加入到《剖析云计算》一书中。

会不会开源，怎么参加？

这个问题也是很多博友非常关注的，身为一名普通的开发人员，我也非常推崇开源这种形式，所以这个项目初期将会以ApacheLicense的形式发布，我个人觉得GPL有点偏激，所以不是特别推崇，而ApacheLicense总体而言，是比较温和的。

关于参加这个项目，我对这些同学是非常欣赏的，也是非常欢迎的，而且能与这些同学共事也是我开发YunTable的初衷之一，但是因为在现在这个阶段项目不论是从代码质量还是在功能上面离最简单的原型还差的很远，所以我个人准备等到项目达到其0.1版的时候发布在GoogleCode，之后希望大家能在这个0.1版的基础上一起讨论这个项目的未来，并参与其中，这样才能做到“有的放矢”。

接下来的几天会对首先试着实现数据模型层的原型，同时也会对HBase的数据存储层进行研究，来探究如何实现对BigTable数据的持久，之后会以本系列博客的形式发布给大家的。

YunTable开发日记（3）–BigTable的数据模型和调用接口

13Jun

本文是《YunTable开发日记》的第三篇。

本文将深入分析BigTable的数据模型，并介绍它是如何被调用的。

数据模型

就像向我之前所说的那样，其实BigTable顾名思义，是一个非常大的表，而且是一个能存储几十亿行（Row）和几千列（Column）的非常巨大的表。

什么表会怎么大呢？

接下来，举一些简单的例子，比如：

用于中国所有公民的个人信息和Internet上所有网站内容的表，这些表的总体规模可以达到PB以上级别，而且这些表的规模都会与日增长，所以很显然需要使用分布式的方法，而不是使用一台机器来承载这个巨大且不断增长的Table。

首先，会介绍一下BigTable最基本的数据模型，也就是table。

Table

图1. 

Table

这就是Table（表格），虽然上面截图只有三个Row和五个Column，但由于这个表会存储中国所有公民的个人信息，所以会有十三亿多Row和几百多Column，接下来，将介绍为了提高访问效率和伸缩性的两个特性：

ColunmFamily（列组）和Tablet（片）。

ColumnFamily

图2.ColumnFamily

由于每个表格都会有成百上千的Column，而大多数查询只需得到其中少数几个Column，所以如果每次查询都将所有的Column取出来的话，这样会得不偿失，所以Google在BigTable的设计中引入了ColumnFamily这个特性，通过这个特性能将多个Column并为一个小组，比如上图的“家庭地址”和“工作地址”都隶属于“地址”这个ColumnFamily，这样做的最大的好处是能将这些Column放在一起存储，这样不仅能提高存取效率，而且能避免读取过多的Column，比如可以选择只读取一个ColumnFamily。

Tablet

图3Tablet

这个非常容易理解，就是BigTable系统会自动根据RowName的范围，来将数据复制到不同的服务器上。

Timestamp

为了帮助数据的同步和备份，可以为每个Cell（单元格）设置相应的Timestamp，而且系统可以根据Timestamp来做GC（GarbageCollection）。

调用接口

Google的BigTable的调用接口主要以API为主，下面是一些示例代码，主要参考自BigTable的Paper。

//打开Table

Table*T=OpenOrDie（“/peopletable”）;

//找到相应的Row，并做相应的更新

RowMutationr1（T,”310101”）;

r1.Set（“地址:

家庭地址”,”SH88”）;

//执行更新

Operationop;

Apply（&

op,&

r1）;

//创建用于查询的Scanner

Scannerscanner（T）;

ScanStream*stream;

//查询相关的代码：

1.锁定“地址”这个CloumnFamily；

2.返回所有版本；

3.查找RowName是”310101”的列。

stream=scanner.FetchColumnFamily（“地址”）;

stream->

SetReturnAllVersion（）;

scanner.Lookup（“310101”）;

//打印

for（;

!

Done（）;

Next（））{

printf（“%s%s%lld%s\n”,Scanner.RowName（）,stream->

ColumnName,

stream->

TimeStamp, 

Value）;

}

下篇开发日记将关注BigTable的存储模型。

参考资料：

1.BigTable的Paper。

2.XX–大规模数据处理。

经过两个星期的努力（如果刨去学习C语言的时间），YunTable终于走完一个从无到有的历程，今天，也就是2010年7月12日，YunTable正式对外发布其0.1版，在0.1版中YunTable虽然在特性，优化和内存管理这三方面还有很多的缺失，但是总体而言，已经实现了一个身为BigTable克隆的基本要求，也就是分布式查询和管理，以及以column为核心的存储。

这是0.1版的下载链接（上次因为对Skydrive的存储机制不熟，导致部分博友没有第一时间拿到0.01版的源代码，在这里向大家表示我的歉意）。

架构综述

首先，请看下面是YunTable0.1版的架构图：

图1.YunTable架构（0.1版）

接下来，将按从上往下的顺序给大家介绍YunTable的架构：

1.Console：

用于让用户输入YunTable的命令，主要包括四种类型的命令（add，put，get和quit），并做一些简单的解析。

2.Master：

主要接收来自Console的请求，并将这个请求转发给相应的Region。

3.Region：

其作用主要是处理Master的请求，并存储和管理大量的数据，其主要包括多个store，而存储数据的目录名为”datastore“。

Region也就是BigTable论文中所提到的Tablet的服务器。

1.Store：

每个Store对应一个相应的columnfamily，系统在初始化的时候，会为默认的column_family（default_cf）创建一个store，store存储的形式为datastore下的一个目录，目录名为其所对应的column_family，并主要包括四类文件：

Memstore，YFile，YFile_data和WAL。

1.Memstore：

其是缓存在内存的数据文件，主要存储最新更新和添加的数据，每隔一段时间，在Memstore上缓存的数据都将会flush到YFile和YFile_data这两个文件中，默认时间间隔应该为60分钟，但0.1版为了测试方便，所以把设定的时间间隔暂定为10秒钟。

2.YFile：

其是持久化的文件，主要用于存储数据的Index，系统会根据从YFile中得到的Index来访问用于存储数据的YFile_data文件中的相应部分，而且由于其体积比较小，所以会在系统运行的时候被载入至内存中。

3.YFile_data：

这就是真正存储数据的文件，由于其体积比较大，所以不大会被存入内存。

YFile这个两个文件参考了HBase的HFile格式和Google的SSTable格式，并做了相应的简化。

4.WAL：

全称为“Write-AheadLog”，用于暂存那些数据更新的请求，以避免当Memstore被意外关闭时所造成的数据丢失，当Memstore完成对数据的写入时，WAL也会清空已经写入的请求。

一些限定

为了使YunTable在合理的时间内达到其0.1版，我在一些方面做了相应的范围缩小，所以YunTable0.1版有下面一些限定：

1.column_name和column_family_name的大小都被限制在16字节之内，如果输入column_name或者column_family_name的大小超过16字节，系统会将多余的字节自动删去。

同时假设在输入的时候，如果不为这个column设定相应的column_family，系统会认定其使用系统默认的columnfamily，也就是default_cf。

2.在分布式方面，为了缩小开发范围，采用了伪分布式的方式，也就是将Master和Region绑定在一起，并且只有一个初始Region可供选择。

3.在查询方面，暂不支持基于column的查询，但是支持基于rowkey的查询，具体可以看下面使用教程中的”Get“命令。

4.在内存管理方面和性能优化方面，由于这两方面在短期内并不关键，而且”过早的优化“也不是业界所推崇的，所以在0.1版中，没有在这两方面发力。

使用教程

首先，使用make来编译生成执行文件YunTable，可通过“./yuntable”来启动YunTable，并进入YunTable的Console，也可使用makeclean来清空之前生成的数据库文件。

接下来，将介绍YunTableConsole所支持四种命令：

1.add：

这个命令，是为了创建新的ColumnFamily存在的，格式是“addcolumn_family:

column_family_name”，在这里”columnfamily”是关键词，不可更改，而“column_family_name”则是等待用户输入的占位符，如果输入的ColumnFamily已经存在的了，Console会显示相应的错误信息。

例子：

addcolumn_family:

address。

2.put：

主要是用于添加数据，其格式是”put 

row:

row_keycolumn_name:

column_name_valuecolumn_family_name.column_name:

column_name_value“，在这里”row”是关键词，在其冒号后输入相应的row_key，比如在后面例子里面提到的”me“，在row之后那些，都不是关键字，只要按照那些占位符输入相应参数就可以，具体也可以参看后面的例子，但要注意，如果这个column不属于系统默认的columnfamily，那么请在columnfamily和column之间加入用于分割的“.”，例子：

putrow:

mename:

ikesex:

maleaddress.homeaddress:

sh。

3.get：

可以通过这个命令来获取数据，主要有两个选择：

第一个是“getall”，这主要是列出数据库中所有的数据，并安排rowkey大小的顺序（字典顺序）排列，但不会对输出的数据进行过滤。

另一个是“getrow:

row_key”，通过这个命令会获得这个row的数据，并且会对其输出的数据进行过滤，也就说，同一row同一column只会显示最新的一个值，例子：

getrow:

me。

4.quit：

这个命令最简单的，没有附加的命令，只有在console中输入“quit”就能退出YunTableConsole。

还有，如果大家第一次使用YunTable的话，可以参考下面附录里面的两个TestCase，特别推荐TestCase1，也就是短的那一个。

今后的安排

关于YunTable的未来，首先，我将会在《剖析云计算》一书的实践篇中，对YunTable的实现和其背后的理论进行详细的讲解。

其次，关于YunTable未来的发展，我还没有明确的规划，所以如果大家有兴趣在今后参与YunTable开发的话，可以直接在使用和分析YunTable之后将自己的想法发到我的邮箱ikewu83@，等我有空了之后，大家可以一起来商量商量，同时也可以直接动手改代码，来对YunTable进行更新和添加。

附录：

下面是两个YunTable的TestCase，一长一短，如果大家有兴趣的话，可以试一下。

TestCase1（短）

make

makeclean

./yuntable

1.addcolumn_family:

address

2.putrow:

sh

3.getall

4.quit

TestCase2（长）

1）beginpart

1.getall

2）addpart

*2.addcolumn_family:

3. 

add 

column_family:

address2

3）putpart

1.putrow:

m22name:

zhusex:

shaddress2.workaddress:

bj

3.putrow:

m1name:

wusex:

*4.putrow:

m3name:

huasex:

maleaddress3.playaddress:

5.putrow:

femaleaddress.homeaddress:

4）testlogpart

1.quit

5）getpart

2.getrow:

me

*3.getrow:

wrong

4.quit

*开头的命令，应该返回相应的错误信息