风轻扬

今早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来提升系统性能。

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来计算联接。

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

若以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/EMailSES：发邮件服务Elastic Load Balan

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，聚集函数只

近日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不同的多条记录一定在同一par

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

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

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

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

并发控制使用MVCC，保证事务ACI

盛大推出云计算服务，看起来想做类似于Amazon AWS的IaaS。看了一下，结构化数据管理的功能很弱，只有最简单的Key-Value服务，只有GET/PUT/DEL，没有条件更新没有锁，没有扫描，这让我觉得很不靠谱。结构化数据管理是99.9%的应用都需要的，而基于盛大云这样简单Key-Value来开发应用是很麻烦的事。比如：

1、如果把多个实体属性拼起来，没法索引，效率也不高；如果分开，那经常得用很多个GET；

2、没有索引和扫描，各种数据列表都不容易，比如按时间/阅读次数/评论次数排序的文章列表，你要用一个KV来维护ID列表，这会涉及复杂逻辑（比如按阅读次数排序的列表就不好搞），而且还会数据不一致；

3、刚说到阅读次数，好把，基于盛大云要维护一个会被并发更新的准确的计数是不容易，很不容易，简单到文章阅读次数，评论次数，好友个数等等。因为没有条件更新和并发控制，你把值读出来，＋1再存回去，一并发就错了。

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

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

这两年来，随着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

另外，设定以下参数：

对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

随机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。之前已经说过，用记录级的缓存是很好的，我们

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

以后博客主要写技术类的，业界新闻、产品方面的就用微博了。网易微博和新浪微博同时用。

网易微博：http://t.163.com/wangyuanzju

新浪微博：http://t.sina.com.cn/breezes