星期日, 六月 03, 2007

多线程环境下的Observer pattern

在“The Problem with Threads"论文中提到的用来抨击线程模型的实例。懒得说了,看代码直接:
public class ValueHolder{
private List listeners = new LinkedList();
private int value;

public interface Listener{
public void valueChanged(int newValue);
}

public void addListener(Listener listener){
listeners.add(listener);
}

public void setValue(int newValue){
value = newValue;
Iterator i = copyOfListeners.iterator();
while(i.hasNext()){
((Listener)i.next()).valueChanged(newValue);
}
}
}
以上代码存在问题是多线程环境下对listeners的竞争访问。既然如此,那在addListener和setValue方法前添加synchronzied。好了些,不过有死锁的可能,这主要是因为你不知道别人在valueChanged方法中会做什么,在调用这个方法时,你手中已经紧紧握住一把锁了。继续改进:
public class ValueHolder{
private List listeners = new LinkedList();
private int value;

public interface Listener{
public void valueChanged(int newValue);
}

public synchronized void addListener(Listener listener){
listeners.add(listener);
}

public void setValue(int newValue){
List copyOfListeners;

synchronized(this){
value = newValue;
copyOfListeners = new LinkedList(listeners);
}

Iterator i = copyOfListeners.iterator();
while(i.hasNext()){
((Listener)i.next()).valueChanged(newValue);
}
}
}
此种实现跟JDK源码util包中Observable实现类似,把竞争访问和死锁都排除了。不过此种实现仍存在问题。比如线程A和线程B依次调用setValue,然后线程B抢在线程A之前通知大家。这样就搞得大家认为ValueHolder中最终value值是线程A设置的值,而实际上是线程B设置的值。没办法,只能继续改进。
public class ValueHolder{
private List listeners = new LinkedList();
private int value;
private int seqnum = 0;
private int globalNum = 1;

public interface Listener{
public void valueChanged(int newValue);
}

public synchronized void addListener(Listener listener){
listeners.add(listener);
}

public void setValue(int newValue){
List copyOfListeners;
int localSeqnum;

synchronized(this){
value = newValue;
copyOfListeners = new LinkedList(listeners);
seqnum++;
localSeqnum = seqnum;
}
while(localSeqnum != globalNum){
//Only to wait
}
Iterator i = copyOfListeners.iterator();
while(i.hasNext()){
((Listener)i.next()).valueChanged(newValue);
}
globalNum++;
}
}
以上是我提供的一个实现,不知还有没有问题。关键一点,保证setValue按序执行。

注意:在Java中,局部变量都是线程私有的,不用担心访问冲突,要担心的就是实例变量和类变量。

星期六, 六月 02, 2007

Thread的层次结构

要弄清楚Thread的层次结构,必须先弄清楚它的参照系。看看“The Futures of Ruby Threading”这段话:“Current stable releases of Ruby use user space threads (also called "green threads"), which means that the Ruby interpreter takes care of everything to do with threads. This is in contrast to kernel threads, where the creation, scheduling and synchronization is done with OS syscalls, which makes these operations costly, at least compared to their equivalents in user space threads.”这里的用户空间线程和内核线程是相对于Ruby解释器来说的。如果把参照系换成操作系统,此处的内核线程只是一个用户空间线程。

常说Java线程是Native thread,是说Java的一个线程映射到操作系统上的一个用户线程。往下随后怎么映射就要看操作系统的实现了。可以看看Solaris的线程模型这里也有些说明资料。

不过Java线程也并不一定是一一映射的,比如Jikes RVM虚拟机,采用了M:N模型,而不是大家经常看到的1:1,具体资料可以看这里。BEA的JRockit是两个都有,既支持1:1模型,也支持M:N模型,叫Thin Thread。

在JVM上实现了M:N模型,当然在操作系统上也可以实现M:N模型,只是层次不同,抽象级别不同。象Solaris就实现了M:N模型,不过这个模型在Solaris 9中已经放弃,为什么?实现太难。“It is not to say that a good implementation of the M:N model is impossible,but simply that a good 1:1 implementation is probably sufficient. ”想更进一步了解Solaris多线程的发展历程,看这个pdf吧(www.sun.com/software/whitepapers/solaris9/multithread.pdf)。

了解清楚Thread的层次结构,碰到Green Thread,Native Thread,User space Thread,Kernel Thread时才不会糊涂。

Thread被过度使用

