风轻扬

对云计算市场的几点预测

风轻扬 — Tue, 10 Apr 2012 19:02:53 +0800

几天前Citrix手上的CloudStack加入了Apache开源阵营，云计算的市场变得更加热闹。由于CloudStack比OpenStack更成熟，之后OpenStack与CloudStack可能此消彼涨，竞争态势可能慢慢发生变化。不过现在来预测OpenStack与CloudStack谁会最终胜出为时尚早，并且单独讨论这两者没什么意义，需要放到云计算整个市场的大环境去看。这时大家关心的主要问题是以OpenStack和CloudStack为代表的开源云计算解决方案是否会对AWS造成很大的冲击，这也是近期我考虑比较多的问题。

首先，我认为OpenStack等类系统的定位将始终是只做基础IaaS平台，而AWS早已包含了大量更高层次的服务，如RDS、DynamoDB、DevPay/FPS、Beanstalk，之后还会拓展更多更多，因此两者有别。OpenStack等类系统的主要产出可分为以下三类：

1、各类资源的虚拟化，包括：虚拟主机（包括镜像管理）、虚拟存储、虚拟网络（包括网络安全、负载均衡等）

2、公共服务与框架，包括：统一认证登录、Dashboard框架、计费框架、权限模型、监控框架、通知服务、日志与审核框架、组合服务（如AWS的CloudFormation和CloudStack的Template）等

3、硬件方面，包括：硬件参考架构、硬件支撑技术（如Intel Node Manager等）

这些公共基础平台功能都是OpenStack类系统目标所及，但超出这一范围，则基本不会涉及。这是因为各类上层服务如关系数据库、NoSQL、并行计算等等，都不能说具有同等的广泛性与通用性，委员会举手表决时很难获得大多数认可。综观任何开源系统，都有明确的目标和范围，大而杂的系统从未见过。

但是，虽然OpenStack类系统本身并不会变得像AWS那样包罗万象，开源系统之间相互协作，有望形成一个围绕OpenStack类系统为中心的Ecosystem。这一Ecosystem，从功能而言，很可能可以与AWS相匹敌。我们已经见识了Hadoop Ecosystem，同样的场景有可能在云计算领域发生。这一过程，应为中速。一方面，开源Ecosystem的形成历来不会很快，LAMP用了很多年，Hadoop是一个更小的Ecosystem，在得到Facebook这样的大佬扶持下，形成Ecosystem也用了3－4年，而围绕OpenStack是一个更大的Ecosystem。但另一方面，围绕OpenStack类系统的Ecosystem不需要像Hadoop Ecosystem那样有大量的新系统构建，主要是集成。比如RDS可以仅仅是对MySQL的简单包装，NoSQL可以包装包装HBase。具体要多久我想谁也说不准，以目前的态势，我估计过2年OpenStack类系统本身可以成熟，再过2年Ecosystem基本形成。

但是，是不是有了OpenStack这些软件，AWS就会没有生意？这个问题，一步一步来看。首先要明确公有云的定位。有了OpenStack Ecosystem，大型组织来部署自己的私有云会比较容易。虽然这些开源的玩意都不是很鲁棒，但开源的东西玩一段时间也可以production，近期Zynga的例子就能说明问题。大型组织本来就不应该是公有云的目标客户。但对中小型组织，情况则完全不同。并不是说一个系统，大企业都能用，小企业用起来更没问题。对大多数其它开源系统，都是这样，但云计算系统的特点决定了中小型组织单独部署私有云毫无经济效益。还有，这一套Ecosystem别人部署好了给你用很简单，自己去部署并不容易，最近玩OpenStack的同学应该都知道。但这是小case，云计算的规模经济才是命门。

因此，无论OpenStack Ecosystem多么成熟，中小组织自始自终将是AWS等公有云的客户。

那么，会不会将来无论谁拿个OpenStack Ecosystem，提供个公有云服务，就可以跟AWS匹敌呢？这里有两个关键，一是再次强调成本经济性，二是公有云与私有云的区别。成本经济性来自于软件与硬件两个方面。硬件方面，系统规模越大，系统整体表现越平稳，资源配比与调度越可优化，初始投入越被摊薄，人力成本越被摊薄。君不见AWS可以一再降价，而像Reserved Instance这样的特有成本优化技术总是降得最猛。而Reserved Instance很可能在规模不到一定程度都属于玩火自焚的东东。很难知道这个规模效应要多大规模才会终止，但基本上预计总是成千上万服务器。

硬件上的成本经济性决定了通用的公有云将是大玩家的市场。但大玩家也很多，是不是有钱的都可以玩？这就要看软件。硬件只是规模效益的一方面，很多时候软件对降成本的更有效，其中最主要的是多租户共享。之前说了，公有云是服务大量中小客户，他们对各类系统的需求都有，但量都只有一点点。分配个虚拟机，装上软件提供服务，当然可行，但对小客户而言成本实在太高。面向极大量小客户服务时，要进一步降低成本，就要实现优秀的多租户、资源共享与隔离等技术。而完善的多租户类技术，我认为不会在开源的OpenStack Ecosystem中出现，理由有：

1、多租户类技术不是一锤子买卖，而是需要对每个服务都要去实现。MySQL需要做MySQL的多租户，Memcached需要做Memcached的多租户，工作很杂；

2、乐于将代码贡献给开源界的各方对多租户等没什么需求。像Dell、HP、华为这样主要给大企业作私有云的企业乐于将代码贡献在开源界，但大企业的私有云对多租户等的需求弱得多，因为私有云不会有极大量的小客户。

3、基于OpenStack Ecosystem做公有云，面向大量小客户服务的企业自然会研究多租户类技术，但这是他们的命根子，绝对不会把代码开源。

因此，每个想做公有云的玩家，即便将来可以借力于完善的OpenStack Ecosystem，仍然需要在软件研发方面投入比较大的人力。综合以上两点，公有云将是少量有经济实力也有技术实力的大玩家的市场，两者缺一不可。那些认为有了OpenStack就可以做公有云的完全是幻想，当然，由于某些特殊的客户关系，或针对某些特定行业，小规模的做是可以的，也可以挣到钱。

总结一下:

1、OpenStack或CloudStack本身将始终是只做基础IaaS平台；

2、围绕OpenStack类系统有可能形成一个开源的Ecosystem，功能上与AWS类似，但需要比较长的时间；

3、公有云的目标市场是大量的中小组织；

4、开源的Ecosystem中不会诞生公有云非常关键的多租户和资源共享等技术；

5、公有云主要是少量有经济实力也有技术实力的大玩家的市场。

Amazon DynamoDB详解

风轻扬 — Thu, 19 Jan 2012 13:17:40 +0800

今早Amazon发布了DynamoDB，作为AWS服务的新成员，提升了AWS管理结构化数据的能力。总体来说，DynamoDB是基于Amazon Dynamo技术实现的可伸缩性和可用性优异的NoSQL数据库托管服务。

我们知道，Amazon搞了一个很牛的KV数据库Dynamo，可伸缩性、可用性和性能稳定性非常好。但Dynamo推出后并没有在Amazon内部被广泛接纳，主要原因是Dynamo是作为软件系统提供给开发者，要用得部署各自的Dynamo集群，安装管理成本很高。后来Amazon推出了SimpleDB托管服务（Managed Service），没有部署和管理开销，很受欢迎。用户也很欢迎SimpleDB灵活的数据模型。

但是SimpleDB也存在几个主要问题：

1、可伸缩性有限。因为批量操作只有Domain数据在一个节点上才能有效完成，导致单个Domain最大只能支持到10G；

2、性能不可预期。SimpleDB为了方便使用，所有属性都建索引，都可以搜索，这导致更新性能不可控，如果属性一多或数据量一大更新就很慢；

3、最终一致性难以使用。一开始SimpleDB只提供最终一致性读，开发者觉得开发应用时很麻烦，几年后SimpleDB才提供了一致性读选项；

4、Machine Hours计费很难用；

根据这些经验，Amazon重新设计了DynamoDB。采纳了SimpleDB中成功的托管服务形式及灵活的数据模型，并从一开始提供了一致性读功能。限制了系统的功能，只能通过主键去操作记录，不能进行批量更新，这使得系统可以保证可伸缩性及任何时候的高性能。另外，全面的使用SSD来提升系统性能。

下面来详细说说DynamoDB的各项特性。

一、数据模型

DynamoDB的数据模型可以说是SimpleDB/BigTable与Oracle NoSQL的融合。系统首先分成多张表（Table）。表中的记录拥有单属性简单哈希主键或两属性Hash Key+Range Key组合主键。记录内容可包含任意多个属性，属性分单值或多值两种。属性值可以是字符串或数值类型。表没有统一的模式，建表时只需要指定主键的定义，其余各记录都可以拥有自己不同的属性集合。记录由主键和多个属性组成这一点类似于SimpleDB与BigTable，这比简单的KV模型更易用。主键可以由Hash Key+Range Key组合而成则类似于Oracle NoSQL，这主要为了提供相同Hash Key的记录集合操作。

二、操作

DynamoDB提供如下操作：

1、putItem：插入或更新一条记录，支持条件更新，支持在更新时返回属性旧值

2、getItem：获取一条完整的记录或某些属性，允许指定用最终一致性读还是严格一致性读

3、batchGetItem：获取一个或多个表中的多条记录或某些属性，只能用最终一致性读。一次最多返回100个属性及小于1MB数据，如果没有返回所有记录，会返回还没有处理的键值以便应用再次去获取

4、updateItem：插入/删除/更新一条记录中的某些属性，支持条件更新，支持更新时返回所有属性旧/新值、被更新属性旧/新值

5、deleteItem：删除一条记录，支持条件删除，支持删除时返回被删除记录

6、query：使用组合主键时查询同一Hash Key的多条记录或某些属性，可指定Range Key范围条件及读一致性要求，可指定返回条数限制。操作保证按主键顺序返回记录，因此可通过在下一条查询时指定上次返回的最大主键作为起始点来实现分页

7、scan：表扫描，可指定多个过滤条件，可指定返回条数限制。实现分页的方法同query

可以看到DynamoDB不但提供了单记录的CRUD操作，还提供了条件更新、多记录读、范围扫描、全表扫描等功能，还算比较灵活。

此外，还可以用MapReduce来分析DynamoDB中的数据。特别的，因为DynamoDB已经是表结构，可以很方便的用Hive来分析。

三、其它

DynamoDB的数据至少都会同步复制到在同一Region的3个以上的数据中心，因此可用性和数据可靠性非常好。

DynamoDB的计费模式中最显著的特点是按读写操作的能力收费，用户要指定每张表第秒能提供多少次读写操作。费用价格为0.01$/小时.10 Write Capacity+0.01$/小时.50 Read Capacity，最终一致性读操作半价。另外存储费用为存储1$/GB.月，操作超过1KB的对象还要另收费。可以看到DynamoDB的存储费用是S3的7－18倍，估计是因为用了SSD带来的成本提高。

四、读后感

数据库，最简单的莫过KV，最复杂多能的莫过传统关系数据库。现在一般认为KV太过简单，关系数据库太过复杂，怎么才是最好的中庸之道，是大家都在探索的问题。时至今日，各项技术都明了，难做的是怎么取舍。DynamoDB是Amazon基于多年经验给出的答案，其特点是类似于关系表但Schemaless的灵活数据模型、组合主键、条件更新、可选的一致性读、受限的范围扫描、全表扫描等，没有多记录原子操作。以Amazon的经验，这些取舍当然值得重视。但并非唯一，如在数据库领域更富有经验的Oracle做的NoSQL数据库则包含多记录原子操作功能。

Hadoop++：Hadoop的局部性能改良

风轻扬 — Fri, 16 Dec 2011 16:48:35 +0800

Hadoop++是对Hadoop Map Reduce的非入侵式优化，通过自定义Hadoop框架中的split等函数来提升，提升查询和联接性能。项目由德国Saarland大学Jens Dittrich教授主持。项目主页是 http://infosys.uni-saarland.de/hadoop++.php。

Hadoop++对Hadoop的优化主要是Trojan Index、Trojan Join和Trojan Layout三方面。

1、Trojan Index

Trojan index的核心是将数据组织成依次由数据、索引、Header和Footer这四部分构成的split，其中Footer是split的分界符，最后一个Footer一定位于文件末尾。索引构建时由MapReduce完成排序。查询时split函数从文件末尾开始根据Footer信息解析出各个split，itemize函数根据搜索范围条件快速定位满足条件的内容。

以数据库技术类比，Trojan Index类似于索引组织表。

2、Trojan Join

Trojan Join根据联接属性将来自多表的相关记录分到一个split，组织成类似于Trojan Index的结构，itemize出来的记录同时包含了参与联接的双方的属性，这样不再需要在查询时再根据联接属性用map/shuffle/reduce来计算联接。

以数据库技术类比，Trojan Join类似于多表聚簇。

3、Trojan Layout

类似于PAX，为block内部的数据组织方法，将查询中经常一起访问的属性组合在一起。不同复本用不同的Layout。根据负载计算最优的Layout，类似于背包算法。

以数据库技术类似，Trojan Layout类似于垂直分区，亮点是不同复本用不同的垂直分区。

Hadoop执行过程

风轻扬 — Thu, 15 Dec 2011 16:31:56 +0800

根据Hadoop++论文的描述，Hadoop执行过程分为Load、Map、Shuffle、Reduce这四个阶段，可以看成是一个由split、itemize、map、reduce等10个函数或算子组成的DAG。其中每一个函数或算子，都可以提供自定义的实现以此来扩展Hadoop的功能或优化性能。

1、Load阶段

输入数据经block函数，按配置的block大小切分成多个block，每个block按配置存储多个复本，Hadoop尽可能保证不同复本存储在不同结点上。

2、Map阶段

每个mapper子任务读取一个split。每个split包含一个或多个block，是一个逻辑单元。split函数决定怎么划分split。split通过itemize函数分割成记录，框架对每条记录调用map函数。map的输出由mem函数切割成多个spill。spill中的每条记录由sh函数决定输出到哪个reducer，为每个reducer产生一个逻辑分区。每个逻辑分区根据cmp函数排序并根据grp函数分组，再根据combine函数进行预reduce处理后存储到文件。如果一台mapper机上对某个reducer产生了多个上述处理所得的spill文件，则进行合并，合并时同样执行排序、分组和combine流程。

3、Shuffle阶段

每个mapper产生的spill文件再次经过sh函数分派给每个reducer。每个reducer从每个mapper接收给它的数据，如果能在内存中合并就在内存中合并，否则接收后先存储，等全部完成后再来合并。最终为每个reducer准备好一个待处理的文件。

4、Reduce阶段

每个reducer的输入文件先同样执行排序、分组和combine流程，然后根据reduce函数得到最终结果。

下面的图显示了一个有4个节点，4个mapper，2个reducer的Map Reduce程序的执行过程。

Amaon AWS's EBS

风轻扬 — Thu, 20 Oct 2011 20:37:05 +0800

EBS是Elastic Block Service的简称，简单的说是可以像普通硬盘一样挂载用的裸块设备。容量1G到1T，属于一个Availability Zone的EBS只能被挂载到同一AZ的EC2主机。一个EBS设备在同一时候只能接到一台EC2实例。

EBS在同一AZ内部复制，但不像S3那样跨AZ复制。因此EBS的可靠性高于单盘，但不是绝对可靠。具体的可靠性取决于容量和最后一次snapshot之后修改的数据量。据官方数据，最后一次snapshot之后修改的数据量小于20G时，年故障率为0.1% – 0.5%。

可以创建存储于S3的快照。这些快照不能通过普通的S3 API操作，只能用于恢复EBS卷。快照是块级增量的。快照不保证一致，如果想获得一致快照，请先停止对EBS的所有写操作。

== 关于EBS的实现机制和性能
据很多用户报告EBS的性能一般也不太稳定。据估计EBS没有用NetApp、EMC等高端存储，而是基于经济型服务器的软件RAIN(Redundant Array of Inexpensive Nodes)的方式来构建。 [1] EBS是通过EC2实例的一般为1G带宽的以太网接入。据第三方测试，EBS的性能不太稳定，最好的时候IOPS可以高至70~80K，每秒7K次seek，但差的时候IOPS可能只有200。[2]创建快照的速度一般在20MB/s左右。[3]

== 参考资料
1、http://perfcap.blogspot.com/2011/03/understanding-and-using-amazon-ebs.html
2、http://orion.heroku.com/past/2009/7/29/io_performance_on_ebs/
3、http://blog.rightscale.com/2008/08/20/amazon-ebs-explained/

Amazon AWS云计算服务简介

风轻扬 — Wed, 19 Oct 2011 14:54:16 +0800

若以2006年3月13日Amazon发布S3服务开始计算，AWS已经有5年半了。经过这么多年的工程与应用，现在AWS的基础设施功能已经相当丰富，能满足构建超大互联网应用的大多数需求，提供的开发工具、文档、社区和支持也还不错。AWS的服务简述如下：

一、基础设施服务
AWS共提供14类28项服务，大致可分为计算、存储、应用架构、特定应用、管理这五大类：
1、计算类服务

EC2：虚拟机实例，有标准型、大内存、高运算能力、带10G网络的HPC、GPU等多种类型、Win/Linux OS、主流WEB、应用服务器、数据库。可自动按需伸缩。本机没有持久化的存储

Elastic MapReduce：MapReduce型分析，基于Hadoop，支持Hive/Pig。能处理EC2和S3中的数据

2、存储类服务

S3：海量文件存储。分高可靠和低可靠两类。
SimpleDB：高可伸缩的简单结构化数据存储，支持极大数据量。强一致和最终一致可选。条件更新
RDS：打包好的MySQL服务，做好备份和软件维护
EBS：可低EC2实例使用的块设备
ElastiCache：Memcached缓存服务。分布式自行管理。
Import/Export：在AWS和存储设备（如盘阵）间导入导出数据
SQS：高可靠的消息队列服务，消息可保存14天。

3、应用架构类服务

Cloud Front：CDN服务，支持静态文件和流媒体。全球20个点
SNS：基于topic的消息订阅与推送服务，支持HTTP/EMail
SES：发邮件服务
Elastic Load Balancing：将请求负载均衡到EC2实例
VPC：虚拟私有云。网络/子网/IP/路由表等可配置
Route 53：DNS服务

4、特定应用类服务

FPS/DevPay：计费服务（不是AWS计费，是指应用借助于这个来向用户计费）
GovCloud：面向政府应用，提供更好的安全性

5、管理类服务

CloudWatch：功能丰富的性能监控服务

