银河里的星星
昨晚燕子来到北京，约好今天碰头。只是时间稍紧，于是定好早上8点过去。平日里一般都是九点多起床，今天醒来刚好七点，大幸。不过还有些担心能否八点到，洗漱完毕，赶紧打车赶去，所幸到了才七点四十。
由于这次时间太紧，没有喊下所有同学。于是只有我二人独向前门行去，到了前门，找个小吃店，只是发现这北京的豆汁实在是难喝，尽管如此，我还是把我那份喝光了。。。之后便边聊边走向TAM，毕竟燕子同学第一次来京，时间短暂，还是简单膜拜下吧。然后转了一转，其实我不喜欢在TAM里转，那里人总是太多，只是故宫的围墙外却颇有几分寂静，于是走出TAM沿着护城河继续赶路，中间顺便小憩了一会。中间boss发来短信，于是约好后海全聚德碰头。待我们到时，boss还未出现，于是便沿着后海转了一下，之前第一次来便觉得这是一个清凉之地，尤其是到了晚上，灯火通明，伴着酒吧的歌声，宛若那六朝繁华的十里秦淮。
SQL解析
http://www.cnblogs.com/RicCC/archive/2008/03/09/OQL-ANTLR-SQL-Parser.html ANTLR实现的SQL解析器 – OQL
http://packages.python.org/sqlparse/ python sqlparser
http://www.cppblog.com/woaidongmao/archive/2008/11/22/67588.aspx 用Lex和Yacc做一个简单的SQL解释器
http://foja.dcs.fmph.uniba.sk/kompilatory/docs/compiler.pdf Compiler Construction using Flex and Bison
zz from：http://blog.csdn.net/wh62592855/archive/2011/05/17/6427766.aspx
【原文】 Hive – A Petabyte Scale Data Warehouse Using Hadoop
【作者】 Facebook 数据架构组 ： Ashish Thusoo, Joydeep Sen Sarma, Namit Jain, Zheng Shao, Prasad Chakka, Ning Zhang, Suresh Antony, Hao Liu and Raghotham Murthy
作者：Mike Burrows Google Inc 2006
译者：phylips@bmy 2011-7-2
出处：http://duanple.blog.163.com/blog/static/7097176720112643946178/
摘要
本文描述了我们在Chubby锁服务系统上的相关经验。该系统旨在为松散耦合的分布式系统提供粗粒度的锁以及可靠性存储(低容量的)。Chubby提供了一个非常类似于具有建议性锁的分布式文件系统的接口，设计的侧重点在可用性及可靠性而不是高性能。该服务已有很多应用多年的运行实例，其中一些实例可能同时为成千上万个客户端提供服务。本论文描述了其最初的设计及期望的应用，并通过将其与实际应用情况进行对比，来说明设计应如何修正以容纳各种差异。
英文原文：http://infolab.stanford.edu/~backrub/google.html
中文版：http://leoncom.org/?p=650350
【摘要】 这篇文章中，我们介绍了google，它是一个大型的搜索引擎的原型，搜索引擎在超文本中应用广泛。Google的设计能够高效地抓网页并建立索引，它的查询结果比其它现有系统都高明。这个原型的全文和超连接的数据库至少包含24000000个网页。我们可以从http://google.stanford.edu/ 下载。设计搜索引擎是一项富有挑战性的工作。搜索引擎为上亿个网页建立索引，其中包含大量迥然不同的词汇。而且每天要回答成千上万个查询。在网络中，尽管大型搜索引擎非常重要，但是学术界却很少研究它。此外由于技术的快速发展和网页的大量增加，现在建立一个搜索引擎和三年前完全不同。本文详细介绍了我们的大型搜索引擎，据我们所知，在公开发表的论文中，这是第一篇描述地如此详细。除了把传统数据搜索技术应用到如此大量级网页中所遇到的问题，还有许多新的技术挑战，包括应用超文本中的附加信息改进搜索结果。本文将解决这个问题，描述如何运用超文本中的附加信息，建立一个大型实用系统。任何人都可以在网上随意发布信息，如何有效地处理这些无组织的超文本集合，也是本文要关注的问题。
一些观点：
Never use Singleton, this is nothing but a honking huge global variable whose initialization is bound to the lifetime of your process not the resource it manages.
What you want is an object injected into every scope that depends on it, in other words the pattern you are looking for is Dependency Injection.
作者：Cary G.Gray and David R. Cheriton 1989
译者：phylips@bmy 2011-5-7
出处：http://duanple.blog.163.com/blog/static/70971767201141111440789/
[
序：所谓租约(leases)，其实就是一个合同，即服务端给予客户端在一定期限内可以控制修改操作的权力。如果服务端要修改数据，首先要征求拥有这块数据的租约的客户端的同意，之后才可以修改。客户端从服务端读取数据时往往就同时获取租约，在租约期限内，如果没有收到服务端的修改请求，就可以保证当前缓存中的内容就是最新的。如果在租约期限内收到了修改数据的请求并且同意了，就需要清空缓存。在租约过期以后，客户端如果还要从缓存读取数据，就必须重新获取租约，我们称这个操作为“续约”{!引用自<<租约机制简介>>}。租约是一个很形象的叫法。虽然最初租约是被用于解决分布式文件缓存的一致性，随着时间的推移，该机制逐步被应用于更多的场景下，比如在GFS，Chubby中都可以看到它的应用，当然这也是翻译本文的重要原因，为深入理解GFS，chubby，租约是一个基础。关于整个租约机制的更多介绍及扩展可以通过译考文献1租约机制简介得到更多信息。本文只是提出租约机制的最初的那篇论文的内容。
from：http://www.cnblogs.com/chio/archive/2007/10/20/931043.html
题目如下：问下列代码的打印结果为0吗？
#include <stdlib.h>
#include <iostream>
using namespace std;
struct CLS
{
int m_i;
CLS( int i ) : m_i(i){}
CLS()
{
CLS(0);
}
};
int main()
{
CLS obj;
cout << obj.m_i << endl;
system("PAUSE");
return 0;
}
打印结果是不定的，不一定为0
代码奇怪的地方在于构造函数中调用了自己的另一个构造函数
我们知道，当定义一个对象时，会按顺序做2件事情：
1）分配好内存（非静态数据成员是未初始化的）
2）调用构造函数（构造函数的本意就是初始化非静态数据成员）
显然上面代码中，CLS obj；这里已经为obj分配了内存，然后调用默认构造函数，但是默认构造函数还未执行完，却调用了另一个构造函数，这样相当于产生了一个匿名的临时CLS对象，它调用CLS(int)构造函数，将这个匿名临时对象自己的数据成员m_i初始化为0；但是obj的数据成员并没有得到初始化。于是obj的m_i是未初始化的，因此其值也是不确定的
从这里，我们归纳如下：
1）在c++里，由于构造函数允许有默认参数，使得这种构造函数调用构造函数来重用代码的需求大为减少
2）如果仅仅为了一个构造函数重用另一个构造函数的代码，那么完全可以把构造函数中的公共部分抽取出来定义一个成员函数(推荐为private),然后在每个需要这个代码的构造函数中调用该函数即可
3）偶尔我们还是希望在类的构造函数里调用另一个构造函数，可以按下面方式做：
在构造函数里调用另一个构造函数的关键是让第二个构造函数在第一次分配好的内存上执行，而不是分配新的内存，这个可以用标准库的placement new做到：
1、Load Balancer
该模式中，一个分发器基于某种策略确定由哪个worker实例处理请求。应用最好是无状态的，以使任何一个worker实例都能同等处理请求。大量的网站都会用到负载均衡器这个模式的。
from：http://www.infoq.com/cn/articles/scalability-principles
作者 Simon Brown 译者 王丽娟 发布于 2008年7月25日 下午8时25分
从最简单的水平来看，可伸缩性就是做更多的事情。更多的事情可以是响应更多的用户请求，执行更多的工作，或处理更多的数据。设计软件这件事本身是复杂的，而让软件做更多的工作也有其特有的问题。这篇文章针对构建可伸缩软件系统提出了一些原则和方针。
看多了正面文章，今天看一篇负面批评吧，在MapReduce几乎已经成为大中型NoSQL产品标配的今天，如果有人说MapReduce完全是个垃圾，估计有很多人要受不了了。下面的一篇文章是一些RDBMS系统的大牛人从多个方面对MapReduce的批评，不妨一看。
zz from：http://pt.alibaba-inc.com/wp/dev_related_728/brewers-cap-theorem.html
英文版：http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
Amazon和EBay一直在喝的酷爱(kool aid)饮料。
by Julian Browne on 2009.1.11 （经Julian授权翻译此文，原文参见）
1976年6月4号，周5，在远离音乐会大厅的一个楼上的房间内，在位于Manchester的Lesser Free Trade Hall，Sex Pistols乐队（注：Sex Pistols的经理人Malcolm McLaren 2010.4.8去世）开始了他们的第一次演出（gig，注：规模太小称不上演唱会）。关于当晚谁出席了那场演出有些混乱，部分是因为6周后的另一场音乐会，但最主要的还是因为，这场演出被认为是永久改变西方音乐文化的一场演出。这场演出是如此的重要且富有象征意义，以至于David Nolan写了一本书：《我发誓我在那里：那场改变了世界的演出》，对那些声称自己看过那场演出的人做出判断。因为6月4号被认为是punk摇滚的开始。
Werner Vogels on December 23, 2008
http://www.allthingsdistributed.com/2008/12/eventually_consistent.html
这篇文章是Werner Vogel在2008年发布在ACM Queue上的一篇数据库方面的重要文章，阐述了NoSQL数据库的理论基石－－最终一致性，对传统的关系型数据库（ACID，Transaction）做了较好的补充。国内已有很多相关方面的介绍，比如InfoQ在2009年的介绍，但基本没有完整翻译的版本。在这里做一个完整的翻译，供初学者参考。
zz from：http://www.oschina.net/news/15813/hadoop-mapreduce?from=rss
最近雅虎开发者博客发了一篇介绍Hadoop重构计划的文章。因为他们发现当集群的规模达到4000台机器的时候，Hadoop遭遇到扩展性的瓶颈，目前他们正准备开始对Hadoop进行重构。
作者：LESLIE LAMPORT 2001 译者：phylips@bmy 2011-4-30
出处：http://duanple.blog.163.com/blog/static/709717672011440267333/
[
序：在PODC2001会议上，我总是听到人们在抱怨paxos算法是那么的难以理解。人们总是被那些古希腊的名称弄得晕头转向，而使得他们觉得论文难以理解，实际上算法本身是很简单的。于是在会议期间我就找了几个人聚在一起，试着直接向他们口头解释该算法。回家之后，我将这些内容整理了下来，后来又基于Fred Schneider 和 Butler Lampson的建议做了修改。就形成了现在的这个版本，虽然已经有13页长了，但是其中仍未包含任何一个比n1>n2更复杂的公式。{!本部分摘自Lamport的my writings，my writings是Lamport本人对自己以往发表的论文的一些总结，其中很多文字涉及到这些论文的创作来源。可以看出该论文的产生经历，与拜占庭将军问题有着截然相反的历程，在发表The Byzantine General Problem的时候，作者是用拜占庭将军这一场景引入到原来的算法中，而Paxos则是作者最初就是用古希腊的故事情节来描述，我想当时作者之所以采用一个故事性的背景，也是因为拜占庭将军这一写作方法带来的成功而受到的影响。只是事与愿违，人们觉得那篇The Part-Time Parliament太难理解了，而且通篇没有数学化的公式证明。根据Lamport的说法，当时的三个审稿人认为这篇文章虽然重要性不够但还有点意思，只是还应该把所有有关Paxos(Lamport在论文中虚构出的一个岛屿的名称)这一描述的地方全部删掉，但是Lamport觉得这些人太没幽默感了，也就没有按照他们要求的去做。以至于作者虽然在1990年就将它提交给了TOCS，但直到1998年才被发表。但是发表之后，很多人还是觉得原来那篇太难理解了，于是才产生了这一篇。不过现在回头再看，虽然当时Lamport的写作方式令文章被埋没了数年，但是也正因此才产生了如此有趣的一则轶闻，Paxos也成为该算法无可争议的名称，虽然另一篇文章<<Viewstamped Replication: A New Primary Copy Method to Support Highly-Available Distributed Systems>>在1988年就独立地提出了类paxos的一致性算法。}
作者：phylips@bmy 时间：2011-3-27
出处：http://duanple.blog.163.com/blog/static/70971767201133011171419/
作为这个星球上最大的互联网公司，毫无疑问google正在引领着海量数据处理实践的潮流。虽然Google经常发表一些对于自己来说已经过时甚至不再使用的技术的论文，但是发表之后总会有类似的系统被业界实现出来，也足以说明google的技术至少领先业界数年。