既然Thread质疑声一片,为什么它仍能够存在呢?原因有:
(1)某些应用程序天生就具有并发特性,而且需要共享地址空间和各种资源,比如数据库服务器。
(2)进程方案开销大。
(3)Java语言大行其道,使得绝大部分程序员认为并发编程唯一也是最好的方式就是采用多线程,而且在Java语言中创建一个线程非常简单。

对于第二点,只有线程创建,线程同步,线程加锁等开销比进程方案开销小,才会真正获益。只是来个线程创建和进程创建开销的比较,那也太天真了。此处,我认为还要包括开发,维护进程并发程序和线程并发程序两种方式之间的开销对比。毕竟,除了机器时间,人的时间也很宝贵。

对于第三点,Java是不是会在以后考虑另外的并发模式。象建立在JVM之上的Scala语言就在采用Actor模式。多个选择,总是不错的主意。不然搞得我们这些开发人员都去用Thread,使得Thread被过度使用,破坏Thread的名声。


附:如果想了解Thread在哪些方面被广泛批评,请参考如下资料:
(1)《The Art of Unix Programming》的“Threads-Threat or Menace?”
(2)“Why Threads Are a Bad Idea”
(3)“The Problem with Threads”

星期四, 五月 31, 2007

Green Thread不比Native Thread差

在Ruby实现中,Ruby1.8采用的是Green thread,JRuby和XRuby采用的是Native thread,Rubinius既支持Green thread,也支持Native thread。Ruby1.9将由Green thread转向Native thread。Green thread有哪些不足呢?

在“Ruby Userspace Threads vs GUI tookits Roundup”中重点强调了Green Thread的一个不足:Blocking syscall将阻塞所有其余的线程,而且这个问题在GUI和网络开发中将随处碰到。另外,Green Thread不能有效挖掘多核和多CPU的性能。于是大家都把视线转向Native thread。我对Native thread不感冒,主要是因为shared state concurrency问题多多。具体有哪些,相信你看完“The problem with threads”就会很清楚了。

现在,Erlang很好的解决了Green Thread存在的问题。它没有采用m:1模式,而是采用了m:n模式。Erlang runtime以n个native thread运行,每个都有一个自己的调度器。而且,Erlang采用shared nothing concurrency,可以把Native Thread存在的问题都抛之脑后。

看来XRuby的thread实现可以好好借鉴一下Erlang的并发范式。在看了“The Futures of Ruby Threading”之后,更坚定了应该朝这方面努力。

星期三, 五月 30, 2007

有了OpenMP,MPI,为什么还要MapReduce?

OpenMP和MPI是并行编程的两个手段,对比如下:
  • OpenMP:线程级(并行粒度);共享存储;隐式(数据分配方式);可扩展性差;
  • MPI:进程级;分布式存储;显式;可扩展性好。
OpenMP采用共享存储,意味着它只适应于SMP,DSM机器,不适合于集群。MPI虽适合于各种机器,但它的编程模型复杂:
  • 需要分析及划分应用程序问题,并将问题映射到分布式进程集合;
  • 需要解决通信延迟大和负载不平衡两个主要问题;
  • 调试MPI程序麻烦;
  • MPI程序可靠性差,一个进程出问题,整个程序将错误;
其中第2个问题感受深刻。每次听我们部门并行组的人做报告,总是听到他们在攻克通信延迟大和负载不平衡的问题。一种并行算法的好坏就看它有没有很好的解决这两个问题。

与OpenMP,MPI相比,MapReduce的优势何在呢?
  • 自动并行;
  • 容错;
  • MapReduce学习门槛低。
附:
  • SMP(Symmetric multi-processing),共享总线与内存,单一操作系统映象。在软件上是可扩展的,而硬件上不能。
  • DSM(distributed shared memory),SMP的扩展。物理上分布存储;单一内存地址空间;非一致内存访问;单一操作系统映象。

多核意味着什么?

过去,提升CPU性能的方法有:
  • 时钟速度
  • 执行优化
  • 缓存
此时用户程序无须修改,就可以获得CPU性能提升所带来的好处。现在,提升CPU性能的方法:
  • 超线程
  • 多核
  • 缓存
此时虽然缓存能,但超线程和多核CPU对现在的绝大多数应用,几乎不会有任何影响。多核还说不定会降慢程序的运行,因为多核带来的是更强的并行处理能力、更高的计算密度和更低的时钟频率。如果不采用并发好好利用硬件资源,多核CPU真的是浪费。