二、开发者服务
AWS面向开发者提供的工具包、SDK、文档、社区和技术支持等服务也是比较多的，相对于Google App Engine和微软Azure来说感觉要丰富不少。主要有：

Java、PHP、Python、Ruby、Android/iOS、Windows .Net共7大平台功能丰富的SDK
Eclipse和Visual Studio插件，包含应用模板、应用部署与调试等功能
比较齐备的开发文档、Tutorial、教学视频，丰富的Sample Code
比较活跃的开发者论坛（每天100帖左右，比GAE的论坛要活跃一些）
按月付费的一对一技术支持服务

三、数据中心分布
目前AWS在全球共有6个Region，美国有3个，还有3个分别在爱尔兰、新加坡和东京。每个Region可能有不只一个Availability Zone。但并不是每个Region都支持所有服务，像S3这样的老又畅销的服务似乎所有Region都支持，但SimpleDB就不是每个Region都支持。CloudFront CDN在全球有20个点，其中最近新增的一个是在拉美。

四、市场及应用情况
2010年营收据估计约5亿美元（不是官方数据，因为规模还是相对太小上不了财报，只是估计），据分析师预计2012年营收将达10亿美元。第二季度末S3管理的文件数达到4490亿。AWS客户多数是互联网应用。

著名的应用案例有：
1、Zynga：底层完全由AWS支持
2、Dropbox：用S3存文件数据
3、Foursquare：用S3和Elastic MapReduce作日志分析
4、其它： NASA(美国航空航天局)、美国国务院、西门子、辉瑞、纳斯达克股票交易所

看起来经过5年的慢慢培育，AWS的市场逐步放量了。其中主要的应该是S3和EC2的用户，像Dropbox这样的大用户可能就几百亿个文件。

Amazon SimpleDB

风轻扬 — Wed, 19 Oct 2011 14:32:13 +0800

4年前SimpleDB刚推出的时候我写了一篇日志《一条腿的Amazon SimpleDB路难行》，是说SimpleDB当时还不支持排序，功能严重残缺。现在SimpleDB早已支持排序了，而且从那之后也加了很多功能。这几天在看AWS，顺便把SimpleDB再记录一下。

一、数据模型
数据分为多个domain，domain包含多个item，每个item包含多个属性/值对，值可以是一个集合，每个单值都是字符串类型。domain类似于表，item类似于行。无固定模式。没有Version的概念。

不需要显式建索引，自动索引。据推测相当于每个属性上都建了索引，无法实现多属性联合索引：猜测where a = xxx and b = xxx的执行过程是做列表的intersect。

二、操作
操作分以下几类：
1、创建/删除/枚举domain
2、PutAttributes/BatchPutAttributes/DeleteAttributes/BatchDeleteAttributes/GetAttributes。支持有条件的UPDATE/DELETE，实现CAS语义。通过NextToken可以一小批一小批的遍历大量数据，类似于翻页。
3、SELECT：类似于数据库单表SELECT，聚集函数只支持count(*)。WHERE条件可以有：简单比较，AND，OR，NOT，intersection，is null/is not null。支持排序，排序的属性必需指定的搜索条件，不能是NOT条件或UNION，由此猜测排序是只能是利用索引实现自然有序。

操作只针对一个domain，不能跨domain。

三、一致性
支持一致读和最终一致性两档一致性保证。

四、限制
属性值最大1024字节，domain最大10G，最多包含2.5亿属性/值对，查询用时不超过5秒，查询返回数据不超过2500个item，最大结果集大小1MB。

Oracle NoSQL Database

风轻扬 — Wed, 19 Oct 2011 11:57:55 +0800

近日Oracle提供了不久前公布的NoSQL数据库的下载，目前只有企业版，开源的社区版还没提供，也就是说还看不到源码。不过根据文档也能大致了解这个NoSQL数据库怎么样。快速看了看，总结如下。

一、数据模型
key包含一到多个major key component和零到多个minor key component，组合起来唯一标准一条记录。key component为Java String，按对应encoding排序。value则是字节流。key和value的大小都没有严格限制。

记录还有版本号，每次更新都产生唯一的新版本号。在put/delete/get操作时，都可以指定要版本号，其中get时用于指定要读的版本，而put/delete指定版本号是指当记录的最新版本还是指定版本时才更新，用于实现原子Compare-and-Swap语义。版本号应该至少是在一个partition内部是全局唯一的。

二、分区与架构
两层架构，客户端直接到存储节点。核心架构是Replication Node和Replication Group，一个Replication Group包含一个可写的Master Replication Node和多个只读的replica。master失败时会failover到某replica。现在发布的版本暂时还不能动态调整存储节点个数，以后会加。

数据按major key hash分区到partition。这样拥有相同的major key仅仅minor key不同的多条记录一定在同一partition，可以提供高效的多记录操作，且系统还支持原子性的操作这样的多条记录。一个Replication Group一般负责多个partition，一个存储节点一般负责一个Replication Node，如果调整存储节点个数，则以partition为单位来移动数据。为方便以后scale-out，应该一开始就多一些partition。

系统底层用的是Berkeley DB Java Edition，用Btree数据结构。缓存包含Berkeley DB的缓存和文件系统缓存，不用DIRECT_IO，文档建议Berkeley DB缓存用于容纳Btree的内部节点，叶节点用文件系统缓存。另外也提供单机版称为KVLite。

三、操作
Oracle NoSQL提供的操作比较丰富，主要包括：
1、用于插入或更新记录的put类操作，包括put/putIfAbsent/putIfPresent/putIfVersion，都要指定一个完整的Key。用途顾名思义就不说了，稍提一点是putIfVersion功能提供了Compare-and-Swap，在处理并发时很有用
2、用于删除记录的delete类操作，包括delete/deleteIfVersion/multiDelete。前两者要指定完整Key，用途顾名思义。说一下multiDelete，这个操作最多可以指定三个参数，一是必须指定完整的major key，二是可以指定一个由第一个minor key的上下限构成的KeyRange，三是可以指定是删除子节点/子孙节点/父节点和子节点/父节点和子孙节点等多种Depth模式。
3、用于读取记录的get类操作，包括get/multiGet/multiGetIterator/storeIterator。multiGet和multiDelete一样可以指定KeyRange和Depth。multiGetIterator用于批量取一个完整major key下的大量记录，防止占内存过多，可以指定遍历方向，不保证数据是某时刻的一致视图。storeIterator用于遍历不完整major key下的大量记录，甚至遍历所有记录。
4、用于批量原子更新多条记录的execute操作。系统保证这批操作的原子性，限制是操作的记录必须都拥有相同的major key，且同一条记录不能操作多次。

四、数据一致性
Oracle NoSQL的数据一致性比较灵活精细。就读取而言，可以指定只从master读、不管replica是否落后都可以从replica读、只在replica落后master时间在某阈值之内时才能从replica读、只在replica的版本号不小于某指定版本号时才读。指定版本号的读一致性可以用于实现read-your-own-write形式的一致性，即保证自己能读到自己刚写的数据。

就更新而言，可以指定两方面的策略。一是master要不要等各个replica的应答，这里可以选要所有replica应答、要大多数replica应答和不等replica应答等3种。二是数据要不要持久化到磁盘，这里可以选不要（更新到内存就可以了）、写磁盘但不SYNC、写磁盘且要SYNC等3种。持久化策略可以指定master和replica分别指定。根据文档看似乎没有用到2PC。

五、系统管理及其它
系统提供命令行或WEB界面的管理工具，管理比较方便。可以创建snapshot，snapshot只在partition内部一致，不保证全局一致。可以从snapshot恢复。提供将NoSQL Database数据导入到Hadoop功能。客户端驱动是jar包。

六、小结与评价
可以看到Oracle NoSQL毕竟是大厂出品，比普通的Key-Value存储要强大许多，突出的主要有三点。

一、数据模型和操作强大。通过由多个key component来构成key并且设计操作时加以支持，Oracle NoSQL实际上不再是纯平面的Key-Value模型，而经常呈现为一种树形模型。多一个key component后缀的记录可以看作是子节点。系统提供了许多批量操作一个子树的功能，对比关系模式可以看出这解决了一部分JOIN问题，提高了开发效率。
二、数据一致性灵活精细。读取和更新都提供了很多一致性选项，可以实现不同的性能和一致性折衷。此外通过版本号，可以支持Compare-and-Swap、Read-your-own-write等语义，为实现并发正确性提供了便利。
三、支持多记录原子性操作。

当前版本最主要的问题是不能加存储节点，不过相信这个问题不久后会被解决。

Clustrix Sierra关系数据库集群

风轻扬 — Mon, 29 Aug 2011 17:58:30 +0800

Clustrix的Sierra数据库集群引擎是一个share-nothing架构的可伸缩关系数据库集群。官方宣传的非常诱人，说是功能像集中式关系数据库一样强大，可伸缩性超强，不需要规划什么数据分区，可用性也非常高。简直是集SQL和NoSQL的优点于一身。据说最近阿里云的RDS服务很可能是基于这个，因此仔细去了解了一下，发现架构上属于软硬一体化的路子，感觉架构上还是有些问题，对硬件的要求也不低。

Sierra前端采用MySQL协议，但本身跟MySQL没有任何关系。系统是一层架构，每个节点既负责处理逻辑，又负责数据存储，没有做处理和存储分层。

表数据根据某些可指定的属性或属性组合Hash/Range分区划分为slice。slice有多个复本保证可靠性。没有专门的主复本机或从复本机，每个节点都可以存储任意复本。slice的数目与表大小有关，太大时分裂，也可以由用户来设slice的数量。slice可以在集群中在线移来移去，新节点上线时分配一些slice给它。每个slice有个主复本，只有主复本处理读操作并有缓存，写操作要更新所有复本。索引是一张内部的独立的表，即全局索引，根据索引键值分区。没有局部索引。全局索引的优点是方便支持唯一性和外键。

每个节点上都有分区信息，查询提交到任意一个节点，Database Personality Module负责将查询分解路由到多个节点并发执行。简单操作直接定位一个节点处理就行了，可伸缩性应该非常不错。复杂查询尽可能的将操作下推给数据所在节点，减少节点间交互。

并发控制使用MVCC，保证事务ACID。读操作不加锁，不会被阻塞。并发控制只在本地做，不需要全局锁，当然更新时要用原子提交。比较麻烦的问题是更新的性能问题。所有更新都是分布式的，至少要更新多个复本，还要更新多个（全局）索引，每个索引都有多个复本，这个问题听上去很夸张。Clustrix为了搞定这个问题，使用了优化的Paxos协议，但更重要的是节点之间要用两路20Gb的Infiniband来互联，还得用带电支持的NVRAM，这样才能保证更新的吞吐率和提交时的响应时间。

Clustrix不提供单独的软件，要用还得用它们的专有数据库服务器，网络设备也得配套。目前有4100和4110两种服务器，都是1U，4核CPU，内存为24/48G，7块80/160G SSD（存数据），1块500G SATA（估计是系统盘），两路20Gb Infiniband（节点间互联及数据迁移专用），4块千兆网卡，1G NVRAM。NVRAM不知道是带电支持的DRAM还是PCM。

看完了架构，我觉得这东西还是有一些缺点。首先从配置可以看出来这玩意挺贵的，存储全用SSD，还要NVRAM和Infiniband。其次没有多表共享的分区策略，这使得联接操作基本上都要分布式处理。第三没有局部索引，使得全局索引的更新对硬件性能的要求非常高。设计中的有些选择总觉得值得怀疑，比如既然非主复本是不可读的，为什么要用原子提交保证一致性，应该异步去更新就行了。

用了这么好的硬件，它的吞吐率估计还不错，但现实中有大量应用是因为数据量太大而需要分布式扩展，并不要求极高的吞吐率，这样用Sierra性价比就划不来。Clustrix是去年5月推出这个产品，现在应用情况好像很一般，估计也是由于这些原因。

最终小结一下：
1、兼容MySQL协议，支持关系数据库几乎没有功能，包括索引唯一性和外键。
2、share-nothing
3、动态可伸缩，高可用
4、单层架构，节点即负责处理也负责存储
5、根据指定属性或属性组合的Hash/Range分区
6、全局索引
7、更新所有复本，只读主复本
8、高端硬件，SSD、NVRAM、Infiniband

NTSE最近的进展及随想

风轻扬 — Wed, 10 Aug 2011 18:20:54 +0800

一、NTSE 0.7发布
几天前NTSE 0.7发布了，核心功能有基于字典的记录压缩和在线建索引两个。在线建索引功能能够在不影响事务并发读写时建索引，并且是由基于排序的高性能索引创建算法，对提高数据库的可用性很有帮助。在线建索引比较简单，重点要说的是基于字典的记录压缩。首先来看模拟博客日志模块的blogbench测试结果。

上图是NTSE 0.7和NTSE 0.5及InnoDB的性能对比，纵坐标是TPS，横坐标是内存占数据量的比例。可以看出NTSE 0.7比0.5在小内存配置下又有了近一倍的性能提升。与InnoDB相比小内存时的吞吐率达到15倍以上。第二个数据是压缩后记录占用的存储空间也节约了将近一半。这样，对部分应用无论从任何角度考虑，用NTSE 0.7都可以比用NTSE 0.5时节约一半硬件资源。相比InnoDB，大约可以只用1/4的硬件。这一结果可谓非常理想。看来记录压缩对提升WEB应用的数据库性能还是很有帮助的。

NTSE的记录压缩基于表全局字典来做，不同记录和页面中的记录都共享一个字典，多个属性可以组合压缩成一个单词，一个属性内部也可能被切分成多个单词来压缩，压缩率远高于InnoDB的页面级zip压缩（只能说InnoDB的页面级zip压缩太烂了）。在内存中也是压缩格式因此能够显著的优化缓存效率减少IO。压缩和解压以记录中的属性组为单位（默认记录中所有属性都是一个属性组），压缩和解压都非常快并且粒度非常细，因此启用压缩对性能的影响非常小，纯内存blogbench测试开不开压缩对吞吐率几乎没影响。

二、NTSE又添新应用
大部分反垃圾数据库，有10多个节点近1T数据已经用上了NTSE。在用NTSE之前用InnoDB，数据已经几T，每台机器上数据好几百G快到瓶颈了，一用NTSE一下子压缩到1/3至1/4，这样这些机器又可以撑很久了。对WEB应用来说，什么内存数据库就是胡扯。

三、其它
嗯，基于NTSE的事务支持日见明朗，感觉今年差不多能搞出来，之后NTSE就可以大行其道了。另外多属性组合查询的事，感觉也能通过NTSE很好的解决（而且顺便可以把与数据库集成的实时全文检索也搞定）。今年有盼头了。再好好规划，来年做基于NTSE的超级可伸缩、高容错的分布式解决方案。做好后，线上数据库和实时搜索、融合搜索的问题有望完美解决了。

基础系统软件的价值

风轻扬 — Thu, 21 Jul 2011 14:59:29 +0800

盛大推出云计算服务，看起来想做类似于Amazon AWS的IaaS。看了一下，结构化数据管理的功能很弱，只有最简单的Key-Value服务，只有GET/PUT/DEL，没有条件更新没有锁，没有扫描，这让我觉得很不靠谱。结构化数据管理是99.9%的应用都需要的，而基于盛大云这样简单Key-Value来开发应用是很麻烦的事。比如：
1、如果把多个实体属性拼起来，没法索引，效率也不高；如果分开，那经常得用很多个GET；
2、没有索引和扫描，各种数据列表都不容易，比如按时间/阅读次数/评论次数排序的文章列表，你要用一个KV来维护ID列表，这会涉及复杂逻辑（比如按阅读次数排序的列表就不好搞），而且还会数据不一致；
3、刚说到阅读次数，好把，基于盛大云要维护一个会被并发更新的准确的计数是不容易，很不容易，简单到文章阅读次数，评论次数，好友个数等等。因为没有条件更新和并发控制，你把值读出来，＋1再存回去，一并发就错了。

总之，这种最简单的Key-Value系统，我一直认为是对系统实现者来说是福音，但对系统使用者来说是绝对坑到祖宗的玩意。如果盛大云就只有这把刷子，没几个开发者愿意用。还好盛大云据说会推出MongoDB服务，这还算有点靠谱。

我越来越觉得这不是正确的做事方式。我觉得做基础系统软件，是希望能够让用户（也就是基于这些基础软件来做应用的人）能够很简单的做出正确、稳定并且高效的应用。很简单的做出应用是指开发效率高；系统不出错并且稳定，这几点是最重要的，高效是在满足前面这几点之后再追求的。系统常出错或不稳定，性能再高也没用，这点可能不用多说。但开发效率的重要性，是工作之后再深刻的体会到的。

做了5年系统，有一件事最失败。我们在DDB里支持了Master/Slave读写分离，希望对数据实时性要求不高的查询去访问slave。这样系统好伸缩，撑不住了加个slave就行了。唯一的缺点是slave上读不到实时的最新数据，可能晚个几秒。我们想几秒有啥关系呢，我写了篇博客，其他人过几秒钟才看到，这有毛关系？但这个功能作了两三年了，几乎没人用。开发者说，要用这个，代码得多很多判断逻辑，每个Dao都要加个参数标明能不能访问slave。这得增加多少开发成本，多出多少bug啊。进度这么紧张，系统正确性这么重要，你好意思再让他们用吗？后来我们被逼上绝路，硬是基于复制实现了系统的准在线扩容，这次大家都满意。这才是帕累托改进！

之前看Codd的图灵奖获奖感言，把关系数据库跟生产力扯到一起，觉得这哥们比较虚，上纲上线。Dijistra多实在，那么大成就，说是humble programer。这几年，看了不少真实的数据库应用，感觉Codd所言不虚。如果没有关系数据库，如果没有陈述式的SQL，没有ACID，开发应用不知道会复杂多少，系统bug不知道会多多少，开发人力成本不知道会增加多少。看基于RDBMS开发的应用，Service调Dao，Dao操作数据库基本上就一两条SQL，业务逻辑清晰无比。要是换成盛大云那样的简单Key-Value，复杂可想而见，基本类同Python和C的开发效率差别。

基础系统软件跟产品一样，首先要考虑的是用户的感受，而不是实现的难易或技术的先进。用户最需要的就是系统用起来爽，只要写几行业务逻辑代码，剩下的基础系统软件都帮他搞定。这样，开发效率才能上去，系统质量才能上去，在互联网领域竞争中才能领先。反之，即使基础系统软件稳定、可靠、性能高效，但用户在此基础之上没法直接写业务逻辑，得重复干系统层应该干的事，开发效率和系统质量都没法保证。像网易这样规模的公司，如果没有DDB、DFS，让开发者像用一个单机数据库和文件系统那样简单，那每个产品都要自己来分库、分表、分存储、搞索引，一大堆烦杂的事，花气力也一定搞不好。

