IT牛人博客聚合

简介：IBM Research最近在Big Data领域有很多工作，例如我们组在4月份在10台采用POWER7处理器的P730服务器上成功地用14分钟跑完了1TB数据的排序，这项工作已经发表为一篇IBM Research Report，欢迎大家围观，并提出宝贵意见，谢谢。

The use of Big Data underpins critical activities in all sectors of our society. Achieving the full transformative potential of Big Data in this increasingly digital world requires b

查看全文: http://www.udpwork.com/item/7259.html

传统的软件设计方法论是不会关注调用者体验的——无论设计者是否有意忽略，往往结果都是这样。

这样说的原因是，“设计”本身的关注点在于“通用”和“可扩展”，而这些点和调用者体验本身就是矛盾的。

我来用一个简单有趣的例子来说明这个矛盾是如何产生的。

比如我们现在要抽象餐馆里顾客点餐的过程，一般的思路会是这样。

顾客实例化一个服务员实例

顾客从服务员实例获得菜单，开始选菜

顾客选好菜品之后调用服务员的点菜接口，下单

用C++表达会是这样，这里省略了很多无关紧要的细节：

class Menu {/*...*/};
class Dish {/*...*/};

class Waiter {
public:
static

查看全文: http://www.udpwork.com/item/7076.html

问题

最近我们在做一个项目的时候有这样一个需求：我们有多台服务器资源，希望彼此协作完成一项工作。这项工作可以被划分为N个小的模块，但由于这项工作会依赖于持续不断的输入(在线业务)，因此我们无法使用人工指定的方式将此工作分发到不同服务器进行。目前我们想到一个方法，将这项工作划分出的小模块放到一个稳定可靠的地方，例如mola存储系统，然后每台服务器去存储系统上取得一定数量的模块进行工作，完成后再将处理的结果输出到前述的存储系统上。这些小的模块虽然可以被不同的服务器运行，然后重复运行却是不可接受的(例如我们的计费日志，重复计费是绝对不允许的)。因此，当任意一台机器取得一些模块并准备运行时，一定要通知到其他所有机器：这些模块已经由我运行，

查看全文: http://www.udpwork.com/item/6367.html

Google文件系统（Google File System，GFS）是构建在廉价的服务器之上的大型分布式系统。它将服务器故障视为正常现象，通过软件的方式自动容错，在保证系统可靠性和可用性的同时，大大减少了系统的成本。

GFS是Google云存储的基石，其它存储系统，如Google Bigtable，Google Megastore，Google Percolator均直接或者间接地构建在GFS之上。另外，Google大规模批处理系统MapReduce也需要利用GFS作为海量数据的输入输出。

系统架构

GFS将整个系统的节点分为三种角色：GFS Master（总控服务器），GFS Chunkserver（数据块服务器，简称CS）

查看全文: http://www.udpwork.com/item/6047.html

之前在微博上调查过大家正在使用的分布式内存队列系统，反馈有Memcacheq, Fqueue, RabbitMQ , Beanstalkd以及linkedin的kafka。RabbitMQ使用比较广泛，Beanstalkd是后起之秀。Beanstalkd之于RabbitMQ，就好比Nginx之于Apache，Varnish之于Squid。后面在项目中使用Beanstalkd的过程中，更发现其简单、轻量级、高性能、易使用等特点，以及优先级、多队列、持久化、分布式容错、超时控制等特性。下面就简单介绍一下Beanstalkd，不足之处请大家指正。

——————

查看全文: http://www.udpwork.com/item/5887.html

跨机房问题一直都是一个老大难的问题，先看传统数据库的跨机房方案。

Master/Slave方案

这是最常用的方案，适用于大多数需求。Master将操作日志实时地发送到Slave，Slave当成Master的一个Hot Backup。Master宕机时，服务切换到Slave，需要修改客户端逻辑使得Master失效时自动寻找新的Master。

这个方案有一个问题就是数据库的Master和Slave一般不是强同步的，所以，切换到Slave后可能丢失宕机前的少量更新。如果将Master和Slave做成强同步的，即：所有的数据必须同时写成功Master和Slave才成功返回客户端，这样又带来了另外一个问题：Master和Slave中任何

查看全文: http://www.udpwork.com/item/5684.html

8月2日（下周二）内部分享的ppt，分为几个部分：

1, 单机存储引擎看SQL与NOSQL；

2, NOSQL从单机扩展到多机的关键点；

3, 从Megastore看SQL与NOSQL的融合；

4, 设计实现的一些Work around方法及技巧；

ppt比较简单，这几天将针对其中的”单机扩展到多机“问题写一篇博客。

“云存储系统”赏析系列分享三：Sql与nosql
View more presentations from knuthocean

查看全文: http://www.udpwork.com/item/5566.html

在今年的SIGMOD‘11上，Facebook又发了一篇新paper（点此下载），讲述了它们在提高Hadoop实时性上的工作及其应用。简单来讲，他们的项目需求主要有：

1. Elasticity（伸缩性）

2. High write throughput（高写吞吐量）

3. Efficient and low-latency strong consistency semantics within a data center（单个data center内高性能、低延迟的强一致性）

4. Efficient random reads from disk（disk的高性能随机读）

5. High Availability and

查看全文: http://www.udpwork.com/item/5486.html

我这里说的程序员搞投资，不是说投资自己的精力去写文档、写程序甚至做产品，而是投资Bitcoin。更理性点说，他们是在非理性的炒作Bitcoin。
是的，很多程序员都投资Bitcoin去了，生怕哪天世界是Bitcoin一统天下，自己也会像没有抢到地一样必须卑躬屈膝的向地产商们送钱一样。
他们靠在圈内的影响力以及诡辩能力，去说服自己和他人，去抢BTC。然而，事情并没有那么简单：
Bitcoin生产BTC的速度受时间限制，总量受控，永远也不会超过2100万个BTC，就意味着它稳定吗？不会通货膨胀就意味着它能够解决现有货币系统的缺陷吗？我今天买一个面包，要1BTC，每天可能就是0.00001个BTC了。我不知道这是膨胀还是紧缩，但我知道这个

查看全文: http://www.udpwork.com/item/5191.html

按：王旭（http://wangxu.me/blog, @gnawux）于2011年6月6日译自 ZooKeeper程序员指南 （http://zookeeper.apache.org/doc/r3.3.3/zookeeperProgrammers.html）的同名章节。似乎很少有文档提这个啊，我其实在看这个之前一直不明白这东东是怎么用的。

所有的Zookeeper读操作，包括getData()、getChildren()和exists()，都有一个开关，可以在操作的同时再设置一个watch。在ZooKeeper中，Watch是一个一次性触发器，会在被设置watch的数据发生变化的时候，发送给设置watch的客户端。watch的定

查看全文: http://www.udpwork.com/item/5188.html

Microsoft云存储服务分为两个部分，SQL Azure和Azure Storage。云存储系统的可扩展性和功能不可兼得，必须牺牲一定的关系数据库功能换取可扩展性。Microsoft实现云存储的思路有两种：

1, 做减法。SQL Azure直接在原有的SQL Server上引入分布式的因素，在满足一定可扩展性的前提下尽可能不牺牲原有的关系型数据库功能。SQL Azure的可扩展性是有限的，单个SQL Azure实例不允许超过50GB，这是因为SQL Azure不支持子表动态分裂，单个SQL Azure实例必须足够小从而可以被一个节点服务。具体信息可以参考我以前的一篇文章：Microsoft SQL Azure架构设计。

查看全文: http://www.udpwork.com/item/5001.html

我在数据库大会有一个报告：<<Oceanbase – 千亿级海量数据库>>，ppt已上传到Slideshare上。有一些同学问我，Oceanbase的创新点在哪里？

从大学的数据结构课程可以知道，数据量比较大时，有两种数据结构很常用：哈希表和B+树，分布式系统也是类似的。如下图：

Amazon的系统实现了一个分布式哈希表，而Google Bigtable, Yahoo PNUTS，Microsoft SQL Azure实现了一颗分布式B+树。分布式哈希表实现相对简单，但只支持随机读取；而分布式B+树支持范围查询，但实现比较复杂，主要有两个难点：

1, 状态数据的持久化和迁移。更新操作改变系统

查看全文: http://www.udpwork.com/item/4906.html

Amazon S3申请了一篇专利，名称为”Keymap Service Architecture for A Distributed Storage System“，而Amazon Simpledb的实现细节暂时没有公开。本文根据Dynamo论文，S3专利以及S3&Simpledb的对外API尝试推测这两个系统的内部实现。

对外API

1, S3：撇开S3系统中的Region, Bucket，用户权限管理等，和底层存储系统相关的API只有如下几种：

Put Object：将object加入到bucket中，即加入<bucket, name> => object 对；如果多个客户

查看全文: http://www.udpwork.com/item/4634.html

从09年第一次阅读Dynamo论文，到最近阅读Amazon S3的一篇专利，一路过来对论文的理解可以简单归结为两个字 – 纠结。第一次看到Amazon Dynamo论文，有一种眼前一亮的感觉，Dynamo通过巧妙地组合一些P2P技术在Amazon构建了一个工程上可行的系统，CAP，NWR, Vector Clock一时成为流行词，更为神奇的是，Dynamo号称能够让用户设置不同的NWR策略从而在CAP三者之间获得一个很好的权衡，鱼和熊掌亦可兼得。而Amazon S3系统的核心基本可以分为两个部分：Blob系统存储对象(Object) + 类似Dynamo的系统存放Keymap，即”Key => Obje

查看全文: http://www.udpwork.com/item/4571.html

RDBMS的优势在于功能，包括事务，强一致性，同时支持随机读和顺序扫描，索引。NOSQL系统的优势在于扩展性和性能。Google的经验告诉我们，系统设计的关键点还是在于可扩展性，依赖于底层GFS+Bigtable提供的无与伦比的可扩展性，Megastore能够在上层不断完善功能，兼具RDBMS和NOSQL系统的优点。

1, 兼顾随机读和顺序扫描。Bigtable底层的存储引擎为MemTable + SSTable构成的Merge-Dump存储引擎，SSTable设计成8K ~ 64K的块，块之间有序，随机读取型应用可以选择较小的块尺寸。和传统关系型数据库的B+树存储引擎不同的是，Merge-Dump存储引擎中的SSTable是只读

查看全文: http://www.udpwork.com/item/4511.html

最近CSDN头条有一篇介绍Google Megastore的文章，讲得挺好，本文主要针对Google Megastore的事务实现做一个更详细的探讨。Google Megastore的底层是GFS + Bigtable系统，GFS + Bigtable解决可扩展性问题，但提供的用户接口简单：读接口只提供Get随机读取和Scan连续扫描，写接口也只能够支持单行事务。Google Megastore构建在Bigtable系统之上，通过客户端封装复杂的特性，包括事务支持，基于Entity Group的数据模型，多机房同步等。Megastore的适用场景比较广泛，如社交类，邮箱，Google日历等。

Entity Group模型

互联网

查看全文: http://www.udpwork.com/item/4319.html