另外,还有一些问题需要注意。有了多核,有时候还是感觉应用程序慢,此时问题可能就不是出在CPU上。要知道就算是单核,在日常工作中,CPU的利用率远没有达到100%。有时候,应用程序的瓶颈可能是在I/O,可能在网络,或者数据库,等等。有了计算能力,还有很多工作要做。

Google Groups:JVM Languages

通过Charles Oliver Nutter博客了解到,他弄了一个Google Groups,目的是讨论如何在JVM之上搞一个框架,以便有更多的语言落户在JVM之上。Motivation何在,我猜是想搞一个“DLR-like”平台。
目前,我主要关注的是xruby,jruby,scala在JVM平台上的实现。

附:
(1)DLR(Dynamic Language Runtime)是Microsoft搭建在CLR之上的一个框架,用来更好的支持动态语言;
(2)Scala:引入Erlang并发范式,建立在JVM之上的语言。

星期一, 五月 28, 2007

测试Hadoop Trunk代码

从SVN上checkout代码,然后部署在了两台Linux机器之上。Hadoop版本为0.12.4。过程还是挺顺利的,这得益于以前折腾过Hadoop 0.5版。

如果你在安装的过程中,发现问题,可以参考用Hadoop搭建分布式存储和分布式运算集群。 当然你可以通过Email或者Gtalk与我联系。好久没有关注Hadoop了,发现它已经越来越成熟,开始步入实际使用阶段,比如Amazon 的 EC2 S3

另外,令人非常兴奋的是,Yahoo推出Pig。从介绍可知,这是一个非常有意思的项目,建立在Hadoop之上。

星期日, 五月 27, 2007

与搜索相关的研发工作

想从事与搜索相关的研发工作,需要哪些知识。带着这个疑问,我查看了包括Google,Baidu,Yahoo,腾讯,Sohu,Sina,阿里巴巴等公司的招聘信息。自我总结如下:
  • 为什么要从事研发工作?
  1. 在公司处于核心地位;
  2. 把研究和开发紧密而完美的结合在一起;
  • 研发职责是什么?
  1. 负责搜索引擎系统的架构设计以及核心模块的系统设计;
  2. 进行搜索引擎系统核心模块的编码和技术研发;
  3. 重点技术难题的攻关;
  • 想从事研发工作,需要什么?
  1. 强烈责任心,开放的性格,良好的沟通能力;拥有极强的发现问题、分析问题、解决问题的能力;
  2. Fluency in English(Reading and Writing);
  3. 对算法设计、数据结构有深刻的理解;
  4. 精通Linux/Unix平台上的C/C++语言编程,熟练使用调试工具;熟悉网络、多线程编程技术(熟悉Unix系统调用io, socket, process, signal);如果懂Java,将更好;
  5. 能够使用一种脚本语言(perl,shell或者python);
  6. 具有搜索、信息检索相关领域开发经验者优先;
  7. 至少熟悉一种数据库系统,你可以选择MySql作为自己重点攻克的对象。
  • 想成为架构师,还需要什么?
  1. 熟悉分布式系统架构设计,具备大流量、大访问量、高负载环境下的系统开发及优化经验;
  2. 知识面广,思路开阔,对业界的最新技术发展动态有比较密切的关注;
  3. 对软件开发生命周期比较熟悉,具备较强的文档编写能力及项目管理能力。
想从事研发工作的朋友可以对照上面的要求,找出自己的不足。对于你来说,那些不足就是最重要的。缺什么,什么就最重要。

Update:一些更加细化的指标,比如:
  • 搜索引擎各子系统(Spider、Indexer、Searcher、分词、网页仓库)的设计和实现。
  • 搜索引擎的性能优化分析和功能升级。

星期二, 五月 15, 2007

继续写博客,记录自己的成长

开博多处,不过全都停了下来。今天,重新开始,将在这里记录自己的每一天生活。

(1)嘻嘻哈哈才是我:http://zyxt.blogdriver.com(最早的地方,也是所呆时间最长的地方)。
(2)飞翔的章鱼:http://zyxt.blog.hexun.com/(目前内容已经全部删除!)。
(3)naivebaby:http://blog.csdn.net/naivebaby(技术blog)。
(4)我是一只小小鸟:现在这个(由于当初google blog被禁,于是放弃)。
(5)**blog:(暂且保密)。

btw:这里主要记录我在技术上的一些感悟,要了解我的生活,请访问链接中的"My Childlike Life"!

星期三, 十月 25, 2006

基本算法连载(14)-BST(Binary Search Tree)的笔记