搞系统的人喜欢做性能优化。性能优化了，自然是好的，但一定要明白系统的性能是个整体。如果为了让底层系统好实现，好优化，把底层系统的功能弱化，则底层系统的性能是高了，但却导致上层做了更多的系统性工作，反而导致系统整体来看更复杂，性能更差。这些工作，总是要做的。要么在底层系统做，由更专业的人做一次；要么在上层做，由不专业的人来做多次。哪种好一目了然，基础系统应该做多点。

所以一直对很多NoSQL系统、最终一致性不太感冒。虽然可伸缩性没问题了，但系统功能退步了，应用开发难了，这样的系统不会有主流市场。
NoSQL只有功能不断丰富到可与RDBMS相比、数据保证强一致性，我觉得才有戏。目前只有Google Megastore还凑合，开源的还都不行。选Key-Value/Entity不选关系模型和SQL、选最终一致性不选ACID，总感觉是做基础系统的人推脱责任。当然可以以此起步，千万不可以此为目标。那些吼吓ACID一定性能和可伸缩性不行的人，就相当于吼吓Java性能不行一定得用汇编，我觉得是主次不分。

分布式事务性能分析

风轻扬 — Wed, 13 Jul 2011 17:18:28 +0800

这两年来，随着NoSQL系统、CAP理论和Eventual Consistency的大热，关于分布式操作要保证强一致还是弱一致性的讨论络驿不绝。双方各执一词，倾向实现强一致性的一方认为弱一致性满足不了应用开发的需要，倾向实现弱一致性的一方则认为保证强一致性将导致系统性能与可伸缩性难以接受。弱一致性能否满足应用开发的需求这一点由应用特征决定，难以一概而论，但强一致性对系统性能、可伸缩性和可用性的影响则是可以作技术分析的。奇怪的是，找了很久，也没找到对这一问题的深入分析，决定自己来做一个。

对于分布式操作，一般来说有以下两种实现选择：
1、    在每个节点上使用单独的事务，只实现弱一致性。
2、    使用2PC保证强一致性。即分布式事务协调者先要求所有参与节点PREPARE，大家都说PREPARE成功后，再要求所有节点COMMIT。只要有一个节点PREPARE不成功，大家都要回滚。这样参与者要强制写两次日志，协调者在决定要COMMIT时也要强制写一次日志。

首先，假设用户发起分布式操作的速率为TpS（Transactions per Second），每个分布式操作平均会操作K个节点。在每个节点上，平均要操作RpT（Rows per Transaction）条记录，而操作每条记录平均要用时TpR（Time per Row），这样在每个节点上事务操作的执行时间为：
    TExec=RpT×TpR
另外，设定以下参数：
- N：数据库中所有节点上的总记录数
- TCommit：在每个节点上PREPARE或COMMIT的时间，PREPARE和COMMIT的主要工作都是写相应的日志，执行时间接近

对分布式操作性能方面一种常见的认识是若使用2PC，将导致事务执行时间大为延长，从而导致过高的事务并发冲突和死锁。当然，从趋势上使用2PC自然会导致并发冲突和死锁增长，但是否能满足应用需求，需要定量的来分析。由于死锁的概率完全取决于冲突概率，以下只分析冲突概率。

对选择1，即每个节点用独立事务时，用户发起的每个事务都会被分成K个小事务，这时系统中的并发事务数是事务速率与事务持续时间之积，即：
    CT_1=TpS×K×(RpT×TpR+TCommit)
当某事务要锁定并操作某条记录时，系统中被其它事务所锁定的记录数是(CT_1-1)×RpT≈CT_1×RpT。假设事务操作的记录是纯随机的，则该事务要锁定的记录与其它事务冲突的概率是(CT_1×RpT)/N。而这个事务总共要锁定RpT条记录，则该事务与其它事务冲突的概率是：
    TWait_1=1-(1-(CT_1×RpT)/N )^RpT≈CT_1×RpT^2/N

对选择2，即使用2PC保证强一致性时，每个节点上需要强制写两次日志，在事务协调者上还要强制写一次PREPARE日志（事务协调者上的COMMIT日志不需要强制写，这一时间可以忽略）。系统中的并发事务数是：
    CT_2=TpS×((RpT×TpR+2×TCommit)×K+TCommit)
但此时系统中被其它事务所锁定的记录数是选择1的K倍，且事务要锁定的记录数也是选择1的K倍，这时事务的冲突概率是：
    TWait_2≈CT_2×RpT^2×K^2/N
这个公式比较复杂，我们先简化一下，假设TCommit和TPrepare时间相对于TExec来说可以忽略，则可以得到有：
    TWait_2=TWait_1×K^2
也就是说事务冲突的概率将会随着分布式操作涉及的节点数K的平方数增长。平方数增长听起来比较厉害，但实际上在真实应用中K通常是很小的，绝大多数情况下等于2。如经典的转账问题，就只涉及两个节点，还有比如建立好友关系时也只涉及两个节点。在使用我们分布式数据库的大量应用中（总共包含约500张表，上千个索引，几千种SQL模式），绝大多数情况下K为2，很少有3，超过3的更是绝无仅有。因此，如果我们忽略2PC PREPARE和提交的时间，则使用2PC时会导致事务冲突概率4~9倍的增长。

换一种情况，如果执行很快但提交写日志很慢，即TExec相对于TCommit来说可以忽略，则可以得到：
    TWait_2=TWait_1×(2×K+1)/K×K^2
这时的情况比只考虑执行时间时差一些，但还是随着分布式操作涉及的节点数K的平方数增长，只不过从4~9倍变成10~21倍。

真实的情况一般在这两者之间，作为估算，可以大致认为采用2PC保证强一致性时将导致事务冲突概率增加8倍左右。

性能方面还涉及到吞吐率和响应时间。类似的进行分析，可以发现如果TCommit相对于TExec可以忽略，则响应时间不受2PC影响，反之，则2PC会导致响应时间增加为原来的3倍，平均的估计可以取增加1倍。对大多数应用，日志提交的吞吐率完全足够，则事务吞吐率不受2PC影响，反之，事务吞吐率会下降一半。

对大多数WEB应用冲突概率非常低，分布式操作只涉及2~3个节点，日志提交的吞吐率完全足够，则使用2PC可能带来的影响是事务冲突与死锁增加8倍左右，响应时间延长1倍，吞吐率不受影响。这些性能影响应该说是完全可以接受的，此时2PC带来的强一致性优点可以说远远超过其对性能的影响。

当然，以上分析中忽略了很多因素，比如网络延时，比如客户端在发起事务的多个操作之间还可能休息一会。加入这些因素后的性能分析会更复杂，但这些因素，本质上是使事务的持续时间增加，跟是否使用2PC无关。使用2PC与不使用2PC之间的性能差异比例，与这些因素关系不大。

但有一个问题需要注意。如果让客户端直接充当分布式事务的协调者，由于客户端上通常不像数据库服务器那样配置带电池的写缓存，fsync的性能很差，2PC将导致简单分布式事务的响应时间增加一个数量级，冲突概率更是可能增加两个数量级，事务提交的吞吐率也可能受到影响。解决方法是部署专职的高性能分布式事务协调者集群，配置高性能的日志存储设备如SSD。

基于这一基本的性能分析，还有一些变种：
1、如果分布式操作在各节点上并行执行，可以计算出冲突概率将是不并行的1/K。这仍比不用2PC串行高K倍，但不再是K的平方倍。比如BigTable中对二级索引和主记录的修改，就可以并行。
2、如果分布式操作是否冲突只取决于其中一个节点，可以计算出2PC并不会导致冲突概率显著增加。符合这一特征的应用模式还是BigTable中对主记录及其所有二级索引的修改，冲不冲突，完全取决于是否更新同一条记录，跟索引无关。
根据这两点也可以看出，如果用并行的2PC来保证主记录及其二级索引之间的一致性，其所带来的性能影响弱于2PC对一般分布式事务的影响，是完全可以实用的方案。

对使用2PC分布式事务的另外一个比较大的担心是如果2PC在PREPARE之后事务协调者崩溃，则参与分布式事务的各个节点只能长时间的锁定资源，等待协调者复活后告诉它事务应该提交还是回滚。如果直接让客户端直接充当分布式事务的协调者，这一问题可能很严重，因为客户端多而杂，崩溃概率高。但如果部署了专职的高性能分布式事务协调者集群，则这一问题基本可以避免。

Facebook Open Compute：如何实现一个高效低成本的数据中心

风轻扬 — Fri, 8 Jul 2011 09:28:26 +0800

Facebook Open Compute（FOC）是一个很无私的项目，据说一个团队辛辛苦苦搞了18个月，最终的结果很无私的公布出来。就这点来说Facebook比Google开放的多了，Google的数据中心技术上很保密。

搞FOC项目的目的是想建一个业界最为高效和低成本的数据中心，所谓高效，指的是能源效率，简单的说关键就是PUE。最终的成果很不错，PUE达到1.07，比目前业界主流先进水平高38%，建设和运营成本降低24%。PUE 1.07确实是很牛了，像国内的机房据说PUE一般只有2，一半的电力都没有供给给IT设备，而FOC只有7%的电力没有供给给IT设备。再优化的余地不多了。当然业界也不是只有FOC一家能做到很低的PUE，根据下图，Google和Yahoo的数据中心的PUE也都是接近的。但业界主流的传统运营商机房的PUE相比确实是差多了。

要建一个极低PUE的数据中心，气候条件很重要。最近Google号称是在搞海里的数据中心，用海水来冷却和发电。FOC没这么夸张，但FOC的数据中心特意的选在一个总体来说天气干冷的地方，这样才适合使用蒸发冷却系统。具体是在Oregon州的Prineville，沙漠地区。这里夏季7月气温最高时平均最高气温约30C，但湿度低干湿球温差很大，冬季最冷的1月份平均最高气温约10C，湿度也不大。蒸发冷却这个专业不懂，但大致说来应该是湿球温度低，干湿球温差大时就比较合适。

此外FOC对机房环境的制定比ASHRAE（美国采暖、制冷和空调工程师协会）的标准要松，ASHRAE标准是干球温度最高80.6F，FOC最高允许85F，ASHARE标准最高60%相对湿度，FOC允许最高65%。交流中Facebook工程师的回答是现在的服务器的稳定性更高，工作范围更宽，放宽一些环境限制没有问题。

一个完整的制冷过程如下：
1、吸入外部冷空气，需要时与内部回流的热空气混合后过滤
2、通过雾化系统加湿，蒸发吸热冷却
3、除湿（但交流中Facebook的工程师说目前没有启用，服务器设计成90%湿度都可工作）
4、通过风扇组压送到冷空气通道
5、冷空气穿透Rack，进入密封的热空气回流通道回到二楼
6、热空气在二楼通过排气扇排出（天气太冷时还会送回到过滤室，有时是为了给办公区加热）

根据外部气候条件的不同，制冷策略也有所不同：
- DB<80F && WB>70.3F && DP>59F：混合外风与回风，采用湿度控制，绕过蒸发冷却系统，控制湿度<65%，DP>59F
- DB>80F && WB>65.76F && DP>41.9F：只用外风，蒸发冷却，控制温度为80F，>59FDP
- DB>80F && WB<65.76F && DP>41.9F：只用外风，蒸发冷却，控制温度为80FDB，42-59FDP
- 65F- DB>52F && DP<41.9F：只用外风，蒸发冷却并加湿，控制温度65~80FDB，43FDP
- DB<52F && DP<41.9F：混合外风和回风到65F，蒸汽系统只用于加湿，控制>54FDB，>42FDP

在供电技术上，FOC主要用电池柜提供短时的后备电力，用柴油发电机组提供较长时间的后备电力。通过定制电源转换和服务器电源提高的能源转换交流。具体的说：
- 柴油发电机组提供后备电力支撑，油量够30小时使用；
- 电网和柴油发电机最终被转换为480V交流；
- 定制的480V交流到277V交流变压，备用电池柜直接输入48V直流，高效的主要电源提高能源转换效率至87%（传统方式66%）；
- 服务器电源450W，双输入（277V交流和48V直流），输出12V直流；
- 一个电池柜为6个rack和配套交换机提供45秒后备电源支持；

机架的设计很独特。6个机架分成左右两个三元组，中间为电源柜。每3个机架组成一个三元组，高47U，每机架30台服务器，共90台服务器，内还包含两台配套的在机架顶部的交换机。从资料中没看出来为什么要用这种三元组的设计，可能是为了减少布线，降低成本。

服务器是高度定制的，设计上也很独特。高度是1.5U，据说据测试这个高度最经济。每块服务器有6块3.5"硬盘。主板是定制的，有有Intel和AMD两种主板，其中80%是Intel。很多没什么用的东西都省去或简单以降低成本，如没有上盖板，没有IO面板，没有VGA插槽，没有BMC（用ROL（Reboot on Lan）和Hardware Watchdog代替，几乎不增加成本）。电源直接接在主板上，没有线缆。用4个60mm的风扇，比1U时用40mm风扇高效。

SSD的随机写一定很慢吗？

风轻扬 — Thu, 7 Jul 2011 22:03:55 +0800

对SSD一种常见的认识是随机读、顺序读、顺序写都很快，但随机写很慢。从很多目前公布的产品性能指标数据和测试结果看，确实如此。一般SSD小块随机读性能可以达到几万甚至过十万，但小块随机写性能则一般只有3-5千，相差一个数量级。

我认为这一认识不完全正确。SSD是一个很复杂的硬件，也还在不断改进，各代产品的性能表现往往有很大差异，针对不同的IO操作模式，SSD的性能表现可能有非常大的差异，它的性能表现决不能用“三快一慢”来简单的描述。要用好SSD，需要从原理上对SSD有深刻的理解，这样才能预计各种应用模式下SSD的性能表现，特别是才能预计出未来SSD的性能特征将走向何方。

SSD最基础的硬件是一堆可以并行操作的NAND Flash，之上的控制器提供了读写缓存、LBA到HBA的映射、wear-leveling、garbage collection等众多功能。控制器非常复杂，各个产商的实现也都不同，但基本上可以认为一个设计的还不错的SSD应该能够较好的发挥出底层NAND Flash的性能。如此，了解底层NAND Flash的性能特征非常重要。根据Wikipedia和《Design Tradeoffs for SSD Performance》论文的数据，NAND Flash的基本性能指标大致如下：
   4K Page read latency: 25us
   4K Page write latency: 200us
   256K Block erase latency: 1.5ms
相对于SSD产品升级换代带来的性能差异，基础NAND Flash的性能指标保持比较稳定。

根据这一基础硬件的性能指标作些简单计算。
256K Block read latency: 1.6ms，单NAND颗粒读带宽：160MB/s
256K Block write latency: 13ms，单NAND颗粒写带宽：20MB/s
  回收一个空的Block：1.5ms
  回收一个近满（50个有效页面）的Block：(25us + 200us) * 50 + 1.5ms = 13ms

据此可以对SSD的性能作出一些分析和预测。

首先，从基本的硬件指标来看，写性能只有读性能的1/8，但目前的SSD产品顺序写的性能不比顺序读要慢很多。无论是Intel X-25/320还是Fusion IO，顺序写性能仅仅只比顺序读低10-20%，而不是只有1/8。这个问题，再仔细看一下可以发现主要原因是SSD的带宽已经到了接口的限制。比如Intel 320系列，顺序读270MB/s，顺序写也有220MB/s，这主要是因为接这个SSD的SATA 3的带宽极限就只有375MB/s，再加上内存拷贝，200多MB/s其实已经接近整个硬件系统的极限了，SSD本身的读写性能再高也没用。但如果将来接口带宽大幅提高不成为瓶颈，则SSD顺序读写之间的性能差异就可能突显出来。

其次，无论是随机写还是顺序写，由于SSD都采用Copy on Write机制，最终对NAND Flash来说都是顺序写。那为什么经常随机写的性能要远差于顺序写？这里主要的差异在于页面的失效模式。随机写会导致随机的页面失效，顺序写会导致连续的大块页面失效。页面随机失效时，要回收block，需要将block中的有效页面读出并写到新位置，然后erase block，而连续的大块页面失效时，由于要erase的block中一般已没有有效页面，拷贝写到新位置的过程就没有了。

如果应用的IO访问有高峰和低谷，使得在低谷时可以完成垃圾回收的话，则erase的性能影响可不再考虑，此时随机写的吞吐率应该跟顺序写相当。反之，则erase对写性能的影响很大程度上取决于要回收的Block中的有效页面数。可以看到回收空Block和回收近满Block的用时相关很大。这可以解释为什么Intel SSD中用越多的Over Provisioning，随机写性能越高。Intel 320系列300G型，如果只用180G留120G用作Over Provisioning，则随机写IOPS就从用足300G的1400/s提高到6600/s。如果应用只用8G的话，则随机写IOPS更是可以高到23000/s。由此可见SSD随机写的性能并不一定很差，如果系统能在空闲时完成垃圾回收，或应用操作少量数据，则随机写性能应与随机读没有数量级上的差异。

不过从基础的理论数据计算，erase对性能的影响不应该像Intel 320系列那样有10多倍的影响，回收一个近满Block用时与写一个Block是差不多的，理论上应只会导致性能相差一半。这里有可能是因为Intel SSD的硬件内部IO并行不好，比如垃圾回收不能在所有NAND Flash上并行进行，或者控制器的算法还不够好。高端的硬件如Fusion IO，其随机写就不比随机读差。Intel还未发布的Ramsdale SSD的随机写IOPS也将过5万，我预计将来随着SSD技术的进步，其性能表现可能接近于基础NAND Flash的性能，随机写与顺序写之间的性能差异可能大幅缩减。

而未来的SSD，将可能更多的体现出基础硬件NAND Flash的性能特征，即：
1、无论顺序写还是随机写，其性能都远比顺序读或随机读差，可能接近一个数量级；
2、随机写性能与顺序写性能之间可能只存在2-3倍左右的差异。

有一些推测还有待实验来验证。对SSD这样的复杂硬件，分析和预测都很容易出错。有可能是我错了，也有可能是硬件设计错了，呵呵。

数据库如何抵抗随机IO：问题、方法与现实

风轻扬 — Thu, 21 Apr 2011 19:48:51 +0800

随机IO几乎是令所有DBA谈虎色变的一个问题，这个问题，往往在数据量小的时候不出现，在数据量超过内存大小时，才陡然出现，令没有经验的DBA促不及防，也令有经验的DBA寝食难安。

