银河里的星星
from：http://www.programmer.com.cn/4014/
文/何伟平
在2010年1月的ACM上，有两篇文章非常吸引人注意。一篇文章是Google的Jeffrey Dean、Sanjay Ghemawat发表的标题为《MapReduce:一个灵活的数据库处理工具》，另一篇文章是Michael Stonebraker、Daniel Abadi、David J. DeWitt、Sam Madden、Erik Paulson、Andrew Pavlo、Alexander、Rasin等人发表的《MapReduce和并行数据库：是朋友还是敌人？》。这两篇文章让我想起去年初Michael Stonebraker等人就MapReduce发表的一些评论而导致了一次MapReduce和数据库系统的大辩论。那篇文章的标题是《MapReduce：一个巨大的倒退》。这次辩论双方则准备了丰富的实践和实验案例。看上去更加有趣也更加有说服力。
from：http://timyang.net/architecture/yahoo-pnuts/
在分布式领域有个CAP理论(Brewer’s CAP Theorem) ，是说Consistency(一致性), Availability(可用性), Partition tolerance(分布) 三部分在系统实现只可同时满足二点，没法三者兼顾。所以架构设计师不要把精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍，选取最适合应用需求的其中之二。比如MySQL 5.1 cluster设计前显然不知道有CAP理论这样的经验, 所以MySQL cluster表面看来尽管可提供所有分布式特性，但实际大部分场合都无法提供稳定可靠的服务。
英文原文：http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/
zz from：http://blog.nosqlfan.com/html/1451.html
注：随着Hadoop的流行，其局限性也在一定程度体现，各大公司也在hadoop上做了很多修改，下面是雅虎对Hadoop下一代的重构计划。原文地址：http://sandaobusi.javaeye.com/blog/941740
zz from：http://www.dbthink.com/?p=483
本文是Ebay的架构师在2008年发表给ACM的文章,是一篇解释BASE原则,或者说最终一致性的经典文章. 文中Dan讨论了BASE与ACID原则的基本差异, 以及如何设计大型网站以满足不断增长的可伸缩性需求,期间如何对业务做调整与折衷. 以及一些具体的折衷技术的介绍.
zz from：http://blog.sciencenet.cn/home.php?mod=space&uid=449420&do=blog&id=444736
Jason Baker, Chris Bond, James C. Corbett, JJ Furman, Andrey Khorlin, James Larson,
Jean Michel L′eon, Yawei Li, Alexander Lloyd, Vadim Yushprakh
Google, Inc.
简述 Megastore是一个存储系统，应对目前的交互在线服务之需求。Megastore以一种全新的方式混合了NoSQL数据存储的可伸缩性以及传统关系型数据库管理系统RDBMS的易用性，并同时提供了强一致性保护以及高可用性。 我们提供了完全序列化的ACID语法以及细致分区了的数据。该分区允许我们在遍布广域网的范围内，同步的复制每个写，以一个合理的延迟进行工作，并支持数据中心的无缝的故障恢复（failover），本文献描述了Megastore的语法以及复制算法。同样描述了我们Megastore构建的在支持广大范围内支持的系列谷歌服务产品时的经验。
分类和主题描述
C.2.4【分布式系统】：分布式数据库；
H.2.4【数据库管理】：系统|并行，分布式数据库
常用字 算法， 设计， 性能， 可靠性
关键字 大型数据库， 分布式事务处理， BigTable, Paxos
1. 介绍
交互式在线服务使得存储社区遇到新需求，就像桌面应用程序迁移到云所需面对的一样。诸如email这样的服务， 协同文档，以及社会网络以指数形式增长，并对现存的架构极限进行测试中。面对这些服务存储是具有挑战性的，这是由于一系列的相互矛盾的需求。 首先，因特网带来了巨大的潜在受众，所以应用就必须是高可扩展的。一个可以用MySQL 进行快速构建的服务可以是一个数据存储【参见：www.mysql.com】，但是将这个服务扩展到百万用户就需要对其存储架构作一个完全的重新设计。其次，服务必须为用户而竞争。这需要快速的开发的特性以及快速的投入市场所需的时间。第三，服务必须是响应的；即是说，存储系统必须有低延迟特性。第四点，服务必须提供给用户以一致的观点看待数据，更新的结果必须立即可视以及持久的保存。看到编辑一个云端电子表格软件消失，无论该表格如何简要，都是很差的用户体验。最后，用户期望英特网服务是24乘7小时的， 故服务必须保持高可靠性。系统对各种故障（faults）还必须对“从个别磁盘，机器失败到从路由起一直影响到整个数据中心的大规模运行中断的出错范围”保持透明（be resilient to）。 这些需求是向矛盾的。关系型数据库就用于构建应用，提供了一个功能的富集，但是关系型数据库却难于扩展到数亿的（hundreds of millions ）用户。诸如谷歌BigTable【参见：Bigtable: 就结构化数据的分布式存储系统】，Apache hadoop的 Hbase【参见：hbase.apache.org】，或Facebook的Cassandra【参见：incubator.apache.org/cassandra】一类的NoSQL 数据存储是高可扩展的，但其受限的API以及松一致性模型（loose consis-tency models ）使得应用开发变得复杂化了。由于为了确保就复制数据的一致性视图，特别是在故障发生期间，故而在远距离数据中心间复制数据的同时提供低延迟性是一个挑战。 Megastore 是一个存储系统，其开发适合了现今交互式在线服务的需求。Megastore 设计方式是全新的，由于其融合了NoSQL 数据存储的可扩展性以及传统RDBMS的易用性。它用同步重复来达到高可用性以及对数据的一致视图。简言之，它对“有足够低下延迟性的远距离复制”提供了一个完全序列化的ACID语法以支持交互应用。 我们通过RDBMS以及NoSQL的折衷，进行设计以达致前述需求：我们对数据存储进行分区并且各自复制了其分区，就分区提供了完全的ACID语法，但在其上仅有受限的一致性保证（limited consistency guarantees）。我们提供了传统的数据库特性，诸如二级索引(译注：参见扩展存储引擎)，但仅仅有那些“可以在用户可以忍受范围内的，并在延迟性限制内的”特性，并且仅支持我们的分区模式可以支持的语法。我们主张从大多数因特网服务而来的数据可以被适当的分区（诸如，用户），从而使该种方法可行，并且一个小的，但是并不简短精炼的特性集可以极大的减缓开发云应用的负担。
与传统智慧形成一个对照的是品【参见：分布式事物处理之外的生活：一个特例独行的观点，垂直 paxos 以及 主要备份复制】，我们可以使用Paxos 【参见：兼职的议会】来构建一高可用性系统，该系统就“地理分布远距离数据中心的同步复制写交互应用”提供了可信的潜在因素。虽然许多系统使用Paxos仅仅用于锁，主线程选择（master election），或者元数据复制以及配置（Congurations），我们相信Megastore 是用Paxos 的最大系统部署，在数据中心之间的每次写时复制主用户数据。Megastore 在谷歌中已近广泛的应用了数年【 参见20 】。它控制了多于30亿写以及200亿的每日读事务以及在全球数据中心上存储了大约拍字节的主数据（primary data）。
该文献的核心贡献是以下三点：
数据模型的设计，以及允许进行快速开发的、“从构建开始就具有高可用性与扩展性的”交互应用的存储系统；
Paxos 复制的实现以及就地理分布的数据中心低延迟性操作之一致算法优化，从而对系统提供高可用性；
就我们在谷歌内大规模部署Megastore 的经验给出的报告。
该文献以下述形式组织。第二节描述了Megastore 如何通过“使用分区和证明我们对许多网络交互应用的设计之充分性”来提供可用性以及扩展性。第三节提供了一个Megastore的数据模型以及特性的全局概览。第四节详细解释了复制算法，并就它们实际执行性能如何给出测量方式。第五节总结了我们开发该系统的经验。在第六节我们将回顾相关的工作。第七节进行总结。
2.面向可用性及扩展性 （TOWARD AVAILABILITY AND SCALE）
和我们需要的存储系统平台的全局性，可靠性以及规模上任意大的特性形成对比的是，我们的硬件构建块缺失地理意义上受限制的，易于出错的，且必然是能力受限的。我们必须将这些组件绑定到一个统一的全体，该全体提供将提供更高的吞吐量以及可靠性。
为了做到这一点，我们采取了双管齐下的方法（two-pronged approach）：
就可用性（availability），我们实现了一同步的，容错的“就远距离连接进行优化了的”日志复制器；
就规模（scale）而言，我们将数据分区到有巨大空间的小数据库集之中（a vast space of small databases），其中每个都有自己的复制日志存储于NoSQL数据存储的每一复制（each with its own replicated log stored in a per-replica NoSQL datastore）。
2.1 复制（Replication）
在单一数据中心的诸多主机上的复制数据通过“克服特定主机失败（host-specic failures）”提升了可用性，但这种提升效果却是递减的（but with diminishing returns）。我们仍旧必须面对外部世界互联的网络以及其驱动，把控网络的基础设施架构（infrastructure）。很节俭的构建出来的站点冒着一定级别的广泛设施中断供应（facility-wide outages ）的危险【参见：数据中心作为计算机： 数据仓库级别的机器之设计介绍】，并在地域性灾难面前是脆弱不堪的。就云存储而言，为了达致可用性要求，服务提供商必须在全球地理范围内复制数据。
2.1.1 策略（Strategies）
我们就大范围复制对通用策略进行了评估：
异步主从（Asynchronous Master/Slave） 主节点复制预写式（write-ahead）日志条目到至少一个从节点（slave）。附加日志在并行传输到从节点的主节点是被确认的。主节点可以支持快速的ACID事务，但却要在从节点的故障切换时（failover）冒时间下降或数据丢失的风险。从而需要一个一致性协议在主机间进行协调（A consensus protocol is required to mediate mastership）。
同步主从（Synchronous Master/Slave）一个主节点将在应答从节点前等待，直至改变被反映到从节点中，从而允许无数据丢失的故障恢复。主节点和从节点失效需要外部系统及时的侦测到。
优化复制（Optimistic Replication）一均匀复制组的任何成员可以接受变异（mutations）【参见：23】，且在组内以异步方式进行传播。可用性和延时性（latency）是极好的。然而，全局突变排序（the global mutation ordering）在commit时的时间是不可知的，故事务（transactions）是不可能的。
我们避免这种“在宕机时会引起数据丢失的”策略，大规模系统通常有该缺陷。我们同样还丢弃了不许可ACID原子事务操作的策略。尽管对最终一致性系统（eventually consistent systems）有操作优势，目前在快速应用开发中放弃“读-修改-写”这种特色，还是太困难。我们同样丢弃了重量级主机（heavyweight master）的操作。故障恢复需要的一系列高延迟性阶段（high-latency stages）,常常会导致用户可见的中断供应（outage），并还常伴随巨大数量的复杂性。如果我们可以在所有主机（masters）间进行区分，那又何必将容错系统构建为仲裁成员以及故障切换工作流呢？
2.1.2 进入Paxos（Enter Paxos）
我们决定使用Paxos， 其是一个经过证明了，并优化了的，容错的，无需区分主机的一致性算法【参见:工程师视角的Paxos构造，兼职的议会】。我们在一组对称的对等节点上复制了预写式日志。任何节点可以初始化读以及写。各日志附加了一个从主要复制（a majority of replicas）而来的应答块，且该复制在少数情况下会被缠住（in the minority catch up），就好象它们能使算法的内在容错性质排除对显著的宕机状态（“failed” state）的需要。一个就Paxos的新特性，将详细在4.4.1节中描述，允许在任何实时复制时进行本地复制。另一个扩展允许允许单程写（single-roundtrip writes ）。
即便Paxos拥有容错能力， 但使用单一日志仍然是有限制的。将备份遍布在广域范围内（With replicas spread over a wide are），通讯延迟性将限制总体上的吞吐量（communication latencies limit overall throughput），而且，当目前没有备份或者对写的应答的主要失效时（majority fail to acknowledge writes），前进的步伐被限制住了。在传统的把控成千上万用户的SQL数据库主机上，使用一个异步的复制日志（a synchronously replicated log）会冒大范围中断影响的风险【参见：大范围同步复制数据库的性能】。所以为了提升可用性以及吞吐量，我们使用多复制日志（multiple replicated logs），其中每一个都把控“数据集中自己的分区”。
zz from：http://bbs.sciencenet.cn/home.php?mod=space&uid=449420&do=blog&id=480749
【原题】Dynamo: Amazon’s Highly Available Key-value Store
【译文】发电机：亚马逊的高可用键值对存储
Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati,
zz from：http://www.dbthink.com/?p=372
By Avinash Lakshman Facebook ,Prashant Malik Facebook; Translated By Jametong
本文翻译自Facebook员工在LADIS大会上发布的论文.Cassandra – A Decentralized Structured Storage System
这篇论文中,两位作者详细介绍了Cassandra的系统架构,它的设计初衷,设计应用时使用到的相关技术,以及设计/实现/使用过程中得到的经验教训.
看多了正面文章，今天看一篇负面批评吧，在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进行重构。
你好。 
其实到现在为止距离淘宝双十一事件已经过去蛮多天了，但在整个技术圈里面大家还是津津乐道。我这次在采访之前在和一些网友做沟通的时候，他们也提出了非常多非常有意思的问题，包括一些高并发的，一些压力测试的等等，那我希望也代表这些网友和你做一个交流。那第一个问题就是，在那么大的访问量，淘宝的技术团队是如何做到一个高并发处理的？ 
继成功举办首期TUP活动后，日前在北京丽亭华苑酒店鸿运二厅，由CSDN和《程序员》杂志联合策划组织的TUP第二次活动如期而至，本次活动以Web 2.0技术为主题，聚焦当下火热的社交网、微博架构与实时搜索领域。就相关领域及产品研发背后的技术、产品设计及用户体验话题为与会者提供全开放式的交流平台。即使是付费沙龙，参会报名人数仍在不断上升，本次活动有超过300人来到现场。
from:http://tech.sina.com.cn/i/2010-11-16/17574872122.shtml
新浪科技讯 11月16日下午消息，由新浪微博(http://t.sina.com.cn)主办的中国首届微博开发者大会在北京举行，这是国内微博行业的首场技术盛宴。作为国内微博市场的绝对领军者，新浪微博将在此次大会上公布一系列针对开发者的扶持政策，以期与第三方开发者联手推动微博行业的整体发展。图为微博平台首席架构师杨卫华演讲。
云计算平台是非常巨大的分布式系统，需要处理庞大的处理请求，因此任何小概率事件在此平台中都必然发生。
DBMS强调ACID：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性 (Durability)。其中的一致性强调当程序员定义的事务完成时，数据库处于一致的状态，如对于转帐来说，事务完成时必须是A少了多少钱B就多了多少钱。而对于很多互联网应用来说，对于一致性和隔离性的要求可以降低，而可用性(Availability)的要求则更为明显。从而产生了两种弱一致性的理论：BASE和CAP。
数据收集和存储的速度正在惊人地发展，对Google而言，数以万计的服务器中存储的PB级数据，以及每天在服务器中处理的数以亿计的图片文件，都对其未来的系统架构提出了新的挑战。重新设计系统架构以此优化搜索引擎的增量处理能力已是Google当务之急。
from: http://www.cloudera.com/blog/2008/12/whats-new-in-hadoop-core-019/
What’s New in Hadoop Core 0.19
by Tom White
December 31, 2008
1 comment
Tweet
The first release (0.19.0) from the 0.19 branch of Hadoop Core was made on November 24. Many changes go into a release like this, and it can be difficult to get a feel for the more significant ones, even with the detailed Jira log, change log, and release notes. (There’s also JDiff documentation, which is a great way to see how the public API changed, via a JavaDoc-like interface.) This post gives a high-level feel for what’s new.
有的时候，或许流浪已经成为一种习惯，正如有的时候，或许痴情也只是一种习惯。不同的只是，人们把后者称为一种美德，而视前者为乖僻。
我父亲是一个狂热的美德爱好者，为了让他允许我保留乖僻的流浪习惯，我只好让他相信我的习惯其实是痴情的美德。我的父亲，人们叫他大侠郭靖。
GFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，但可以提供容错功能。它可以给大量的用户提供总体性能较高的服务。
出处：http://labs.google.com/papers/gfs.html
Google’s BigTable 原理 （翻译）
题记：google 的成功除了一个个出色的创意外，还因为有 Jeff Dean 这样的软件架构天才。
—— 编者
官方的 Google Reader blog 中有对BigTable 的解释。这是Google 内部开发的一个用来处理大数据量的系统。这种系统适合处理半结构化的数据比如 RSS 数据源。 以下发言 是 Andrew Hitchcock 在 2005 年10月18号 基于： Google 的工程师 Jeff Dean 在华盛顿大学的一次谈话 (Creative Commons License).