插入实现(传指针地址的地址):

void InsertNode(struct node **node_ptr, struct node *newNode) {
struct node *node = *node_ptr;
if (node == NULL)
*node_ptr = newNode;
else if (newNode->value <= node->value)
InsertNode(&node->left, newNode);
else
InsertNode(&node->right, newNode);
}

删除节点:

void DeleteNode(struct node*& node) {
struct node*&amp; temp = node;
if (node->left == NULL) {
node = node->right;
delete temp;
} else if (node->right == NULL) {
node = node->left;
delete temp;
} else {
// Node has two children - get max of left subtree
temp = node->left;
while (temp->right != NULL) {
temp = temp->right;
}
node->value = temp->value;
DeleteNode(temp);
}
}

星期日, 十月 22, 2006

基本算法连载(13)-递归程序转变成非递归

用堆栈实现递归其实并没有消除递归,只不过人工做了本来由编译器做的事情。真正的非递归是指运算时所需要的空间是常数,即所需空间与问题的输入规模无关。并非所有递归都可以转换成非递归,比如著名的Ackmann函数。
递归转非递归方法:
(1)用一般公式直接代替。象经常看到的斐波那契数列,它就存在通项公式,而无需采用递归实现。
(2)使用栈来实现
(3)通过Cooper变换、反演变换将一些递归转化为尾递归,从而迭代求出结果
至于什么是Cooper变换,反演变换,这可得好好研究数学。这里贴两个变换实例。

计算阶乘的递归实现(用Haskell实现的,谁都看得懂):f x = if x = 0 then 1 else f(x-1)*x;
第一步:转变成尾递归

int G(int x, int y)
{
int x1, y1;

if (x == 1) {
return 1 * y;
} else {
x1 = x - 1;
y1 = x *y;
return G(x1, y1);
}
}

int f(int x)
{
return G(x, 1);
}

第二步:转变成迭代

int G(int x, int y)
{
int x1, y1;

loop:
if (x == 1) {
return 1 * y;
} else {
x1 = x - 1;
y1 = x *y;
x = x1
y = y1;
goto loop;
}
}


求斐波那契值:
f x |x==0 =0
|x==1 =1
|otherwise = f (x-1)+f (x-2)

第一步:转变成尾递归
int fib(int n){
if(n==0)
return 0;
return _fib(n,1,0);
}

int _fib(int n,int f1,int f2){
if(n==1)
return f1;
return _fib(n-1,f1+f2,f1);
}

第二步:转变成迭代(略)

星期六, 十月 21, 2006

基本算法连载(12)-顺序查找的两个实现

顺序表的实现,天下人都知道,最最简单的一种,不过我还是贴出两个实现,大家看看:

int search(int a[],int key,int length){
int i;
for(i=length-1;i>=0;i--){
if(a[i]==key)
return i;
}
return -1;
}

/*
* 实际数组元素是从1号位置起开始存储,0号位置存储key
*/
int search(int a[],int key,int length){
int i;
a[0] = key;
for(i=length;!(a[i]==key);i--);
return i;
}

由此,想到了字符串的拷贝实现:

for(i=0;0!=(dst[i]=src[i]);i++);

星期一, 十月 16, 2006

基本算法连载(11)-两个基本概念:in-place和tail-end recursion

平时看算法,经常碰到in-place algorithm和tail-end recursion两个概念。今天终于了解了这两个概念。
In-place算法:The input is usually overwritten by the output as the algorithm executes.函数语言是不鼓励或支持in-place算法的,它把overwriiten当作side effect。函数语言,听过不少,没有学过,有时间得学学。
代码:

int sum(int n){
int i;
int sum = 0;
for(i=1;i<=n;i++){
sum = sum+i;
}
return sum;
}

此处的sum就被overwritten,可以算作in-place算法。

Tail-end recursion(tail recursion):函数所做的最后一件事情是一个函数调用,被称作尾部调用(tail-call)。使用尾部调用的递归程序称为尾部递归。tail-recursion是很容易转变成iteration的。在把尾部递归程序转变成非递归程序时,我们就有了理论保证。尾部调用是可以进行优化的:在尾部进行函数调用时使用一个栈结构覆盖当前的栈结构,同时保持原来的返回地址。
以下的代码展示的是一个更一般化的tail recursion,它先转变成熟悉的tail recursion,然后转变成iteration。看惯了Java代码,看这个还有点不习惯。
代码:

#include <stdlib.h>
typedef struct list{
int value;
struct list* next;
}list;