传统的数据库架构对随机IO几乎没有还手之力。传统数据库的核心通常是页级缓存、B+树、堆或索引组织表，这些机制，对随机IO的抵抗能力，都无一例外的可悲的差。页级缓存有很强的“连坐”效应，就是为了要缓存一条有价值的记录，顺带可能要同时缓存百条无价值的记录。传统上这一点自豪的称之为locality，是用来减少IO的，但往往会导致内存缓存的利用率很差。在记录的级别，应用的访问模式通常符合Zipf分布，其中10％的记录所占的访问概率超过90％。如果我们用记录级的缓存，用相当于数据量10％的内存，就可以消除90％的IO，但用页级缓存，这10％的热点记录，很可能就分布在70％的页面上，这样同样10％的内存，很可能只能消除可悲的30％的IO。B+树的情况也好不了，如果索引大于内存量，每次随机的索引搜索、插入和删除，几乎都将带来一次随机IO（假设索引的非叶节点都在内存中）。

新的SSD硬件可以缓解随机读问题，但对随机写依然是无能为力。SSD的技术比较成熟了，期望它哪一天能魔术般的也搞定随机写，是不现实的。但我们可以从数据库架构上来想办法，谢天谢地，其实有很多办法，虽然未必能马上就用上。

先说记录的随机IO。之前已经说过，用记录级的缓存是很好的，我们NTSE的测试表明这一招很有效。但似乎不太有公开的数据库支持类似的功能。退而求其次，大家可以用Memcached，但两者有重大区别。用Memcached时，很难保证Memcached与数据库的一致性，除非用数据库事务来保证，但这样会导致在两个系统之间进行每个事务毫秒级的锁定。虽然数据库内置的记录级缓存也需要用某种加锁机制来保证一致性，但这个锁定时间是微秒级的，并发度不可同日而语。但最重要的一点是，Memcached通常只能消除随机读IO，对随机写无能为力。而数据库内置的记录级缓存，则可以很好的解决这个问题。数据库内置记录缓存的设计，常用的有几招：
1、最基本的一招是，如果要访问的记录在记录缓存中，就不去读底层的堆文件。当然这是废话，如果不这样，那还叫记录级缓存吗？但如果仅仅是这样，记录缓存跟Memcached是一样的，还不如用Memcached，更灵活。但接下来数据库内置记录级缓存的招数，基本上都是Memcached搞不定的。
2、如果仅仅如果更新命中了记录缓存中的记录，则只更新记录缓存，不更新底层的堆等存储。具体细化下来有UPDATE和DELETE两种，NTSE暂时只能搞定UPDATE；
3、记录缓存里的东西，总是要有周期的持久化的，否则恢复时间不能保证。这个第三招，就是持久化也就是把记录缓存中的脏记录dump出去的时候，不要去更新对应的堆中的记录，否则短时间就会爆发大规模的随机读写，做法应该是像内存数据库那样，把脏记录用顺序写IO dump出来。NTSE就是这么做的，刷记录缓存脏记录时，我们先看看对应的页面在页面缓存中在不在，在，则更新堆，否则顺序dump到log中。
4、在更新时，可以只把UPDATE后的后像插入到记录缓存中，根本不去读原来的记录，当然这个要看具体情况，如果后像是依赖于前像的那这招就不灵，但很多时候是可以用的，比如根据主键找到一条记录，不管3721把其中一些属性改掉。NTSE暂时还搞不定这招，有待改进。

记录缓存的这4招，消除数据库中记录操作带来的随机IO是很有效的。遗憾的是这不是必杀技，如果记录的访问确实的纯随机的就会失效，幸运的是这样的情况不常出现。

索引的随机IO问题要更复杂一点。我们简单点，只说涉及到单个索引项的操作。传统的B+树，无论是搜索、插入还是删除（更新相当于插入+删除，就不额外讨论了），理论上都是O(log(B)(N))次IO（其中B是页面包含的键值数，N是总键值数），但实际情况下可以假设非叶节点都在内存中，因此是1次IO。磁盘一般只能有每秒几百次随机IO，因此对大的索引，每秒只能有几百次操作，这个性能真是低的可怜。B+树是70年代的老怪物，但直到今天，大多数数据库里仍然用得是它，但实际上，有比传统B+树更能对付随机IO的东西。

1996年，P O'Neil等提出的LSM-Tree是一个重大突破。LSM-Tree主要有两种变形，最简单的LSM-Tree，是一个内存中的小索引加上外存中的大索引，更新先缓存在小索引中，再批量更新到大索引，这样就有望合并对属性同一页面的多次更新的IO。复杂的LSM-Tree，是划分为多个level的很多的小索引，每个level的大小，近似的是前一个level大小的r倍，如果一个level有r个小索引，则合并形成一个下一level的较大的索引，这样随机插入或删除的平均IO开销可以降低到log(N)/B次，是一个很大的提升。但带来的问题是，搜索的时候，就要搜索这么多个小索引，而这样的索引会有O(log(N/B))个，那是可能有几十个，搜索的性能就可能下降几十倍，这往往也带来问题。LSM-Tree已经有不少的现实应用，BigTable、Cassandra、Lucene等这些用的是复杂的那种LSM-Tree，InnoDB的change buffer可以说是那种一大一小的简单LSM-Tree。NTSE想在做多版本事务的时候顺便实现change buffer。

2000年，MA Bender等提出的Cache Oblivious B-Tree是第二个重大突破。这个跟LSM-Tree有些类似，也是索引从小到大分成相邻大小翻倍的多个索引，因此随机插入或删除的平均IO开销也是log(N)/B次，但它用了Fractional Cascading的技术，使得搜索的性能较传统B+树相关不多。虽然论文发表了10年了，这种索引似乎现在只有TokuDB一家实现，它是称之为Fractal Tree。我们拿来试了试，效果果然出奇的好。

有没有可能将来搞出一个比Fractal Tree更好的东西呢，遗憾的是如果硬件不发生根本改变，已经证明Fractal Tree已经是最理想的了。

但LSM-Tree或Fractal Tree，其实只是消除索引的随机插入和删除带来的随机IO，对随机搜索没什么帮助。这个剩下的索引的随机搜索问题比较复杂，要分解来看。一种是真正的来自于应用需求的搜索，另一种是检查唯一性带来的搜索。这两种处理方法是不同的。

对于真正的来自于应用需求的搜索，处理还得借助于记录级缓存类似的技术，但这时变成索引项的缓存了。InnoDB中的Adaptive Hash Index就是这个东西。但对检查唯一性带来的搜索，Bloomfilter是个好方法，经常可以消除98%以上不必要的检查。所以BigTable里就用。但对传统B+树由于索引是实时更新的，Bloomfilter不好用，对Fractal Tree，索引是在merge的时候再批量更新的，可以用Bloomfilter。我们试了TokuDB，根据性能表明看，它对索引性索引的随机插入，也能轻松对付，估计也是用了Bloomfilter类似的技术。

因此，我们可以看到，随机IO这个老大难的问题，其实还是有不少的技术可以解决的。然而，现实是悲摧的，我们经常在用的主流数据库，无论是商业的Oracle、DB2、SQL Server，还是开源的MySQL、PostgreSQL，都基本上还在用最老土的技术，InnoDB里搞了一点change buffer，就能让人津津乐道半天。NoSQL系统走在前面，用上了LSM-Tree，但也并不是最先进的，搜索的性能经常令人担忧。在索引这方面，TokuDB走在前面，但还没为大众接受。记录方面，不清楚为什么大家不作记录级缓存，这不是很难的事，莫非认为用Memcached就可以了，“因为善小而不为”？

相信未来，总有改善的一天。

开始玩玩微博

风轻扬 — Tue, 25 Jan 2011 19:42:31 +0800

开始玩玩微博这东西，看看这玩意影响力到底能如何。

以后博客主要写技术类的，业界新闻、产品方面的就用微博了。网易微博和新浪微博同时用。
网易微博：http://t.163.com/wangyuanzju
新浪微博：http://t.sina.com.cn/breezes

深练：天才之道

风轻扬 — Tue, 11 Jan 2011 11:01:28 +0800

由于老板的推荐，周末看了薜涌写的《天才是训练出来的》之大半部，草草看过，有所感悟。

作者薜涌，身高1米67，从小身体瘦弱，体重被人戏称为“戴着眼镜刚才100斤，摘掉就没了”。直到上大学，长跑从没及格过，但自从有一次被人嘲笑后奋发图强，一举成为长跑健将，至今年近50，万米成绩仍然可达38分，换算成马拉松不到3小时，为业余中的顶尖高手。若参加第一届现代奥运会，能获马拉松冠军。

本人风轻扬，意即风轻轻一吹就满地飞扬，身高1米72，体重53公斤，算BMI与薜涌几乎一样。心脏有杂音，医生告诫不要剧烈运动，我深以为然。直到大二下，1000米从没及格过。但大二下脑筋短路开始奋发图强，二月后1000米成绩达到85分，在班中已属中上。

如此巨大的提高，原因只在于进行了有针对性的训练，即所谓深练。英文原称为Deliberate Practice，后简称Deep Practice。很多天才研究者对此作了大量的研究，发现只要智力水平在中上，经过深练，即可以很大的提高几乎任一方面的专业素养。如果持续深练得法10000小时，则几乎可以成为任意领域的专家。诚然，天资不足的人，再深练也无法成为科学领域的牛顿、爱因斯坦，音乐界的莫扎特，台球界的奥沙利文，但成为一般专家则很有可能。而这一水平，对于大多数职业而言，已足以使你获得极强的竞争力。

回顾，深练的例子还不少。数据库的理论经验，大多来自于大三时死磕厚厚的英文《Database Concept》；实现经验，大多来自于OSCAR和NTSE；MySQL实战实验，大多来自于06至07年独立一人担任DBA期间。

本人笨，25岁还不会用筷子，一直是X形的，夹东西易滑。但04年在香港，看到有中国人教外国人用筷子，跟着专心学习，结果不到一周，就能运用自如。03年前，不会打五笔。有一次脑筋短路，开始学五笔。找到一个好机会，免费帮室友打字（每晚打一小时左右）。室友乐得其成，我也进步神速，不到两周已经基本流畅。可惜好景不长，室友的资料两周后打完了，我再也没有进行过这么针对性的训练，直到今天，7年已过，五笔水平还只是当年两周后的水平，sigh！

深练有益，但下决心深练很难。一难是要有信心，二难是要将自己当白痴，三难是要坚持。对大多数技术来说，练习的方法倒是不难掌握。

InnoDB加锁实现机制初步分析

风轻扬 — Fri, 7 Jan 2011 16:04:40 +0800

虽然普通的SELECT在InnoDB里是不需要加行锁的，但LOCK IN SHARE MODE、更新操作及高串行化级别中的SELECT都要加锁。InnoDB宣称其行锁实现非常先进，开销只有每行3-4 bit。传统的数据库锁表结构，锁定一条记录时要构建一个包含被锁定对象ID信息、等待者队列、持有者队列链接等一系列东东的复杂数据结构，开销至少在100字节以上。InnoDB竟然可以做到只有3-4 bit，真是牛到不可思议。

于是，去初步了解了一下。基本原理应该是像这篇日志里说的这样还是用的Hash的锁表，只不过不是锁一条记录就创建一个复杂的结构，而是用位图来表示页面中各记录的锁定情况，这样，一个事务锁定页面中的很多行时，只需要把很多个位置设为1就行了，事务锁定大量记录时的平均空间开销就会很小。上述日志里做了个测试，一个事务锁定过百万条记录时，确实锁表占用的空间大概只有每条记录3 bit。

据此推测，如果一个事务只锁定页面中的少量记录，那这个平均开销就大了，上述日志没做过这样的测试。我简单测试了一下，发现确实如此，如果只锁定一个页面中的一条记录的话，也会新建个lock struct，占用空间似乎过百字节。如果一个事务锁定属于同一页面的两条记录，则只有一个lock struct，如果锁定不属于同一页面的两条记录，则就会产生两个lock struct。另外一条记录如果被N个事务同步锁定，锁占用的空间似乎就会达到N倍。

这样看来InnoDB宣称的单记录锁定空间开销3-4 bit是不假，但只是在事务锁定连续的大量记录时才是这样，如果事务只是随机的锁定一些记录，这些记录分散在很多页面上，则单记录的平均开销就大了。基本上锁的空间开销取决于被锁定的页面数。

上述只是推测，要了解真知还得有空时分析代码。

Dropbox差异同步算法rsync及其改进算法原理

风轻扬 — Fri, 12 Nov 2010 17:26:32 +0800

之前用过rsync很多次，只知道可以做差异同步也没研究过原理。所谓差异同步是指只通过传输两文件的差异部分将两文件同步到一致，自己取的称谓，不知道学术术语是什么。差异同步算法中最有名的就是rsync系列了。

近来研究Dropbox，想看看它的同步怎么做的，没找到官方资料，不过据推测应该用的就是rsync，于是，看看鼎鼎大名的rsync是怎么实现的吧。

rsync算法要解决的问题很简单：A和B两个文件在两台服务器中，要将A同步到与B一致，要求尽量减少同步带来的网络传输开销。

rsync基本算法
先说基本的rsync算法，并不复杂，简单的说是三步：
1、按固定大小将A分为多块，每块都计算出一个32位的滚动哈希值和一个128位的MD4（有些也用MD5），发给B一端。
2、B一端从位置0开始按的同样块大小的滚动哈希值，查找看是否命中A给的某个滚动哈希值，若匹配，则表明B文件中的这块内容与对应的A中的那块内容很可能是一致的，但由于32位的哈希值强度不够，因此再计算MD4，若还是匹配，则确认是一致内容，这时B发给A端匹配的段号。对于那些不能匹配的内容，则发给A端原始内容。
3、A端得到B端给的匹配信息，构造一个与B一致的复本，若是匹配的块，则拷贝原A文件中对应的块，若是不匹配内容则追加之。

滚动哈希值的设计基于Adler32算法，使得2~K+1字节的哈希可以根据1~K字节哈希和1、K+1字节的内容快速计算得到，这可以提高从位置0开始依次计算滚动哈希值的效率。

据试验一般来说块大小取500~1000字节效果比较好。

rsync初级优化
在上述基本算法之上可以进行一些初级的优化，比如：
1、传输数据再做压缩
2、先用更短小的哈希值作同步，然后比较同步后二者MD5，如果不一样，再换用更长的哈希值，如此在大多数情况下可以减小哈希值的传输开销。因为如果用500字节的块大小的话，一个32位的滚动哈希值和一个128位的MD4会占用原始数据1/25的开销，并不太小

基于rsync的改进算法
基于rsync的改进算法主要有多轮rsync和本地rsync两个。

多轮rsync的原理简单的说就是先用较大的块大小按rsync的方法处理一轮，但只传输那些命中的块，那些没命中的数据称为“空洞”，按较小的块大小再按rsync的方法又处理一轮，如此双可能产生规模更小的“空洞”，如此按来一轮，直到块大小到配置的最小块大小为止。最后一轮跟原始rsync是一样的，当然只处理上一轮遗留下来的“空洞”。多轮rsync在理论上可以将最差情况下的复杂度（以传输的数据量称是）从原rsync的O(sqrt(n))提高到O(ln n)。试验中有时多轮rsync可以比原rsync有10倍的提升，但大部分情况下是类似的。

本地rsync则是直接更新A到与B一致，原始rsync算法是需要构造一个与B一致的副本。为实现这一点，需要先拿到所有匹配信息后进行拓扑排序，再依次应用，是有些复杂的。

无欲无求的生活

风轻扬 — Sat, 6 Nov 2010 00:54:06 +0800

听了一天的云计算数据中心的报告，若有所思却又难以理清。百度和Google的分享都相当质朴，虽然了无新意，而其它的所谓云计算的宏伟蓝图大都抽象莫明，即便连演讲者自身都体现出不自信。

年初在国家项目期间曾写下“自信则无忧，尽力即无憾”来勉励自己以求平和的心态，半年多来，这两句话时常想起，似乎真的心态平和许多了。

从小在青山绿水间长大，靠山面水，方圆50里没有工业。从小过着无欲无求的生活，从小学、中学直到大学，像汪峰《春天里》一样没有烦恼。很多人说高中很辛苦，我觉得相当之奇怪，明明高中和本科是最最开心的时光了，只要做了功课什么都不需要想，还有那么多的女孩给我来暗恋，还有些女孩暗恋着我。不知为什么，感觉从研究生到工作开始，会有烦恼，有时会轻度抑郁，二三天不知所衷，要找亲朋好友开心一刻才能好。无欲无求的生活似乎离我越来越远。

可幸的是，这一年以来，这样的生活又离我越来越近了。也许当你看到孩子灿烂的笑脸，你会明白你失去的有多少，父亲的心似乎可以柔化一切。也许因为每天上下班时听的摇滚让我回忆起曾经的单纯。当你有了妻子孩子和可靠的居所，还有多少重要的利一定要去追求呢？虽然名的放下还远。无欲无求但可以有许多梦想，希望能做出更好许多的系统，希望能做好产品，希望有条件再多一个孩子，希望能再拥有一个靠山面水，每天可以去游泳钓鱼的房子，希望能帮助到家人朋友等等，似乎有欲有求，但求的都不是生活所必须的事情，即便个个落空，生活一样可以家庭幸福快乐美满，人生一样可以快快乐乐，如此这些欲求都可以抛弃。只求将来不要得癌症折磨一年半载，只希望可以中风安然西去。

妈妈的突然故去令我几度伤心落泪，当我在车里边听边唱“我靠在回忆的梦中冥想你的笑容，看着天上的星星今晚失去灵光”时，我多少次泪流满面，昨天听到“我不想记住，那个恐惧的夜晚，灾难穿透了无助的眼”仍然痛哭流涕。似乎一个男人爱哭是可耻的，校招时有HR明确的表示对此的鄙视，但小时是想哭就哭的，长大后受男人名号的拖累不敢哭了，现在回归了。

也不抱怨政府了，不需要再愤青了，看看王国平的《城市论》，我觉得一辈子在杭州也是挺好的，一切都会不错。看看《苏东坡传》，学习苏老所有人都是好人的乐观人生也挺好。慢慢的，学习也客气的回应问你的房子要不要出租出售，一天可能好几次的骚扰电话，谌总即便对这类电话都很客气的，末了常常不忘说声谢谢，多好。

之前妈妈下地的时候，经常不做完一块地即便天黑了都不回家，我今后种地的时候，估计早晚无定。

