IT牛人博客聚合

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

NOSQL的资料很多，不过不成体系，让分布式系统开发工程师无所适从。笔者根据过去跟着阳老师开发类似Google GFS/MapReduce/Bigtable的系统以及对Dynamo, PNUTS等典型系统的理解尝试梳理流行的分布式存储和计算系统的分类，设计及实现。本文结构安排如下：

基础知识：一个大规模数据处理系统工程师必备的基础知识；

关键技术实现：工程实践中遇到的典型问题的解决思路；

通用存储系统分类：讲述笔者关于存储系统如何划分的个人观点；

典型存储系统工程实现：选取典型的存储系统讲述大致实现；

通用计算系统分类：讲述笔者对于计算系统如何划分的个人观点；

典型计算系统工程实现：讲述典型计算系统的大致实现；

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

By：Fenng posted @ dbanotes.net. RSS | Ad.Adobe Flash Builder 4 简体中文正式版下载

这两天看到消息，Dell 在对 3PAR 争夺战中退出，HP 宣布获胜。当然，代价也是不菲，总收购价格大约 20 亿美元。

3PAR 这家公司刚进入国内我就有所接触，因为该公司在美国有很多证券、金融行业的客户，加之我上一家雇主就是做这个方面的，所以我非常想了解并引入 3PAR 的一些成功的经验，并且研究了一下高端的几款产品特性（refer: 3PAR 存储架构解析 )，最后还吃了一下螃蟹，在 3PAR 上实现了一套 Oracle 11g RAC 集群。所以，我算得上国内少数真正用过 3

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

Cache和Buffer是两个不同的概念，简单的说，Cache是加速“读”，而buffer是缓冲“写”，前者解决读的问题，保存从磁盘上读出的数据，后者是解决写的问题，保存即将要写入到磁盘上的数据。在很多情况下，这两个名词并没有严格区分，常常把读写混合类型称为buffer cache，本文后续的论述中，统一称为cache。

Oracle中的log buffer是解决redo写入的问题，而data buffer cache则解决data block的读写问题。对于Oracle来说，如果IO没有在SGA中命中，都会发生物理IO，Oracle并不关心底层存储的类型，可能是一套存储系统，可能是本地磁盘，可能是RAID 10，也可能是RAID

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

Google存储: 它到底是什么

By Royans Tharakan Translated By Jametong

昨天Google在Google I/O上向我们中的部分人(5000个?) 宣布了Google Storage.下面是我从我参与的多个不同的讨论/讲座中看到的要点.

在开始之前,我要指出,Google打算提供的服务没有任何新意.Amazon一直在通过它的S3(Simple Storage Service)提供此项服务.关键的区别是,如果你是个Google的客户,你不再需要到其他地方去寻找与此类似的存储服务了.

下面就开始讨论技术细节吧:

它试图实现强一致性模型(CAP中的CA:一致性与可用性),这意味着你存储

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

Zoie是LinkedIn开源的基于lucene的实时检索系统，对于它的介绍及初步使用可参考我的上一篇文章“使用Zoie构建实时检索系统”。在初步研究并理解了Zoie的源码实现后，本文分析一下Zoie的实现。

实时检索的核心原理

通常的检索系统中，建索引和查询是分开的，即建索引是离线的，新的索引会以一定频率（比如每隔5分钟）供查询端使用。对于一些站内检索来说，这种延迟性使得：不需要建索引的速度足够快（只要能跟的上提交频率就行），查询的效果不必完全精确。而要取得实时检索效果，典型的思路是：建索引和查询是在一个进程内，这样每一次的添加索引都会被下一次的查询用到，但这里面的细节还是需要好好琢磨解决的，下面就给出Zoie的基于Lucen

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

很久没有更新，今天说些和分布式系统中的一些概念、理论相关的东西，切入点是CAP。

CAP

CAP理论是由Brewer远在2000年的PODC会议上提出来的。CAP指的是：Consistency、Availability和Partition Tolerance，下面简述此三者：

1、Consistency（一致性）：一致性是说数据的原子性，这种原子性在经典的数据库中是通过事务来保证的，当事务完成时，无论其是成功还是回滚，数据都会处于一致的状态。在分布式环境中，一致性是说多点的数据是否一致。

2、Availability（可用性）：可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果。而这种可用性

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

1、Beansdb是什么？

Beansdb是豆瓣荣誉出品的分布式key-value存储系统，该系统是对经典的Dynamo的简化。项目地址：http://code.google.com/p/beansdb/，其上的Inside BeansDB.pdf文档是对beansdb的很好的介绍。

Beansdb的CAP特点表现为：

1）分布式的，伸缩性比较好（P）

2）最终一致的(C)，可能出现短时间内的数据不一致。

3）高可用的(A)，部分节点出现故障不影响服务。

Beansdb在豆瓣内部有着广泛的使用，比如图片文件、小媒体文件、profile、properties等等。Beansdb不像GFS等分布式存储系统，一般不用于存储百兆

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