//----------------------------------
//一般化的tail-recursion
list* f(list* input){
list* head;
if(input == NULL){
head = NULL;
}else{
head = (list*)malloc(sizeof(list));
head->value = input->value;
head->next = f(input->next);
}
return head;
}

//------------------------------------
//熟悉的tail-recursion
void fprime(list* input,list** p){
if(input == NULL){
*p = NULL;
}else{
*p = malloc(sizeof(list));
(*p)->value = input->value;
fprime(input->next,&(*p)->next);
}
}

list* f1(list* input){
list* head;
fprime(input,&head);
return head;
}

//------------------------------------
//iteration
list* f2(list*input){
list* head;
list** p;
p = &head;
while(input != NULL){
*p = (list*)malloc(sizeof(list));
(*p)->value = input->value;
input = input->next;
p = &(*p)->next;
}
*p = NULL;
return head;
}



星期四, 十月 12, 2006

基本算法连载(10)-模式匹配之BM(Boyer-Moore)

周末两天被BM算法折磨的要死。《a fast string search algorithm》论文中提到的算法思想倒是理解的差不多,但网上(http://www-igm.univ-mlv.fr/~lecroq/string/node14.html#SECTION00140)给出的实现可就是看不懂。通过Baidu,Google一搜,可以看到很多Boyer-Moore的实现。但绝大部分实现都是简化版本,只考虑了bad-character shift,而忽略了good-suffix shift。
它思想的源泉是从右向左匹配字符串将获得更多有用的信息。The algorithm precomputes two tables to process the information it obtains in each failed verification: one table calculates how many positions ahead to start the next search based on the identity of the character that caused the match attempt to fail;the other makes a similar calculation based on how many characters were matched successfully before the match attempt failed.其中前一个称作bad-character shift,后一个称作good-suffix shift。想详细了解Boyer-Moore的思想,我极力推荐看作者发表的论文,它比网上对这个算法介绍的文章容易理解的多。
处理主串为n,模式串为m的情况,此算法的最好表现是:n/m。在这种情况下,只有模式串中的最后一个字符需要比较。不相等,马上可以跳过m个字符。从这里可以看出此算法一个违反直觉的性质:模式串越长,搜索越快。
最优的代码实现(没看懂,明天贴个我自己改的):
void preBmBc(char *x, int m, int bmBc[]) {
int i;

for (i = 0; i < ASIZE; ++i)
bmBc[i] = m;
for (i = 0; i < m - 1; ++i)
bmBc[x[i]] = m - i - 1;
}


void suffixes(char *x, int m, int *suff) {
int f, g, i;

suff[m - 1] = m;
g = m - 1;
for (i = m - 2; i >= 0; --i) {
if (i > g && suff[i + m - 1 - f] < i - g)
suff[i] = suff[i + m - 1 - f];
else {
if (i < g)
g = i;
f = i;
while (g >= 0 && x[g] == x[g + m - 1 - f])
--g;
suff[i] = f - g;
}
}
}

void preBmGs(char *x, int m, int bmGs[]) {
int i, j, suff[XSIZE];

suffixes(x, m, suff);

for (i = 0; i < m; ++i)
bmGs[i] = m;
j = 0;
for (i = m - 1; i >= -1; --i)
if (i == -1 || suff[i] == i + 1)
for (; j < m - 1 - i; ++j)
if (bmGs[j] == m)
bmGs[j] = m - 1 - i;
for (i = 0; i <= m - 2; ++i)
bmGs[m - 1 - suff[i]] = m - 1 - i;
}


void BM(char *x, int m, char *y, int n) {
int i, j, bmGs[XSIZE], bmBc[ASIZE];

/* Preprocessing */
preBmGs(x, m, bmGs);
preBmBc(x, m, bmBc);

/* Searching */
j = 0;
while (j <= n - m) {
for (i = m - 1; i >= 0 && x[i] == y[i + j]; --i);
if (i < 0) {
OUTPUT(j);
j += bmGs[0];
}
else
j += MAX(bmGs[i], bmBc[y[i + j]] - m + 1 + i);
}
}


基本算法连载(9)-模式匹配之KMP(Knuth-Pratt-Morris)

KMP算法,在《数据结构》课上听过,似是非懂,读完大学后全忘光了。Brute-Force算法,简单,谁都知道。从主串S的第pos个字符起与模式串进行比较,匹配不成功时,从主串S的第pos+1个字符重新与模式串进行比较。如果主串S的长度是n,模式串长度是m,那么Brute-Force的时间复杂度是o(m*n)。最坏情况出现在模式串的子串频繁出现在主串S中。虽然它的时间复杂度为o(m*n),但在一般情况下匹配时间为o(m+n),因此在实际中它被大量使用。
前几日,重新拾起了KMP算法,然后向MM讲解之。KMP的主要思想是:每当一趟匹配过程中出现字符比较不等时,不需回溯主串S的指针,而是利用已经得到的“部分匹配”结果将模式串向右“滑动”尽可能远的一段距离后,继续进行比较。
模式串到底向右滑动多少,在KMP算法中是用一个数组来存储的。针对模式串中的每个索引j,都将有一个对应的值。此值的含义为模式串中位置从0到j-1构成的串中所出现的首尾相同的子串的最大长度加1。
下面给出具体实现:
/*
* n is the length of text,while m is the length of pattern.
* And pos which is zero-indexed is the start point of search.
*/
int kmp(char* text,int n,char *pattern,int m,int pos){
int i,j;
//Generate the array of next
int* next = (int*)malloc(m*sizeof(int));
i = 0;
j = -1;
next[i] = j;
while(i<m){
if((j==-1) || (pattern[i]==pattern[j])){
i++;
j++;
if(pattern[i]!=pattern[j])
next[i] = j;
else
next[i] = next[j];
}else{
j = next[j];
}
}

int k = 0;
for(k=0;k<m;k++)
printf("next:%d\n",next[k]);

//Search
i = pos;
j = 0;
while(i<n&&j<m){
if((j==-1) || (text[i]==pattern[j])){
i++;
j++;
}else{
j = next[j];
}
}
if(j==m)
return i-m;
else
return 0;
}
KMP算法的时间开销包括两部分,一个是求next数组元素的值,此时的时间开销是o(m);一个是搜索,此时的时间开销是o(n)。因此,它的时间复杂度是o(m+n)

星期一, 十月 09, 2006

看《The Google File System》后的一些笔记

看了基于Google File System思想实现的Hadoop代码,重读了Google的这篇论文《The Google File System》。Paper挺长,网上已经有热心的人把翻译版奉献了出来。在这里,只是把其中的部分内容抽取出来,与大家一起分享。
性能,可扩展性,可靠性,可用性仍然是GFS的目标,但它还有一些与传统分布式文件系统与众不同的东西:
(1)对于大规模的集群系统,机器出现故障很正常,因此系统容错必须十分重视。文件系统必须具有高可用性,数据完整性和相应的诊断工具。通过快速恢复,chunk复制,master复制达到高可用性;通过checksum检查数据完整性;通过log记录系统中出现的各种事件,以便诊断错误。
(2)传统文件系统的block的大小只有几k,而GFS将选用64M,以满足当前出现的越来越庞大的数据集处理需求。选用大的chunk size,可以:
a、减少与master的交互次数;
b、大部分的时候,对chunk的操作都集中在一个chunk上,因此可以维护一个持久的TCP连接减小网络开销;
c、减少存储在master上的元数据把它放在内存中。
在具有优点的同时,存在缺点,就是多个客户端同时访问同一个文件(此文件比较小,由一个chunk组成),易形成hot spot。
(3)通过观察发现,绝大部分的时候,对文件的修改操作都只是附加内容,很少是翻盖写或者随机写。因此在GFS中,对文件附加操作进行重点优化。

GFS的体系结构
GFS的体系结构是由一个master和多个chunkserver组成(在Hadoop中,master称作name node,chunkserver称作data node,chunk称作block)。
采用单一的master,可以简化系统设计,在拥有全局视图的情况下制定更好的chunk处置策略。采用此种方法,存在瓶颈问题是显而易见的。因此master只存储元信息,相当于元数据服务器,具体的数据传输由client和chunkserver来完成。

元数据
包括三类元数据,它们分别是:文件和chunk的命名空间,文件到chunk的映射和每个chunk副本的位置。元数据全部放入内存,这样可以加快master的操作速度,但它受限于内存大小。

操作日志
对文件系统的操作都将被记录到持久化存储介质,通过重新执行这些操作来达到恢复文件系统的目的。当操作日志达到一定大小时,将做checkpoint,这样可以减少文件系统的恢复时间。目前,Hadoop不支持对操作日志做checkpoint。

Data Flow
在GFS中,数据流和控制流分开,这是显而易见的。数据流怎么流动,具有一定的技巧性。它采用的是pipeline方式。一个chunkserver并不是把数据同时分发给其余的chunkserver,而是把数据只传给离自己最近的chunkserver(距离的远近通过IP地址来判断)。此时这个chunkserver在接受数据的同时,把数据转发给离它最近的chunkserver,这样充分利用了全双工网络的带宽。

以上只谈到paper中涉及的一些方面,完整内容请阅读paper。

星期四, 九月 21, 2006

基本算法连载(8)-Library Sort(gapped insertion sort)

特色:Library sort优于传统的插入排序(时间复杂度为O(n^2)),它的时间复杂度为O(nlogn),采用了空间换时间的策略。
思想:一个图书管理员需要按照字母顺序放置书本,当在书本之间留有一定空隙时,一本新书上架将无需移动随后的书本,可以直接插空隙。Library sort的思想就源于此。
实现:有n个元素待排序,这些元素被插入到拥有(1+e)n个元素的数组中。每次插入2^(i-1)个元素,总共需要插logn趟。这2^(i-1)个元 素将被折半插入到已有的2^(i-1)个元素中。因此,插入i趟之后,已有2^i个元素插入数组中。此时,执行rebalance操作,原有处在(1+ e)2^i个位置的元素将被扩展到(2+2e)2^i个位置。这样,在做插入时,由于存在gap,因此在gap未满之前无需移动元素。
具体代码

/*
* length:待排序元素个数
* elements:待排序数组
* factor:常数因子
*/
void librarySort(int length,float factor,int elements[]){
int i,j;
//扩展后的数组长度
int expandedLen = (int)((1+factor)*length);
int* orderedElem = (int*) malloc(expandedLen*sizeof(int));

//标志gap
int flag = 1<<31;
for(i=0;i<expandedLen;i++){
orderedElem[i] = flag;
}

int index = 1;
int numOfIntercalatedElem = 1;
orderedElem[0] = elements[0];

while(length>numOfIntercalatedElem){
//第i次插入2^(i-1)个元素
for(j=0;j<numOfIntercalatedElem;j++){
//待插入元素为elements[index]
//------------折半插入---------------
int mid;
int low = 0;
int high = 2 * numOfIntercalatedElem - 1;
while(low <= high){
mid = (low + high)/2;

int savedMid = mid;
//如果mid所在位置为gap
while(orderedElem[mid] == flag){
if(mid == high){
//当向右遍历没有找到元素值时,改成向左遍历
mid = savedMid - 1;
while(orderedElem[mid] == flag){
mid--;
}
break;
}
mid++;
}

if(elements[index] > orderedElem[mid]){
low = mid + 1;
//缩小范围
while(orderedElem[low] == flag){
low = low+1;
}
}else{
high = mid - 1;
}
}

//把elements[index]插入到orderedElem[high+1]
//当位置为空,没有存储元素值时...
if(orderedElem[high+1] == flag){
orderedElem[high+1] = elements[index];
}else{
//位置非空,首先往前挪动元素,如果前面已满,向后挪动元素
int temp = high+1;
while(orderedElem[temp] != flag){
temp--;
if(temp < 0){
temp = high+1;
break;
}
}

//向后移动
while(orderedElem[temp] !=flag){
temp++;
}

while(temp < high){
orderedElem[temp] = orderedElem[temp+1];
temp++;
}

while(temp > high+1){
orderedElem[temp] = orderedElem[temp-1];
temp--;
}

orderedElem[temp] = elements[index];
}
//---------------------------------
index++;
if(index == length){
break;
}
}

numOfIntercalatedElem *=2;
int generatedIndex;
//Rebalance...
for(j=numOfIntercalatedElem;j>0;j--){
if(orderedElem[j] == flag){
continue;
}
//原数组元素从i处移到2i处
generatedIndex = j*2;
if(generatedIndex >= expandedLen){
generatedIndex = expandedLen - 1;
if(orderedElem[generatedIndex] != flag){
break;
}
}
orderedElem[generatedIndex] = orderedElem[j];
orderedElem[j] = flag;
}
}
//测试输出
for(i=0;i<expandedLen;i++){
printf("%d\n",orderedElem[i]);
}

}

星期一, 九月 18, 2006

基本算法连载(7)-Skip List(下)

基本算法连载(6)-Skip List(上)

Skip List号称性能与BST(Binary Sort Tree)树有得一拼,于是把它翻了个底朝天。代码是阐述其思想的最好方式,那我们还是看看它的具体实现(采用Java语言)
public class SkipList {

public static final int NOT_FOUND = -1;
public static final int HEADER_KEY = -2;
public static final int NIL_KEY = Integer.MAX_VALUE;

// optimum probability
public static final float OPT_PROB = 0.25f;
private float myProbability;
// probability to increase level
private int myMaxLevel;
// upper bound of levels
private int myLevel;
// greatest level so far
private SkipListElement
myHeader; // the header element of list

/*
* Constructs a new skip list optimized for the given
* expected upper bound for the number of nodes.
*/

public SkipList(long maxNodes) {
// probability set to 0.25 and maximum level
// of list is depending on expected number of nodes
// (see paper for mathematical background)
this(OPT_PROB,(int)Math.ceil(Math.log(maxNodes)/Math.log(1/OPT_PROB))-1);
}

public SkipList(float probability, int maxLevel) {
myLevel = 0;
myProbability = probability;
myMaxLevel = maxLevel;
// generate the header of the list
myHeader = new SkipListElement(myMaxLevel,HEADER_KEY, 0);

// append the "NIL" element to the header
SkipListElement nilElement = new SkipListElement(myMaxLevel, NIL_KEY, 0);
for (int i=0; i<=myMaxLevel; i++) {
myHeader.forward[i] = nilElement;
}
}

/*
* Generates with help of randomizer the level of a new element.
* The higher a level, the less probable it is (see paper).
* Levels begin at 0 (not at 1 like in the paper).
*/
private int generateRandomLevel() {
int newLevel = 0;
while (newLevel<myMaxLevel &&Math.random()<myProbability ) {
newLevel++;
}
return newLevel;
}

/*
* Inserts a new node into the list.
* If the key already exists, its node is updated to the new value.
*/
public void insert(int searchKey, int value) {
// update pointers to next elements on each level and
// levels run from 0 up to myMaxLevel.
SkipListElement[] update = new SkipListElement[myMaxLevel+1];

// init "cursor" element to header
SkipListElement element = myHeader;

// find place to insert the new node
for (int i=myLevel; i>=0; i--) {
while (element.forward[i].key <searchKey) {
element = element.forward[i];
}
update[i] = element;
}

element = element.forward[0];

// element with same key is overwritten
if (element.key == searchKey) {
element.value = value;
}else{
// or an additional element is inserted
int newLevel = generateRandomLevel();
// element has biggest level seen in this list,update list
if (newLevel > myLevel) {
for (int i=myLevel+1;i<=newLevel; i++) {
update[i] = myHeader;
}

myLevel = newLevel;
}

// allocate new element:
element = new SkipListElement(newLevel,searchKey, value);
for (int i=0; i<=newLevel; i++) {
element.forward[i] = update[i].forward[i];
update[i].forward[i] = element;
}
}

}

/*
* Search for a given key in list. You get the value associated
* with that key or the NOT_FOUND constant.
*/

public int search(int searchKey) {
// init "cursor"-element to header
SkipListElement element = myHeader;

// find element in list:
for (int i=myLevel; i>=0; i--) {
SkipListElement nextElement = element.forward[i];
while (nextElement.key < searchKey) {
element = nextElement;
nextElement = element.forward[i];
}
}

element = element.forward[0];
if (element.key == searchKey) {
return element.value;
}else {
return NOT_FOUND;
}

}

public void delete(int searchKey) {
// update holds pointers to next elements of each level
SkipListElement update[] = new SkipListElement[myMaxLevel+1];

// init "cursor"-element to header
SkipListElement element = myHeader;

// find element in list
for (int i=myLevel; i>=0; i--) {
SkipListElement nextElement = element.forward[i];
while (nextElement.key < searchKey) {
element = nextElement;
nextElement = element.forward[i];
}
update[i] = element;
}

element = element.forward[0];
// element found, so rebuild list without node
if (element.key == searchKey) {
for (int i=0; i<=myLevel; i++) {
if (update[i].forward[i] == element) {
update[i].forward[i] = element.forward[i];
}
}

// element can be freed now
element = null;

// maybe we have to downcorrect the level of the list
while (myLevel>0&& myHeader.forward[myLevel].key==NIL_KEY){
myLevel--;
}
}
}

/*
* inner class
*/

private class SkipListElement {
int key;
int value;
int level;

// array of forward pointers
SkipListElement forward[];

public SkipListElement(int level, int key, int value) {
this.key = key;
this.value = value;
this.level = level;
forward = new SkipListElement[this.level+1];
}
}

}