只求公司的猪肉早点能吃到。

沪杭高铁

风轻扬 — Fri, 29 Oct 2010 22:43:20 +0800

到上海出差，算是第一次座上高铁，之前由于有很多听闻，比如：

1、我们的高铁因为要大干快干赶紧上，都没有经过严格测试就上了；

2、人家老外其实也没大规模用过，拿咱当小白使；

3、我们的高铁非常脆弱，有人抽根烟都会使它怕了高不起来；

因此心里还有些怕怕，尤其是上车之后发现连个安全带都没有，心想这要出事我就乐去了。不过坐了之后，感觉还挺平稳，一点感觉不出是350码。

传说中会显示运行速度的LED没看到，还好有手机GPS显示速度，但有人确实是拍了照片的，奇怪。我想这速度还是不要显示的好，不要挑战某些人的神经。

坐车上先睡了回，然后看车上的杂志，讲上海虹桥火车站的，一下子50多分钟就过去了，似乎没感觉到车子有中途停靠过，所以，泸杭高铁会在嘉兴南站等中途站停吗？都没搞清楚，晕。

还得说一下虹桥火车站，这玩意其实不能称火车站，那是包括航空在内的大大大大的交通枢纽，那个大，大无边了。一下车，看到一列列乳白色的CRH排着，确实是相当之壮观。下高铁坐地铁走不了多少路，挺方便，看来设计者是下了一些工夫，想起北京的某地铁换乘，不知道是哪个艺术家设计的，曲径通幽处，走得那叫一个累。

据说这个是史上最大，世界最大。这玩意肯定有很多人说它劳民伤财的，这么多钱，为啥不补贴给咱老百姓，不过史书上从来不会这么写。我觉得是有必要的，在车上杂志里看到有人说：看了虹桥火车站，明白为什么《2012》里安排中国做避难所了。有理，这么大的工程，只有疯狂的中国人才能干啊，朝鲜应该是更疯狂的，可惜没那体力。最发达的老美，高铁认证了多少年才挤出几十公里高铁，9月去了一趟，走了几个城市，没有在搞基建的，高楼都不太看得到，都不知道在练什么内功。

公司乔迁之喜

风轻扬 — Wed, 7 Jul 2010 17:23:58 +0800

这事值得纪念一下，以前是租的单元房，一下子升级成别墅了。不过，啥时候要是很多员工都能搞上个别墅，那公司才叫是真正成就了啊。

哂两张照片，楼太大站得太近，实在拍不下啊。公司这么多玩单反的，等公司大楼都整好后，搞个摄影大赛吧，以后出去宣传就不用哪个什么效果图了。

NTSE性能提升，稳定性有待加强及随想

风轻扬 — Tue, 22 Jun 2010 17:42:41 +0800

经过几个月的努力，新发布的NTSE 0.4不但实现了NTSE自主写binlog功能，性能也有很大提高。以下是NTSE与InnoDB的对比测试，在内存是数据量的10-20%时，NTSE开启MMS时的性能有了很大的提升，达到InnoDB的9倍左右，是InnoDB结合Memcached使用时的4倍左右。其实InnoDB的性能比之前也提高不少，原因是这次测试将sync_binlog设成0，之前设为1过于严格，导致InnoDB性能很差。

不过NTSE的稳定性还有待提高，目前还已知两个问题，一是NTSE写的binlog有可能某些时候不对，二是堆和索引有时会不一致，虽然通过重建索引可以解决，但不能确定结果是不是百分百正确的。

NTSE的性能优势已经很明显了，暂时没有太大的必要再优化，目前最重要的工作是提高稳定性。在第一步都没有坚实的跨出去的时候，应该把系统搞得简单点，这是我做NTSE所获得的教训。作为第一步，NTSE最核心的一点应该就只有性能，而对性能来说最核心的只有两点：
1、内置的行级缓存，且UPDATE也可以被缓存，进行检查点时被UPDATE的记录不能强制更新到堆中；
2、大对象压缩
只要有这两点，NTSE相对于InnoDB的性能优势就应该是板上钉钉的事情。考虑到将来改起来不易，最多再加个索引前缀压缩。现在回顾一下，其实目前NTSE实现的很多功能，都不是必需的，比如：
1、高性能UPDATE。这个功能虽然对某类特殊的应用有很大作用，但对普通应用并没有太大价值；
2、定长和变长两种堆。单独为定长记录设计一种堆格式并没有太大价值；
3、面向提供高可用性的在线创建索引和OPTIMIZE。借助于MySQL的复制技术也可以实现在线的表结构修改和OPTIMIZE（在Slave上完成操作到再切换），NTSE提供这两者只是带来很大的便利，而不是有与没有的巨大区别。

虽然在NTSE的开发过程中也曾注意裁剪那些可有可无的设计，比如行级缓存原来还实现了一个从主键到记录的映射表，导致行级缓存的实现很复杂，后来被无情的去掉了。但是现在看来对NTSE需求的控制还是做得不够好，做了一些初期不应该做的功能。上述那些功能后期当然是应该增加的，但第一期不应该包括进去胡搅蛮缠。假如把上面那些东西都去掉的话，虽然NTSE的实现还是非常复杂的，但节约3-5个月的时间还是有可能的。

之所以想在产品中一下子就塞进去这么多看起来很好的功能，主要的原因在于，对产品的不充分思考和不自信。没有深入的思考NTSE最核心的是什么，不能非常自信的说出我只要做到哪几点，就一定会成功。由于不自信，总想把能想到的所有觉得有用的东西都做进去，从而导致系统不必要的复杂。系统的复杂一定不是没有成本的。杰克.韦尔奇说：不自信的管理者制造复杂，很有道理。

因此崇拜Apple，做事总显得那么自信，而且很少失败，即便失败时也是如此。Apple做iPad，就是三件事：玩游戏、看书、看电影，因此要键盘干嘛？要手写笔干嘛？但重力感应，那是绝对需要的。Apple做iPhone，就是体验和App Store，因此，要Flash干嘛？要多任务干嘛？白鸭说Apple并不是只会自己YY，Jobs一个人拍脑袋的，不考虑用户需求的，而是非常非常的重视用户需求和调研，用户调研做得极其充分，白鸭说有空他会介绍一下，可惜似乎到现在也没见介绍。不过可能见了介绍也没有用，面对同样的需求调研结果，有的人就会觉得什么都需要做，有的人就会觉得很多东西都没必要做。

再回到NTSE，老大说“知行合一”，既然稳定最重要，接下来就全力做稳定性，某些可有可无的功能就不做，比如对分区表的支持，我仅管大声宣布我们不支持分区表就行了。某些功能即便已经实现，但会导致系统更复杂，测试更难的，就暂时去掉。比如高性能UPDATE功能暂时会被禁用，即便没有这个性能优化，NTSE的性能也是远远高于InnoDB的，但这个功能会导致很多地方都麻烦很多，在最关键的功能都不稳定时，这类没有核心价值的优化对保证系统的稳定性无疑是雪上加霜。

不过我同时还会在“行进中开火”，虽然NTSE现在还不很稳定，但那些问题都是偶发事件（要不是偶发事件要知道怎么回事了），在复制的保驾护航下，在一些非核心应用中用还是可以的，因此还是要用，用，才能发现问题。而问题，总是能被解决的。

2009年数据库技术领域回顾（转载）

风轻扬 — Tue, 23 Feb 2010 10:18:24 +0800

我用有道阅读看到这篇好文，希望和大家分享。我的看法是：
1. NoSQL运动的核心并不在SQL，也不在Key-Value。现在大部分所谓的Key-Value数据库，都支持根据各属性进行索引扫描的访问方式，并不是纯粹的只能根据Key来访问。从数据模型上说，这些Key-Value数据库已经相当于必须有主键的关系模型。而这些Key-Value数据库的操作语言，也类似于受限的SQL，主要是没有联接与子查询。NoSQL运动的核心，可能是在于BASE/CAP与关系数据库的ACID的区别，然而，BASE/CAP还是ACID，与数据模型并没有强制绑定关系。

2. 基于MySQL的开源产品Drizzle发展的非常好，我在开发存储引擎中遇到的很多问题，Drizzle中都已经解决了，比如：存储引擎和MySQL上层都要维护表定义带来的不一致问题；非标准表定义信息的传递与修改等。我认为Drizzle的未来很好，被Oracle控制的MySQL官方版本的未来是黯淡的。

3. 虽然SSD还没有爆发，但马上就会爆发的。

4. 关于国内BeansDB，还有之前开源的MemcacheDB的开源的两个疑问：一、不清楚为什么决定要开源；二、开源后，更新很少，似乎开源的都是老版本，最新的东东还不愿意拿出来分享，也没什么意思嘛。

以下原文转载自DBA notes

作者：Fenng 发布在 dbanotes.net.

简要回顾一下 2009 年数据库技术领域。过去的一年，差不多也可以说是过度的一年，数据库技术以及数据存储产品等都都或多或少发生一些方向上的转变。

Oracle 收购 Sun，MySQL 前途未卜

Oracle 收购 Sun 可谓一波三折。在获得美国司法部门的批准后，欧盟委员会又开始调查，Oracle 随后抛出一个"十条保证"，眼看着欧盟就要点头，没想到 MySQL 创始人 Michael Widenius(Monty) 则在这个当口不失时机的搞出来一个"拯救 MySQL"的抵制活动，让 Oracle 头疼不已。Monty 这人多少也有点上纲上线，现在已经将 MySQL 的命运和 "Internet Free"这个大话题绑在一起了。

没有人会相信 Oracle 会善待 MySQL，谁会干放虎归山的事情呢? 换了你也会把 MySQL 雪藏起来，毕竟商业公司就要逐利。但是，也很难说一旦收购完成后，MySQL 会在短期内消失，基于 MySQL 众多开源分支以及解决方案也都发展的不错，我相信最终决定权还是在用户的手里。就算没有 MySQL，也没准儿会有 YourSQL 出来的...

尽管口水战还在进行，MySQL 的开发者倒是没闲着，在年底发布了 5.5 第二个里程碑版本，原来站点上的 6.0 系列的信息全部撤掉。5.5 更像一个集成版本，将不少第三方贡献的功能改进(比如 Google 的 Patch)融合了进来。

而 Oracle 这一年在产品上的一个标志性事件是推出了 Exadata 存储第二版，与第一个版本不同的是，这一个版本在 OLTP 方面增强了许多。从这个版本开始，Oracle 正式拥有自己的存储硬件(第一版是和 HP 合作的产物)。RDBMS 上，除了发布 11g 第二版之外，也在做功能上的调整，这一次，面向的是数据中心。

NoSQL 的兴起

这是今年数据库领域最有趣的话题。NoSQL 的由来大约是这样的：当时还效力于 Last.FM 的 Johan Oskarsson （现在已经投靠 Twitter 了)组织了一个技术会议，话题是关于"open source, distributed, non relational databases"，为了方便一点，想出来一个 "NoSQL" 的术语。然后由 Rackspace 的 Eric Evans 引用，进而流传开来(refer)。NoSQL 在基于 Key-value 的存储解决方案上提倡去 SQL 化，尤其避免表连接，并且通过一些变通的办法提供 RDBMS 的 ACID 功能（如果需要的话）。

NoSQL 的理念能够短时间内被技术圈所接受，离不开基本的理论支撑：最终一致性、BASE 、CAP 这三大基石；一方面是基于 Key-Value 的数据存储解决方案更加成熟，

所谓 NoSQL ，是针对当前对关系型数据库的过度依赖与运用而言，不要将其当成万能药，也没必要过于激进的推行 NoSQL 的模式。在我看来，NoSQL 是针对争夺应用模式上的一种理念上的运用。对多数企业来说，仍属屠龙之技，没必要照搬解决方案。至于传统的 RDBMS 是不是已经走向末路，我认为不尽然。RDBMS 依然尤其广泛的应用场景，而NoSQL如果要有更大的作为也要有来自商业上的更大支持才会有所突破。

SSD 被更多企业接受

Jim Gray 在 2006 年的那句名言：Tape is Dead，Disk is Tape，Flash is Disk，RAM Locality is King ，现在正在被现实所验证。2009 这一年，用户已经开始进一步试水 SSD 产品，包括 MySpace、Last.FM 等网站已经开始在关键应用上部属 SSD(refer: 1, 2)。而国内也有很多企业对 SSD 进行尝试性的使用，这其中包括阿里巴巴、优酷。

更多的存储厂商已经在高端存储中兼容 SSD ，除了去年的 EMC 尝鲜之外，现在 IBM、HDS 、NetApp 都加入了这一阵营。

。

随着 SSD 的价格迅速下降，很多存储厂商已经开始调整硬件架构，现在有个看似可行的趋势是在 Cache 层与磁盘层之间多构建一个 SSD 存储层，在成本与性能之间做一个折衷。

在去年年底的回顾中，我曾大言不惭的说"相信2009 年会是 SSD 爆发的一年"，总体来看，2009 年对 SSD 的部属还谈不上"爆发"。中规中矩而已。

Amazon EC2 对 MySQL 企业版的支持

尽管我不愿意谈云计算，不过 Amazon 这一年在云计算方面还是做了很大的突破，Amazon EC2 上面现在已经可以跑 MySQL 企业版了，采取按照增长付费 ('Pay-as-we-Grow') 的模式让初创公司有更多的选择，这比 SimpleDB 可以说是前进了一大步。这种模式在国内是否可行，考虑到当前内容审查的问题，还有待商榷。

国内 Key-Value 产品

这一年来国内对 Key-Value 产品的研究与运用和国外基本没太大的距离，豆瓣网先作出了不错的表率，发布了 BeansDB 存储系统，这是一个豆瓣风格的 Dynamo 实现，采用类似 Memcached 的去中心化结构。而最近得到的消息说人人网也要将其内部使用的存储系统 Nuclear 开源。相信在新的一年可供参考的 Key-Value 会层出不穷。

其它方面

Hadoop 过去一年中没有太大的变化，上了一点规模的网站都在用，快成了 Web 数据分布式计划的标准组件了。Doug Cutting 出走 Yahoo! 还是带来了一定的影响，不知道今后 Yahoo! 在 Hadoop 方面的支持力度会如何。至于面向列的 DB 发展情况，在过去的一年中进展不大。SQL Server 和 DB2 等方面似乎没什么可圈可点的大事，倒是 PostgreSQL 因为 MySQL 的不确定性而取得了不小的增长。

有一点要补充的是，假以时日，Open Data 或许也将成为一个趋势。

当然，这份回顾有浓郁的个人色彩，有不同意见请留言探讨吧。

--EOF--

本文发表在《程序员》杂志，不过这里的有些许更新。本文写作时，Oracle 收购 Sun 还没有尘埃落定，现在看起来，一切都变化太快。

最近文章|Recent Articles

本站赞助商：豆瓣网

评论数(2)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/database/database_event_2009.html

DBA Notes 理念: 用简约的技术取得最大的收益...

用有道阅读订阅DBA notes

到有道阅读开启快捷的资讯阅读之道

苹果低调投资眼动仪公司 Tobii（转载）

风轻扬 — Wed, 13 Jan 2010 10:52:58 +0800

我用有道阅读看到这篇好文，希望和大家分享。我的看法是：
我规划了一套将来用眼睛取代鼠标的方法：眼睛盯着，眨一下左眼表示单击左键，眨一下右眼表示单击右键，双眼一眨表示双击。闭着左眼移动视点表示拖动。似乎很酷啊，到时候公司里一眼望过去一堆人挤眉弄眼的。

以下原文转载自apple4us

在收购兼并方面，苹果一向极尽低调之能事，当然，比起它的很多硅谷同侪，比如思科和谷歌，苹果的收购也算得上极少。
我们能粗略数出来的： Casady & Greene、CoverFlow、P.A. Semi、EditGrid、Lala、Quattro、可能收购 iCall……以及很可能是乔布斯本人投资的 Aviary。
我在之前曾经写过：

苹果一向有对小公司、小产品点石成金般的收购能力：2000 年时，苹果买下了一家叫 Casady & Greene 的公司及其产品 SoundJam MP 的所有权，这个仅涉及三名员工的收购在不到十年之后成为年收入 40 亿美元的 iTunes；2001 年，他们招纳了一个怀揣音乐播放器创意的前菲利普员工，这个叫 Tony Fadell 的年轻人搞出了最初的 iPod； 2006 年 7 月，一家名为 Steel Skies 的设计师做了一个名为 CoverFlow 的呈现 iTunes 音乐的专辑封面的小产品，2 个月内就被苹果收购并整合进入 iTunes，甚至将此技术一路应用到其 OS 的文件管理中。

今天我们听到了这方面的最新故事：苹果战略投资了瑞典眼动仪公司 Tobii。
比起苹果目前所在的几个领域——电脑、手机、音乐播放器、电视、互联网——眼动仪显然是一个过于细分的市场了，它主要用于认知科学、心理学和医学等学术研究，以及网页可用性测试。
但是， Tobii 是一家非常独特的公司：市场上其它的眼动仪都需要用户带上一些仪器，以监控被测试者的注视时间、注视顺序和回视次数等眼动指标，但 Tobii 的产品不需要用户佩戴任何辅助仪器，直接依靠红外线捕捉目光即可知晓用户的眼动信息。网上能够查到的说法：Tobii 「眼动仪内置广角摄像机和近红外发射系统，能够在完全自然的状态下记录人们的眼动轨迹、面部表情和声音」（因为我本人并未使用过这一产品，如果您有亲身使用体验，请不吝赐教）。

这意味着什么？
即使在其官方网站上， Tobii 也不讳言：「眼动技术可以用于交互：只是用眼看看，人们即可操控电脑或让某事发生」。
这一想法由来已久，一个名为 COGAIN（Communication by Gaze Interaction）的机构亦曾做过一个相关研究：用眼睛来操控《魔兽世界》（YouTube 上的视频）。当然，这一技术也有明显的挑战：眼睛看到并不意味着有所举动，如何「确认」就成了一个问题。目光的流动非常多，像鼠标一样确定一个具体的位置似乎并不容易。而且，正因为人们观察事物的方式不同，这世界才有不同的视角，为依顺技术而接受相关训练，多么无趣？
但很显然，这笔投资对于苹果而言是战略性的，如果它能够找到一种非常好的方式将眼控加入到未来的操作系统、未来的电脑和未来的手机中，它将何其颠覆性？
说道未来的用户交互，最近一段非常流行的视频不可错过：

用有道阅读订阅apple4us

到有道阅读开启快捷的资讯阅读之道

Tokyo Cabinet事务机制初探

风轻扬 — Thu, 31 Dec 2009 17:00:44 +0800

名为初探，其实只是乱猜猜而已。之所以又去看下Tokyo Cabinet是因为发现BeansDB也是基于Tokyo Cabinet的，似乎Tokyo Cabinet相当之流行。

Tokyo Cabinet很好理解，持久化的key-value，还支持遍历，表格与索引。唯一比较费解的是它的事务支持是怎么样的。某个官方文档中说Tokyo Cabinet是基于"write ahead logging and shadow paging"来实现事务，事务支持ACID。嗯，这给不了多少信息，除了shadow paging比较奇怪，因为这个技术在支持高并发的数据库中不太用。

然后看到这个：
The database is locked by the thread while the transaction so that only one transaction can be activated with a database object at the same time。
和这个：
Tokyo Cabinet provides two modes to connect to a database: "reader" and "writer". A reader can perform retrieving but neither storing nor deleting. A writer can perform all access methods. Exclusion control between processes is performed when connecting to a database by file locking. While a writer is connected to a database, neither readers nor writers can be connected. While a reader is connected to a database, other readers can be connect, but writers can not. According to this mechanism, data consistency is guaranteed with simultaneous connections in multitasking environment.

嗯，原来事务并发控制是通过一把巨锁来实现的，事务时整个数据库被用写锁锁定，别人不能读也不能写。这样ACID中I的问题解决了。

剩下A和D，D好搞，有WAL就好做。A是怎么做的呢，嗯，看到这句话就明白了：
Because all pages are cached on memory while the transaction, the amount of referred records is limited by the memory capacity.

原来是，事务修改过的未提交页面必须在内存中不能写出去，这样事务回滚时，只要把内存中的页面扔了就行了，原来是这么个shadow paging法。

这样，A、I、D都解决了，C嘛，本来就是用来凑数的。这么实现可真是初级简单，但并发度应该不太靠谱吧。

NTSE 0.3发布啦

风轻扬 — Thu, 31 Dec 2009 16:18:55 +0800

经大量测试，发现并解决大量bug之后，NTSE 0.3终于在圣诞节当天发布。NTSE 0.3在性能、可用性、功能和可管理性四个方面都有了显著的提升：
1. 性能：性能是本版本最主要的工作之一，NTSE 0.3消除了0.2测试时发现的两个主要的性能瓶颈，即MMS与索引的并发性能问题，解决这两个问题后，NTSE 0.3中已经没有明显的并发性能问题。
2. 可用性：可用性是本版本另一项最主要的工作。NTSE 0.3增加了完全在线的索引创建和OPTIMIZE功能，执行这些操作的过程中读写操作仍可继续进行。不但如此，NTSE 0.3也已经为在线增加、删除字段作好了准备，只不过由于MySQL 5.1暂时没有对外提供的在线增删字段的接口，这一功能对外仍不可用而已（实际上OPTIMZE功能即是通过一个增加0个字段的特殊增/删字段操作实现的）。
3. 功能：增加了时间日期、二进制、DECIMAL等数据类型，已经可以满足杭研应用的数据类型需求；
4. 可管理性：数据库对象级的操作统计和连接级的操作统计让确定系统性能瓶颈更容易。

原先预计可在1个月之内发布NTSE 0.3，结果在22天之后发布，看来估计还比较准确。NTSE 0.3还不是正式版，稳定性可能不太好，有可能会崩溃。但在保证数据即便崩溃也不会丢失这一点上我们还是有一定信心的，在运行模拟博客日志行为的blogbench期间曾经测试杀死NTSE后能不能恢复，备份数据库后从备份恢复能否成功，早期曾发现问题多个，但临近发布时，已经杀死NTSE数十次，备份数据库多次，都能成功恢复。而这个blogbench既有大对象，又有MMS和MMS缓存更新，主要的功能都测试到了。

接下来将全力以赴保证NTSE的正确性和稳定性。正确性方面首先需要解决MySQL的binlog与NTSE不同步问题，然后就是测试、测试、再测试。

稳定性中最重要的是保证数据库不会损坏到不可恢复的地步。NTSE偶尔coredump还是可以接受的，但如果coredump后数据无法恢复，导致数据丢失则是绝对不行的。为此，我们将使出“绝招”，构造一个测试全方位的操作，然后不断的随机构造各类恢复初始条件来恢复，这样的测试跑它个十天八天，基本上所有的恢复问题都会被暴露出来。

计划将于明年3月发布NTSE 0.4，这将是NTSE 1.0发布之前最后的一个开发进程碑，接下来就会进入beta/rc迭代直到正式release。版本号就不叫0.x了，叫1.0.5、1.0.6之类的吧，好听点。

NTSE 1.0之后将并行开展NTSE 1.1和TNT 2.0的工作。NTSE 1.1的主题是优化，TNT 2.0的主题是多版本事务。1.1的优化最重要的是基于全局数据字典的记录压缩，据初步估计，大概可以将记录占用的空间压缩到50%以下。而且记录在内存中还是压缩形式存储的，所以空间就是磁盘，就是内存哪，而磁盘和内存就是服务器数，就是钱哪。TNT 2.0的多版本事务就不说了。

提前预祝NTSE/TNT在来年一路走好！

最最最担心的不是NTSE/TNT内核本身，这些我都有9成的把握能做好（时间上的掌握确实难些），但NTSE/TNT与MySQL对接才是难。最近才发现MySQL原有的binlog机制根本不适应NTSE，这类东东在存储引擎API里根本没有，手册里也语焉不详。还有各种各样奇奇怪怪的SQL语句真难对付，测试时就发现问题不少，这个情况太多，处理的不好就可能coredump。怎么办呢，要不开源让别人去测去，呵呵。

怎么样才是好的程序员

风轻扬 — Wed, 30 Dec 2009 22:49:53 +0800

要判断一个程序员是不是好的程序员，主要看他写的代码，因为程序员最重要的事是写代码。

即便不去理解代码的意图，只要看一眼，好的程序员写的代码与差的程序员写的代码基本上就可以看出来。好的程序员写的代码，整洁而规范，视觉上自然有一种美感。空白错落有致，注释恰到好处，命名和排版遵守统一的规范。差的程序员写的代码则经常出现过长的函数，前后不一致的命名方式和排版，过深的嵌套结构，非常复杂的表达式，随处可见的数字等毛病。

再去粗粗阅读，对好的程序员还是差的程序员就会更有把握。好的程序员写的代码，有一种精心雕琢而成的一致性。好的程序员一致会遵守统一的命名方式，如camelCase，而差的程序员的变量命名时不时的就会偏离统一规范。好的程序员的代码中拼写错误几乎不可见，而差的程序员的拼写错误要多得多。好的程序员对于同一类动作，不会忽而用这个动词，忽而又用那个同义词，如add/insert混用。好的程序员采用一致的简写规则，差的程序员则时而不简写，时而简写。好的程序员会很注意名称中形容词与名词谁在前谁在后，而差的程序员没有规则，时而在前时而在后。好的程序员很少会写出大段大段的重复代码，差的程序员却经常搞不定重复代码，他们难以将重复的代码抽取出一个统一的概念进行重用。好的程序员对于对外的API会注重注释与代码的一致性，差的程序员经常注释中的参数名称与函数定义都不一致。好的程序员很少会留下被注释掉的或用#if 0括起的垃圾代码，他们意志坚决，代码有用就要，没用就不要，差的程序员则不一样，他们经常不确信一段代码是否真的需要，他们缺乏保持代码整洁的习惯，因此他们让垃圾代码留着。

如上，即便你不懂他所用的语言，不却关心程序的逻辑，对好的程序员还是差的程序员就能做到八九不离十的判断。程序的好坏几乎总是取决于它们是否“漂亮”，不“漂亮”而好的程序，除了C++ STL源码，我再也没见过（如果你稍仔细看，STL的源码虽然不够“漂亮”，但仍然满足这里提出的一致性原则）。而又好又“漂亮”的代码则随处可见，如Linux Kernel，InnoDB，JDK，JUnit等等。

如果再仔细阅读，就能更准确。好的程序员写的代码，好似浑然天成，简单而直白。函数通常较短小，函数的名称准确的反映函数要完成的工作。逻辑简单而自然，让你读的时候由衷的发出“啊，就应该是这样”的感叹，而差的程序员的代码经常让你发出“怎么是这样？这是再干什么呀？”的疑问。好的程序员会在紧要关头加以画龙点睛般的注释，差的程序员要么没注释，要么注释只是代码的重复，纯粹是废话，更差的是注释是错的，是误导。

好的程序员未必是“语言律师”，即那种非常清楚的了解语言的各个细节，在编程时到处使用的家伙。好的程序员也不常“炫技”，在代码中精心构造一些独具匠心的片断，他们偶而会，但大多数时候总是用直白的语言来表述。

从代码也可以看出一个程序员的团队协作精神。注意团队合作的程序员，会严格按照团队规范写代码，而风格与团队规范不一致的程序员则很可能欠缺团队精神。注意团队合作的程序员会注意给模块的对外接口加以重要的说明，如前置条件、后置条件、参数能否是NULL等等，不注意团队合作的程序员懒于处理这些细节。

好的程序员与差的程序员的生产力差别巨大，项目的周期越长，项目越复杂，项目对质量的要求越高，好的程序员的价值就越大。好的程序员与差的程序员，管理成本也差别巨大，好的程序员只需要与他共同确定设计，代码可以不看，差的程序员的代码经常需要经过多次review，且仍有可能达不到理想的质量。

要成为好的程序员，首先要树立要成为好的程序员的志向，再勤加练习，天长日久，就会越来越好，这些人不怕老。没有志向永远成不了好的程序员，这些人若不在老去之前成为经理就会变成废人。

通过两个小时的笔试和半个小时的面试对于判断程序员来说是不够的。通过笔试与面试，你可以判断一个程序员是否具备算法与数据结构等基础知识，可以判断他对编程语言的特性是否掌握，可以判断他对技术是否关注，然而要知道他能否真的能很好的完成工作，不写代码是不够的。

那些显得对技术充满热情的，未必是好的程序员。这些人可能非常乐意从事有新意的工作，但后续的编码、测试、调试、文案工作则可能让他们感到厌烦。他们可能会提出好的创意，但却经常不能够有始有终的将其完成。公司不需要多少这样的人。

因此招聘的方式需要改善。招聘是最重要的，因为进来后就难以出去，即便是试用。转正条件白纸黑字写的很清楚，只要合格就可以转正，要达到合格并不是很困难。今年部门里进了很多新人，并不是人人都很优秀，但确实也都合格，自然也应该转正。

改善招聘的方法，就是让他写程序，可以出两道题，一道让他写程序，一道让他重构一个已有的较长的程序，一天之内完成。假使可以考他半个月，那么重构是不太需要的，但一天的时间太短，通过重构可以考察阅读并理解代码，并通过重构“化腐朽为神奇”的能力。那些不愿意写别人的代码，不愿意接受别人的代码，经常要重来一遍的人是不理想的。

今年有两个人采用了类似的方法。有一位简历很优秀的人，做了两道编程题被拒了，有一位简历及面试一般的人，通过编程测试，录用了。我感觉比单纯的笔试与面试要准确。

豆瓣开源数据存储系统BeansDB（转载）

风轻扬 — Wed, 30 Dec 2009 18:36:37 +0800

我用有道阅读看到这篇好文，希望和大家分享。我的看法是：
听起来很棒，国内公司的开源精神越来越好了。

以下原文转载自Solidot

豆瓣公司以New BSD许可证发布了分布式key/value存储系统BeansDB，开发者称BeansDB是简化版的Dynamo，Dynamo(PDF)是亚马逊公司开发的高可用性key/value存储系统。BeansDB采用类似memcached的去中心化结构，在客户端实现数据路由。目前只提供了Python版本的客户端，其它语言的客户端可以由memcached的客户端稍加改造得到。主要特性包括：高可用：通过多个可读写的用于备份实现高可用；最终一致性：通过哈希树实现快速完整数据同步（短时间内数据可能不一致）；容易扩展：可以在不中断服务的情况下进行容量扩展；高性能：异步IO和高性能的KeyValue数据TokyoCabinet：可配置的可用性和一致性：通过N,W,R进行配置；简单协议：Memcache兼容协议，大量可用客户端。

用有道阅读订阅Solidot

到有道阅读开启快捷的资讯阅读之道

政府网站因安装屏蔽软件而遭屏蔽（转载）

风轻扬 — Wed, 16 Dec 2009 10:54:02 +0800

我用有道阅读看到这篇好文，希望和大家分享。我的看法是：
港口交通管制--》口交，有创意！

以下原文转载自Solidot

《南方都市报》报道，武汉市气象局(目前在删除相关文章后已恢复)网站被信息监控系统检测到不允许的词而无法访问。原因应该是网站托管或租用的服务器安装了信息监控系统，服务器上的所有网站只要出现“不允许的词”，即无法打开。南京电子技术研究所网站至今还存在同样问题，点击“南京电子技术研究所简介”、“企业新闻”和“民用雷达”都会有提示“检测到不允许的词”，其中“民用雷达”页面的提示“信息监控系统检测到不允许的词：口交”，其实是来自“民用雷达广泛应用于……港口交通管制等领域”。《南方都市报》称华为公司就曾经为避邪，而在官网产品介绍中将产品名称“24口交换机”改成“24嘴交换机”。

用有道阅读订阅Solidot

到有道阅读开启快捷的资讯阅读之道

Oracle公布对MySQL的十大承诺（转载）

风轻扬 — Tue, 15 Dec 2009 16:26:10 +0800

我用有道阅读看到这篇好文，希望和大家分享。我的看法是：
Oracle很不情愿啊

以下原文转载自Solidot

为了让欧盟尽快批准拖延了快一年的Oracle与Sun的合并案，Oracle在一篇新闻稿中公布了对MySQL顾客、开发者和用户的十大承诺，以维护开源数据库在数据库市场的竞争力。 Oracle表示会继续加强MySQL的开发，增加研发投入；MySQL的后续版本，包括Version 6，都将采用GPL许可证；在未发布相同版本的GPL社区版的同时，Oracle将不会推出新的，加强版本的MySQL企业版。欧盟委员会对此表示满意。认为这将确保该交易不会对欧洲数据库市场的有效竞争带来负面影响。

用有道阅读订阅Solidot

到有道阅读开启快捷的资讯阅读之道

NTSE 0.3性能白皮书

风轻扬 — Thu, 3 Dec 2009 22:04:59 +0800

经历1年半时间开发的NTSE存储引擎今天达到了一个令人振奋的里程碑。今天不久将要发布的NTSE 0.3版本与InnoDB的性能对比测试结果已经出来了，见下图：

图中横坐标是内存与表大小的比例，由于相同的数据量时使用NTSE和InnoDB时的表大小不同，这一比例是相对于InnoDB的表大小的。纵坐标是tps，即每秒处理的事务数。

从图中可以看出:
1、NTSE性能始终显著优于InnoDB，尤其在内存<=数据量的30%时，NTSE性能大约为InnoDB+Memcached的3倍，为纯InnoDB的4倍以上。也就是说，有些时候用NTSE后，Memcached就可以扔掉了；
2、小内存时NTSE开启MMS对性能有较大帮助，内存10%时与无MMS相比提高75%，内存较大时也基本没有负面影响；
3、小内存时配置Memcached对InnoDB的性能也有较大帮助，在10%内存时提高67%，但大InnoDB内存已经很大时反而有很大的负面影响；
4、NTSE在10%内存时的性能相当于InnoDB+Memcached 40%内存时的性能，20%相当于InnoDB 75%，30%相当于InnoDB 90%，因此在提供同等吞吐率时，NTSE只需要InnoDB 1/3的内存；

另外还有一点，在图中没有给出的是，使用NTSE时的表大小只有InnoDB的54%。

测试使用的是我们模拟博客日志应用开发的blogbench测试程序。这一测试程序操作以下的Blog表:
CREATE TABLE Blog (
    ID BIGINT NOT NULL PRIMARY KEY, -- 递增生成
    UserID BIGINT, -- 按zipf分布生成，5%的用户拥有95%的日志
    Title VARCHAR(255), -- 长度10-30字节，平均20
    Abstract VARCHAR(2000), -- 长度10-500字节，平均255
    Content MEDIUMTEXT, -- 长度20-20000，二项分布，平均2.1k，内容取自从博客中随机挑选的100篇日志
    AllowView SMALLINT, -- 91%为-100，1%为100，8%为10000，与博客真实数据一致
    PublishTime BIGINT, -- 发表时的系统当前时间
    AccessCount INT, -- 初始为0
    CommentCount INT, -- 初始为0
    KEY IDX_BLOG_UID_PUBTIME(UserID, PublishTime, AllowView)
);

blogbench会模拟以下七类博客应用中的典型操作:
1. list-blogs: 按发表时间倒数排序显示某个用户最近的10篇日志的信息；
2. show-blog: 显示某篇日志内容；
3. update-access: 更新某篇日志的访问计数；
4. update-comment: 更新某篇日志的评论计数；
5. show-siblings: 显示某篇日志前一篇后一篇日志的标题等信息；
6. publish-blog: 发表一篇日志；
7. update-blog: 修改一篇日志；

表的数据的统计特征、事务的概率组合、事务中参数的统计特征、事务的实现方式都基本与线上数据库一致，因此blogbench能够将真实的模拟当前博客日志模板的行为。当InnoDB与Memcached组合使用时，我们也是完全参照前台的DAO框架实现的，比如使用一个单独的计数Memcached来存储频繁更新的AccessCount，更新AccessCount时不是立即更新数据库，而是放到一个队列里，每隔10秒处理这个队列，去掉重复的更新后再更新数据库和普通Memcached.

可以说，这一性能结果还是非常不错的。当然我们还有一些已知的优化没有实施，比如如果NTSE改为自己写binlog，对AccessCount的更新不是每次都写binlog的话，初步实验发现在10%内存时性能还能再提高30%。但目前的性能已经很不错，短期内不会再实施优化了，我们将全力投入稳定性工作。由于在NTSE 0.2发布时在稳定性上已经有良好基础，我预计NTSE 0.3的稳定性工作也不需要太长时间，应该不出一个月就可以release啦！

在此要非常感谢领导的支持和(曾经)参与NTSE项目的全体成员：余利华、邵峰、苏斌、谢可、张潇、聂明军、潘宁和李伟钊，感谢DDB组同事的大力配合。NTSE是一个非常困难的项目，目前已有C++实现代码9万行左右，测试代码也有8万多行，完成任务600多个，并且对性能和可靠性的要求都极高。没有大家的付出，不可能走到今天。虽然现在NTSE离实用还有不小的距离，但到今天应该说已经有了不错的基础，只要再接再励一定可以早日投入使用。

但NTSE只是起点，不是终点。比如某些应用要求更高，需要事务；某些应用要求更低，你可以连日志、行锁都不要，崩溃了我就重建不需要你恢复，只要给我性能；某些应用希望用key-value模型，不想白白消耗SQL解析、查询优化的开销。这些需求能不能在NTSE基础之上实现，我相信是能的，比如最复杂的事务支持，我想我已经找到了一条可行之路，就是多版本，NTSE底层已经提供了单条记录更新原子性，崩溃可恢复这些保证，我只要在上层给每条记录加上版本号信息并实现可见性判断就OK了，我相信再增加不到1万行代码就可以实现。NTSE如果支持了事务，那就不能叫NT(Non-Transactional)SE了，我想叫TNT(Transactional and Non-Transactional)吧，听起来挺酷的，大家觉得怎么样？

Twitter CEO：我们为什么要改造「转推」（转载）

风轻扬 — Tue, 17 Nov 2009 15:27:49 +0800

我用有道阅读看到这篇好文，希望和大家分享。我的看法是：
我对文章中的观点是否合理没有感觉，但感觉到，就这么简单的一个转推功能，也有很多值得雕琢的地方。

以下原文转载自apple4us

作者：Evan Williams；原文链接

编者按：如果说 Twitter 是继谷歌之后本世纪最大的互联网现象，这话可能会有人不同意。但不可否认的是，Twitter 昭示了一个「实时互联网」的雏形，而我相信这是互联网的下一个范式变革之地，尤其考虑到 iPhone 对其带来的助推作用。
Twitter 的快速流行，本已是一个值得反复探讨的有趣话题，而在它之上的一个用户自发创造的功能——「转推」（Retweet）——的爆炸性传播则是一个缩影。但更为有趣的是，Twitter 官方网站上似乎迟迟不对此巨大的用户需求做出反应，直到最近，他们才试运行了一个令很多用户不快的原生（native）转推功能。Twitter 的 CEO 伊凡·威廉姆斯上周在自己的个人博客上发了一篇长文，陈述了他对于「转推」功能的设计思路。

这周在 Twitter 上，我们推出了一个新功能，这个功能我们已经开发了相当一段时间并且已让很多用户试用过。（如果你还没有，稍安勿躁。）这个功能就是我们的原生版「转推」，几个月前比兹已经在 Twitter 官方博客上发帖提及【比兹·斯通，Biz Stone，Twitter 的创意总监，公司二号人物——译者注】。

我现在写这篇帖子，是因为我知道这个功能的设计会多少有些争议。人们对「转推」功能应如何实现有很多预想，这很容易理解。我想说一说我们在如何设计这个功能时的一些思路。在 Twitter 内部，我是这个思路的一大支持者，因为——尽管它不会满足所有形式的需求——我认为它提供了一些更新、更强大的东西。

背景

正如你们所知，「转推」是件很酷的事情，它诞生于 Twitter 用户之手，表达他们对有趣信息的热情。Twitter 客户端软件的第三方开发者也做出了积极应对，在他们的软件中加入了「转推」功能，尽管我们 Twitter 的人还没有任何行动。这并非首例，这种新型用户行为正是我们的用户和开发者所组成的生态系统最美妙之处。

人们很早就开始问我们打算什么时候把 RT 按钮加入 twitter.com。添加「转推」功能会带来很多琐碎的工作，从一些客户端软件之上可见端倪，但这事花了我们很长时间是因为我们想要让它变成一个更基础的功能，我们期望能给它赋予更多价值。

尽管「转推」今天已经得到了极大使用，但「转推」本身仍然存在一些问题。其中比较显著的有——

来源不清。在一条普通的推（tweet）里，包含了用户头像、用户名、以及推文内容。这三者之间有着特别的联系，我们称之为「推文构造」（anatomy of a tweet）。

而在我所称的「自发性转推」（organic RTs）中，尽管这几个要素没有变化，但彼此之间的关系却改变了。最显著的是，「转推」的文本不是这个你能看到头像的用户所撰写的，也不是推文中排在第一个的用户名——除非转推人做了注解，因此他们只是推文的部分贡献者。（有时候这些转推人的用户名在推文开头，有些时候是在末尾。）即使你已经习惯了常用的标注方法（其实不止一种），将推文和真正的作者而非头像所有者联系起来，仍然需要你进行额外的头脑运算。

我认为这对推文的可读性带来了潜在的巨大问题。我也常常收到别人对我的 @ 回复，以为我就是我转推的内容的原作者。

信息破碎且杂乱。来源不清还算是最好的情况了。更糟糕的是，因为不同客户端软件处理 RT 的方式不同，如果某人转推了一条转推，就会很快变成一锅浆糊。由于自发性转推的推文是可以编辑的，即使原作者的原意不会被转推人扭曲，但原话可能就发生改变了。来源不准确，在任何媒介形态中都可能出现。但在 Twitter 上，由于字数限制，这种情况便成为必然。人们会缩短或者编辑转推的文字，以使其符合规定长度。即使是出于合理的原因，这也会产生误导，以及对原作者的不公。更坏的是，转推是可以造假的，这已经成为了「垃圾推」（spam）的一种形式，假冒公众人物之名推销一些他们本人从来没说过的东西。

冗余信息。如果你关注的 5 个人都转推了同样的内容，你就看到了 5 条重复的推，这或许有用，但带来的噪音（noise）太多了。在搜索时，这种情况更为严重。比较受欢迎的用户被转推的内容足以淹没掉有效的搜索结果。正巧，写到这里时，有人对我发了一条──

噪音（Noisiness）。我们必须承认，有些人过于热爱转推了。你或许感兴趣他们本人说的话，但你实在无需探知他们兴奋地扣下转推的扳机，打出的每一条链接。今天你惟一的选择，只能是判断他们偶尔说出的珠玑之言是否值得你忍受他们的转推腹泻症【retweetarrhea，作者自造的一个词，即「转推」和「腹泻］的组合──译者注】。

无法追踪（Untrackable）。转推都可能潜藏着非常有趣的数据。毕竟，如果某事值得你向所有关注者重复说一遍，意味着它比其他信息有更多价值（转推迷除外）。如果某事被一堆人转推──数量多少视原作者有多少关注者而定──这是个有价值的信息，也许有助于人们更快发现有趣的新闻。第三方开发者已经注意到了这一现象，并建立了一些网站来跟踪这些信息（比如 RetweetRank）。但从根本上来说，这很难做到，因为这些数据是没有结构化的。

最后这一点不那么显而易见，但对于 Twitter 实现其目标──帮助人们尽快发现对自己有价值的信息──而言则尤其重要。Twitter 之美，其中一点就在于你能关注朋友、机构、公众人物、或者你觉得有趣的陌生人。但无论你如何细心打理你的关注对象名单，在每日产生数百万条推的今天，你能见到与你最相关的信息吗？或者，你看到了一些好东西，也得到了一些你并不关心的东西，同时错失了大量你并不知道的杀手级推？

我会认为，情况是后一种。一个完美的 Twitter 应该只展示你关心的东西──与你相关的、此时此地的、好玩的、任何你会感兴趣的东西──即使它们出自你没有关注的人。当然，它也应该给你最强大、最细致的控制权。我们想要有更多的方式让好东西自动浮现在你眼前。

前景

为了达到这个目标，我们试图通过「转推」功能的设计，既能帮助人们发现好东西，又要解决上面提到的这些问题。

在几周之前的一份声明中（即 Twitter 提供给开发者的官方转推 API），我们让开发者可以将新的转推功能加入他们的客户端软件，我们发布了一些简单的示意图，展示了新的转推功能在 twitter.com 上的应用效果。（今天我几次看到有人说我们只在 twitter.com 上提供这个功能，这个说法不对，现在大多数客户端软件都在进行添加这个功能的工作。）

其思路很简单：每条推的下面都有一个转推链接，你只需两次点击，就可以将此推发送给你的关注者。这解决了「信息破碎且杂乱」的问题，因为谁都不能对转推进行编辑了（下文会详细说明）。元数据（meta data，如原作者和转推者）不会显示在转推的文字里面，这样也就无需对其进行编辑以缩短长度。由于这个原生功能建入了整个系统，因此这些转推是 可追踪的。并且，因为可追踪，我们就能解决冗余信息的问题：你的关注对象中有多人转推了同一信息，你也只会看到一条。

转推会更加快捷容易，你再也不用去编辑转推的文字，这样你也不用担心你的关注者是否已经看过了这条推，这会鼓励人们更多进行转推，更多有用的信息也会传播更广。

噪音问题的处理方式，是新增了一个系统设置，让你可以针对每个关注对象单独开启和关闭他们的转推。也就是说，如果你只想看某人自己写的推，你就可以不用删除他而又免受他的转推之扰。

来源的问题：为了免除来源不清的麻烦，在你的时间线中，我们会显示出被转推的内容的原作者的用户名和头像──同时在元数据中显示谁转推了此条（当然只显示你加了关注的人）。我们的决定是，这个样子──

要比这个样子的呈现更好──

@AleciaHuck 的转推并无过错，只是第一种呈现方式更简洁易读，并且也合理地表明了原作者是 @badbanana。即使你认识 @AleciaHuck，也没有必要将她的头像显露在这里。

［新转推机制］不好的地方是，在自己的时间线中看到非关注对象的头像，这会有点让人吓一跳（甚至会令部分人不快）。我希望这些人能明白：你已经通过自发性转推看到过同样内容了。这只是给了你更多的上下文。我的体验是，你会很快适应，而且这种机制更便于理解事情。如果你觉得某人不断把你不喜欢的人塞进你的时间线，正如之前所言，你只想看人们自己原创的推，你可以（挨个）关闭所有关注对象的转推。自发性转推可没有这样的灵活性。

［新机制］另外一个会让部分人不喜欢的地方是，与自发性转推不同，新机制中你无法对转推添加注释，或者在转推时顺便发表你自己的评论。有些人会在每条转推上加上注释，有些人则从来不加。但在很多情况下，新机制是绝对很有用的。出于简洁的考虑，我们在第一版中去掉了这个功能。不过我们对此还是有一些想法，可能我们将来会加入这个功能。（这一点万万不要忽略。）

那当你特别想在转推中加评论的时候怎么办呢？别忘了，没有人拦着你发推的时候引用别人的推。还有，旧式转推并没有禁止。在这一版本中，我们不得不决定哪些需求是要优先考虑的。但就像 Twitter 之前完全没有转推功能的时候，人们还是有自己的办法。我们这只是多提供了一个选项。

不过，最重要的一点是，这个功能应该让 Twitter 更有力地帮助人们找到他们关心的东西。

大家要想更明白我们希望达到的效果，就去看 TechCrunch 今年 5 月份一篇帖子《转推的惊人潜能》后面的留言吧，帖子的作者大卫·萨克斯（David Sacks）是 PayPal 的前任 COO，现在 Geni 和 Yammer 的 CEO。他在文章中阐明了我上面讲的东西──他描述了现在的转推方式的缺点，并且对于原生转推功能提出了建议，与我们所做的事情完全一致。（信不信由你，在他说之前我们就已经有这个设计思路了──并非我们为了避开盗用他创意的嫌疑。）

看到我们的用户和开发者的创造，以及教会了我们转推，我为此激动不已，我们因此才能给它带来更多改进。

用有道阅读订阅apple4us

到有道阅读开启快捷的资讯阅读之道

Google GO语言是十年内首个系统级编程？（转载）

风轻扬 — Thu, 12 Nov 2009 23:07:54 +0800

我用有道阅读看到这篇好文，希望和大家分享。我的看法是：
我喜欢D语言，不喜欢Go语言，Go语言有些过于原始了吧

以下原文转载自Solidot

GOGOGO 写道 "Go语言官方介绍视频上说到：最近10年没有新的系统编程语言出现。很显然这句话完全无视了D语言的存在。有趣的是，用Google搜索"system programming language"，第一个结果是相关的wiki页面，第二个结果就是D语言。另外，D语言的作者Walter Bright曾在Google作过两次报告，在报告前他询问有多少人知道D语言，“几乎所有人都举手了”。这样的话那就只有一种解释：Google认为支持内嵌汇编，异常处理，模板元编程，运算符重载等等特性的D语言，不算一种系统级语言。而以上特性全都不支持的GO语言，才能算是系统级语言。"

用有道阅读订阅Solidot

到有道阅读开启快捷的资讯阅读之道

云计算中的结构化数据: Amazon RDS

风轻扬 — Thu, 12 Nov 2009 22:03:07 +0800

云计算的先驱Amazon近日推出云中的关系数据库服务（Relation Database Service），简称RDS。

一向在云计算中真才实料的Amazon，这次玩了一把虚的，因为RDS，不是什么新鲜玩意，实实在在的，只是一个MySQL 5.1，单机的。

Amazon帮用户简化的是数据库的管理与监控。RDS会帮用户搞定数据库软件自动升级、自动备份、根据指定的策略保留一段时间的备份、从备份恢复等事情，另外，通过Amazon的CloudWatch技术，可以对数据库进行监控。也就是说，用了RDS，你可能不需要初级的SA/DBA了。

RDS提供内存从1.7G到68G不等、存储从5G到1T不等的多种数据库实例（Database Instance），实例不够时，要加很方便，调用一个API CreateDBInstance，新的实例就可以用了。但要记住，这个实例是空的，要把它的资源用起来，是应用自己的事，Amazon帮不了你什么忙。

Amazon在有了SimpleDB的情况下，还推出RDS，是因为很多用户需要用，可见关系数据库的根基极其稳固。

RDS对于云计算，也只能算是应景之作，权宜之策。

云计算：关于新浪SAE的初步猜测

风轻扬 — Tue, 10 Nov 2009 11:50:00 +0800

新浪近日推出Sina App Engine，涉足云计算。由于需要邀请吗，无法注册。目前的文档非常原始。目前能够获得的最重要的信息如下：

SAE具有以下特点：

自动负载均衡 - - - - 根据应用压力自动调整服务规模，自动负载均衡
自动分布式代码部署 - - - - 原子的将开发者代码部署到所有web前端
自动健康检查 - - - - 所有设备自动健康检查
故障系统自恢复 - - - - 发现故障服务自动内部无缝切换，故障报警和有限度自行恢复
多平台简单SDK操作 - - - - 主流OS平台SDK支持，任何一台PC即可享受SDK
快速分布式web应用开发 - - - - 提供多种分布式服务，接口友好封装，减少开发者学习使用成本
团队开发写作 - - - - 开发者可以进行项目团队管理，代码管理、在线沟通方便有效
资源自动分配 - - - - 符合云计算理念，所有资源在配额内，自动分配
所付即所用 - - - - 符合云计算理念，最大粒度量化开发者成本，所付即所用，所付仅所用
服务高可靠SLA保证 - - - - 全架构高冗余实现高可靠性

SAE为开发者提供以下服务：

PHP5 Runtime运行环境 - - - - 基于PHP 5.3.0内核
支持读写分离的分布式数据库服务 - - - - 基于Mysql数据库
分布式文件存储服务 - - - - 基于分布式文件系统
基于Memcache协议的分布式缓存服务 - - - - 基于集群memcache系统
URLFetch远程数据抓取服务 - - - - 基于分布式proxy服务
Cronjob定时任务 - - - - 基于分布式定时器服务
SPP图片处理服务 - - - - 基于分布式高CPU计算服务

第一部分，即SAE的特点是虚的，第二部分，根据SAE提供的服务大致可以看出来SAE干了些什么。估计主要是：
１、用MySQL复制技术实现一定可伸缩性的MySQL服务，没有sharding；
２、分布式文件系统不清楚是新浪自己开发的，还是用现成的；
３、Memcached没什么好说的，现成的拿过来用；
４、分布式计算功能是受限的，仅限于处理图片；

估计新浪这个SAE中原创的东西不多，主要做的是把一些常用的技术集成起来，跟GAE，还是不能比啊。

引用需求管理和人力资源管理

风轻扬 — Mon, 9 Nov 2009 22:36:05 +0800

我非常赞同这里对需求管理的描述，尽管我更愿意称之为需求开发。好的需求要从哪里来，判断一个需求重要与否有什么方法可循，有什么规则可用。这是至关重要的。第一个问题不解决，产品不知道做什么；第二个问题不解决，产品就会乱做一气。而且这些，光有一两个产品经理知道还不行，至少还要让公司领导和中层管理都清楚，明白。

需求怎么来呢。我们目前可能最缺乏的是对用户反馈的分析。用户反馈要如何分析，我的意见是：

不听用户的意见是不对的，盲目听取用户的意见也是不对的。听取用户意见的正确做法是，充分收集大量的用户意见并消化吸收，并构造出一个逻辑自恰、各方面协调一致且可行的框架，将大多数用户的意见囊括其中，而少量用户的意见则可以摈除在外。

至于第二个问题，我的观点是就目前公司的情况来说，稍逊于第一个问题。

其实，我现在有点Fans晓文哥的。

引用

胡晓文（男，一子一女）的需求管理和人力资源管理
产品开发无非是要做好两件事情：方向和执行，而需求管理和人力资源关键恰恰是这两件事情中最细致的工作。

这里所指的需求管理并不是说把这个版本的需求都列个表，定上优先级交给开发部门，然后一股脑的开发出来。而是说把各个途径收集到的需求有效的整理起来，分析各个需求针对的目标，可能对产品带来的收益等等，根据分析的结果排一个优先级，然后，产品经理可以针对不同目的选出最先需要实现的那些需求。

没有需求管理的产品往往是这样：召集各方老大讨论发展思路，市场部门觉得应该加大推广力度，商务部门觉得应该拓展更广泛的企业间合作，QA部门觉得目前开发流程需要规范，用研部门觉得可用性存在较大问题等等，而最后产品部门还是按照自己原有的思路有条不紊的进行，各位老大提到的建议选择性的执行一些，最后总结计划的时候，还是一堆需求的堆砌，要说为什么这个需求这么重要？因为重要；为什么另外一个需求到现在还不做？没人手；长远计划是什么？做完这些再考虑。

方向定完了，接着是执行。软件的开发完全靠人，而人会因为多种原因表现的不在状态，比如：不认同其他人的观点，不知道自己所做的工作到底处于怎样一个地位，长期干同一个工作感到厌烦，长时间一个人工作孤单寂寞，对自己的未来没有把握等等。这些因素都可能造成工作的非经济性：厌倦、疲劳、压力、低生产率、劣质品、常矿工和高离职流动率。这些表现的出现，往往会被管理者认为是无德或能力低下。在我看来，在某些特定的组织中，是不大会出现能力特别差、品行特别恶劣、特别无德的人，在其背后可能是性格原因，也可能是心理原因，还可能是工作环境的影响。这对管理者来说是非常大的考验，如何找到每个人不在状态的原因，如何激励，仅仅依靠施加更大的压力是否可以做好？

云计算中的结构化数据：Google GAE Datastore

风轻扬 — Mon, 9 Nov 2009 12:08:11 +0800

GAE Datastore是Google App Engine提供的（半）结构化数据存储系统，基于Google大名鼎鼎的Bigtable技术构建。

一、数据模型
GAE Datastore的数据模型与关系模型有很大的相似性，但是无模式的。GAE Datastore的接口主要是ORM风格的，一个类，称为kind，与关系数据库中的表类似。一个kind中的数据为多个entity，每个entity有唯一的key标识。每个entity可有多个property，一个property可用多个value。这与关系模型有类似的地方，但GAE Datastore中属于同一个model的不同entity可以拥有完成不同的property，不同entity的同一个property的value的类型也可以不一样。因此GAE Datastore的数据模型更为灵活。

多个entity可组成entity group，一个entity group实际上是以一个entity为根，通过父子关系（在创建entity时指定父亲）构成的子树。这一模型类似于关系模型之前的层次数据库，自然也拥有与层次数据库类似的局限，如很多模型就很难自然的用这种层次模型建模，如学生选课系统Student-Course-Elect，谁是谁的父亲呢。entity group主要用于事务，后面会讲到。

二、查询与索引
GAE Datastore提供类似于SQL的GQL查询，从SQL的观点看，GQL的限制是只有单表查询，有WHERE、ORDER BY和LIMIT/OFFSET，但没有GROUP BY、HAVING、聚集函数等功能，也不支持子查询。WHERE条件可以是基本的"property op value"条件通过and/or任意组合，ORDER BY可指定多个属性。但条件的复杂度有一定限制：
１、如IN (list)条件中list最多只能有30个元素；
２、不等条件只能针对一个属性指定；
３、不等条件属性必须出现到ORDER BY的最前；
这些限制，据估计应该是为了实现方便和保证性能，如不等条件属性在ORDER BY的最前这一限制使得系统可以方便的通过索引扫描直接输出有序的结果，不需要再来排序。

更新的形式相比SQL有很大的限制。UPDATE通过put接口实现，给的参数是一个完整的entity，似乎不能像SQL一样只更新某些属性，为了更新一个属性，似乎需要先取出整个entity（系统可能用lazy load技术，没有用到的属性不会取）。删除时只能指定一个key列表，在关系数据库中的一条DELETE语句要分成两步，先通过查询得到要删除的entity的key，然后再来删除。并且一次操作中删除的entity个数不能超过500。

默认情况下GAE Datastore会建立一些基本的索引，根据文档的描述，我推测GAE应默认为每个属性建了一个索引，并且索引中都包含key (类似于InnoDB中的二级索引中都包含主键)。应用也可以在在配置文件中定义索引，指定索引包含的属性及排序方向。索引的排序方向必须与查询中ORDER BY的方向一致，也就是索引只能正向，不能反向扫描，我不清楚造成这一奇怪限制的原因是什么。

如果一个查询没有合适的索引，则不允许执行，也就是像关系数据库一样的表扫描是不行的。

三、事务
不使用事务时，对每个entity的写操作是原子的。

系统使用乐观的并发控制，其特征是在有并发冲突时，不等待，而是让操作回滚失败。这保证了操作的响应时间，但可能导致由于无法立即完成而失败的操作增多，这就好比基于锁的数据结构会被阻塞，无锁数据结构则可能需要不断的进行CAS循环。系统提供自动的重试机制缓解这一问题。

在同一个entity group中的多个entity操作可组合成一个事务，事务的ACID性质有保障。GAE Datastore应该是通过多版本的技术实现的，因此事务能够获得事务开始时的一致快照，奇怪的是事务本身的更新也看不到。

对不同entity group的操作是无法组合事务的，而entity group必须通过entity间的父子关系才能组织赶来。这使得GAE Datastore的事务会受一些限制，比如经典的银行转账问题是搞不定的，两个银行账户，谁是谁的父亲呢。理论上用一个伪的根entity把所有entity组成一个entity group，可以解决这一问题，但这会影响性能。因此只所以限制事务只能在一个entity group内，是因为系统在决定entity存储位置时，会将同一entity group存在在一台机器上，如果把所有entity都纳到一个group，系统就无法分布与伸缩。

有一个细节问题是事务的提交分两步进行：更新entity和更新索引。因此可能出现根据key找到的是更新后的entity，但根据索引找不到。

四、限制
GAE Datastore的数据或操作有很多限制，比如entity最大1M，一次删除的entity最多500个，查询最多返回1000个结果等。这些限制可能会给应用开发带来不便。对于查询最多返回1000个结果这个限制，准确的说是limit + offset不能超过1000，即如果你指定了offset是200，那最多只能返回800个结果了。

五、我的评价
系统性能的两大要素是Scalabity和Efficiency。Scalable的系统不一定Efficient，Efficient的系统也不一定Scalable。对于海量数据存储系统来说，Scalable是必须的，是行与不行的问题，但Efficient也是非常重要的，是省与不省的问题。

GAE Datastore的Scalabity我估计是不错的，但我不清楚有什么具体的证据表明其Scalabity到底
怎么样。GAE Datastore的数据分布对应用来说是透明的，应用不能指定根据某属性的值进行哈希分区之类的显式数据分布策略，这使得精准的查询路由难以实现，Bigtable论文中说的bloom filer的效果是值得怀疑的。如果实现不了精准的查询路由，很多查询都要访问大量存储节点的话，就会影响到Scalabity。虽然Google内部很多产品也用用GAE Datastore，但我们知道Google是买服务器不眨眼的，不好比。

但其Efficiency怎么样，我持很大的怀疑态度。无模式将使得系统不能进行很多优化，底层基于GFS，通过冗余保证可靠性等都可能会影响到系统效率。有人反映Amazon SimpleDB不快，最简单的查询的响应时间也超过100ms，不知道类似的GAE Datastore会怎么样。

功能上，最大的优势是无模式带来的好处，即应用升级时不需要像数据库那样做非常耗时的增加/删除字段操作了。但这是一把双刃剑，也可能会带来混乱。打个比方，这就类似于静态类型与动态类型编程语句的区别。

其次，是ORM风格的接口带来的开发便利，不需要像JDBC编程那样写很多SQL语句。

与数据库相比，GAE Datastore的功能局限性也是明显的，主要体现在查询处理和事务处理两个方面。查询处理方面，查询只能是单表，没有GROUP BY和聚集函数，查询的条件复杂度和查询返回的记录数都存在限制；DELETE不能指定WHERE，只能指定key的列表等。对事务的支持是受限的，只能在entity group中进行。这些局限，给应用开发会带来多大的困难，我不清楚。我想，只有将我们的常见的应用如用户与好友关系、日志、相册、消息等，用关系数据库和GAE Datastore对照着实现一遍，那么哪个系统好用，哪个不好用才能一清二楚。

多版本并发控制：PostgreSQL vs InnoDB

风轻扬 — Sat, 7 Nov 2009 22:15:44 +0800

多版本并发控制技术被很多数据库或存储引擎采用，如Oracle，MS SQL Server 2005+, PostgreSQL, Firebird, InnoDB, Falcon, PBXT, Maria等等。新的数据库存储引擎，几乎毫无例外的使用多版本而不是单版本加锁的方法实现并发控制，可以说多版本已经成为未来的发展趋势。

虽然都是多版本，但不同的系统的实现却有很大不同。在开源数据库领域最负盛名的两个系统PostgreSQL和InnoDB的多版本实现就可谓有天壤之别。

一、PostgreSQL的多版本实现(基于8.4.1版本)
PostgreSQL采用堆+B+树索引（忽视R树、哈希、GiST等不常用的索引）的存储结构，堆与索引的存储模式不同。

堆中记录包含版本化信息，PostgreSQL不区分记录的最新版本或老版本，都存储在堆中。简单的说，堆中每条记录头上记录t_xmin和t_xmax两个属性，分别表示创建与删除这一版本的事务ID，另外记录t_ctid属性，表示该记录下一个更新的版本的RID，即记录的多个版本构成从最老到最新的单向链表（见HeapTupleHeaderData结构）。DELETE一条记录时，设置t_xmax，并不将记录真正删除；UPDATE一条记录时，也不直接更新，而是插入一个新版本，对原来被更新的版本，将其t_xmax设为当前事务ID，设置其t_ctid指向新版本。

有了这些信息还不够，为了判断版本的可见性，还需要两个东西，一是事务提交日志，二是事务快照。事务提交日志对每个事务使用两个bit，记录事务是活跃、已提交还是已回滚。事务快照在事务开始时分配，其中最重要的信息是当时活跃事务的列表（见SnapshotData结构）。

有了这些东西，系统可以判断一个版本是否可见。判断过程比较复杂，不过从简单的原理上说，系统先通过判断t_xmin是否在全局活跃事务列表中、是否在事务快照活跃事务列表中、根据事务提交日志判断事务是提交还是回滚了等来判断t_xmin事务是否在事务开始时已经提交；然后用类似的方法判断t_xmax是否在事务开始时已经提交。如果t_xmin在事务开始时没有提交则不可见；如果t_xmin在事务开始时已经提交而t_xmax没有，则可见；如果t_xmin和t_xmax在事务开始时都已经提交了则不可见。（详细过程见HeapTupleSatisfiesMVCC、TransactionIdDidCommit、XidInMVCCSnapshot等函数）。

索引中则不包含版本信息。一般情况下，记录的所有版本都在索引中存在对应的索引项。举个例子，如果一个表有三个索引，更新一条记录时，不但在堆中会插入一个新版本，新版本对应的索引项也要插入到三个索引中，即使这次更新可能没有更新某些索引的属性（见ExecUpdate函数）。在PostgreSQL 8.3中引入了HOT（Heap-Only-Tuple）技术，如果新老版本在同一页面，并且UPDATE没有更新任何索引属性，则不插入新版本对应的索引项。

由于索引没有版本信息，进行索引扫描时，即使查询所需所有属性在索引中都存在，也需要从堆中取出对应的记录判断是否可见（见index_getnext函数）。

事务提交或回滚时操作简单，除事务提交时要写出事务外，只需要更新事务提交日志中对应的事务状态。也就是说回滚时并不需要将事务所作的操作从物理上清理掉，只要将事务状态设为已经回滚，则该事务产生的版本对其它事务自然就不可见了。

老旧的不再需要的版本，即不会被将来的任何事务见到的版本的清理是通过VACUUM实现的。由于新老版本混杂在一起，进行VACUUM时本质上是需要扫描所有数据。8.4版中引入了Visibility Map技术，用来在VACUUM时跳过那些肯定不包含老旧版本的页面，但如果系统更新频繁且离散，这一技术就派不上大用场。在线的VACUUM只能清理页面中的老旧版本，但不能缩减表占用的空间，其实是产生碎片。要缩减表空间时的VACUUM会锁住表导致期间表不能被更新。

二、InnoDB的多版本实现（基于MySQL 5.1.33版本带的InnoDB）
InnoDB采用索引组织表的存储结构，没有堆，记录存储在主键索引中，其它索引称为二级索引，其中每个索引项都包含所对应记录的主键。主键索引与二级索引的存储格式也不同。

主键索引拥有版本化信息，但与PostgreSQL不同，一般情况下InnoDB的主键索引中只存储记录的最新版本，旧版本的信息则集中存储在回滚段中，只有主键被更新时才需要同时存储多个版本在主键索引中。主键索引记录的头上包含有6字节的事务ID与7字节指向回滚段中旧版本的指针（见MySQL手册）。DELETE时只是标记而不真正删除。UPDATE时进行本地更新，并将前像写到回滚段中。

存在与PostgreSQL中事务快照类似读视图，也记录了事务开始时的活跃事务列表（见read_view_struct结构），但不需要PostgreSQL中的事务提交日志。根据读视图和记录头上的事务ID，可以判断出一个版本在事务开始时是否已经提交，即是否可见。如果存储在主键索引中的记录不可见，则根据指向回滚段中旧版本的指针找到旧版本信息，构造出旧的记录。回滚段采用的是append-only的日志型存储，记录的旧版本信息并不是一条完整的记录，而只是被更新的属性的前像。回滚段中的旧版本信息中也包含更旧的版本的位置，即版本链表是从新到旧的。

由于没有事务日志表示事务是否回滚，在事务回滚时必须清理该事务所进行的修改，插入的记录要删除，更新的记录要更新回来（见row_undo函数）。事务提交时则无需处理。

二级索引中的每个索引项并没有版本化信息。但在页面头记录了对该页面操作的事务的ID的最大值，通过这一值可以判断页面中是否可能包含不可见的数据，如果是，则需要访问主键索引判断可见性。否则，可以直接从索引中获取查询所需属性。二级索引中可能存储一条记录的多个版本对应的索引项，如果UPDATE操作更新了某个索引的属性，则类似于PostgreSQL，插入新索引项到二级索引中，老索引项并不删除。但没有被UPDATE操作更新的索引则不需要插入新索引项。

系统使用一个后台线程不时处理回滚段，在需要时清理由于DELETE、二级索引或主键索引中由于主键被更新而产生的老旧版本，这一过程称这purge。如果UPDATE没有更新索引，则不会带来purge开销。

三、我的评价
PostgreSQL与InnoDB的多版本实现最大的区别在于最新版本和历史版本是否分离存储，PostgreSQL不分，InnoDB分。

PostgreSQL的这种设计被其最初的设计者Mike Stonebraker称为no-overwrite的设计，在设计了PostgreSQL几年之后他的一篇回顾性论文《The Implementation of Postgres》（PostgreSQL早期叫Postgres）中，Stonebraker指出当初这样设计的主要原因是寻求与当时已经广泛使用的WAL模式不同的存储机制，有点为了创新而创新的意思。这一设计有两大好处：一是事务回滚时无需复杂处理，非常快；二是可以查询以前的历史数据。还有一个可能的好处是可以实现数据即日志，即更新时只要更新数据就行了，不需要再写日志来描述做了什么更新。但要使这个好处实现，需要有一种持久的，并且随机写具有与顺序写类似性能的存储介质才行，因为为了保证事务提交后的持久性，需要写出被事务更新的数据，而这些数据可能是离散的。WAL系统则不同，事务提交时只需要写日志就行了，而日志是顺序写入的。当前的硬件环境并不是这样，因此PostgreSQL中仍然还要写日志，只不过不需要写UNDO日志，只要REDO日志就行了。

最新的PostgreSQL与当初Stonebraker的设计已经有了很大改进，比如HOT技术减少了索引中的版本数，Visibility Map技术加快了VACUUM，记录头部结构也更紧凑。但no-overwrite的设计原则仍然没变。

相对于InnoDB，PostgreSQL的优势似乎主要的只有一条：事务回滚可以立即完成，无论事务进行了多少操作。查询以前的历史数据的功能并不常用，在目前的PostgreSQL中也并不实用。

PostgreSQL的主要劣势在于：
1、最新版本和历史版本不分离存储，导致清理老旧版本需要作更多的扫描，代价更大；
2、UPDATE不是本地更新，会产生老旧版本需要清理。与之相对的是InnoDB只有在事务回滚时才需要清理老的记录数据。而事务回滚是罕见的；
3、只要有一个索引属性被更新，或者新版本的记录与原版本不在同一页面，就要插入所有索引的新版本索引项；
4、堆占用的空间不能通过在线的VACUUM回收，在线VACUUM会产生很多碎片（这也是由于使用了堆而不是索引组织表导致的）；
5、由于索引中完全没有版本信息，不能实现Coverage index scan，即查询只扫描索引，直接从索引中返回所需的属性。与之相对的是InnoDB中二级索引页头记录的最近修改该页的事务ID信息可以在大部分情况下实现Coverage index scan。Coverage index scan是应用中经常使用的优化技巧，PostgreSQL不支持这个对提升系统性能带来很大限制，因为索引扫描是顺序访问，去访问堆则很可能变成乱序访问，性能可能相差百倍；
6、判断版本可见性更复杂，开销更大。PostgreSQL比InnoDB在判断可见性时，需要增加访问事务提交日志的操作，事务提交日志每个事务需要分配两个bit，对高更新负载的系统会占用较大空间，这时要么事务提交日志回占用大量内存，要么判断可见性时就可能产生额外的IO。对比PostgreSQL中判断可见性的函数HeapTupleSatisfiesMVCC和InnoDB中判断可见性的函数read_view_sees_trx_id，可以容易看出这两者的复杂度不可同日而语。

InnoDB的主要劣势在于事务回滚时需要清理事务所作的所有修改，因此使用InnoDB时要避免使用超大型事务，否则回滚可能超慢无比。

风轻扬

对云计算市场的几点预测

Amazon DynamoDB详解

Hadoop++：Hadoop的局部性能改良

Hadoop执行过程

Amaon AWS's EBS

Amazon AWS云计算服务简介

Amazon SimpleDB

Oracle NoSQL Database

Clustrix Sierra关系数据库集群

NTSE最近的进展及随想

基础系统软件的价值

分布式事务性能分析

Facebook Open Compute：如何实现一个高效低成本的数据中心

SSD的随机写一定很慢吗？

数据库如何抵抗随机IO：问题、方法与现实

开始玩玩微博

深练：天才之道

InnoDB加锁实现机制初步分析

Dropbox差异同步算法rsync及其改进算法原理

无欲无求的生活

沪杭高铁

公司乔迁之喜

NTSE性能提升，稳定性有待加强及随想

最近不写博

2009年数据库技术领域回顾（转载）

苹果低调投资眼动仪公司 Tobii（转载）

Tokyo Cabinet事务机制初探

NTSE 0.3发布啦

怎么样才是好的程序员

豆瓣开源数据存储系统BeansDB（转载）

政府网站因安装屏蔽软件而遭屏蔽（转载）

Oracle公布对MySQL的十大承诺（转载）

NTSE 0.3性能白皮书

Twitter CEO：我们为什么要改造「转推」（转载）

Google GO语言是十年内首个系统级编程？（转载）

云计算中的结构化数据: Amazon RDS

云计算：关于新浪SAE的初步猜测

引用 需求管理和人力资源管理

云计算中的结构化数据：Google GAE Datastore

多版本并发控制：PostgreSQL vs InnoDB

引用需求管理和人力资源管理