不使用SimpleDB的10个理由
Google订阅 | 鲜果榜 | Technorati | Delicious | Twitter | Taobao DBA | 招聘 | 合租 | 管理 | 阿里妈妈

不使用SimpleDB的10个理由

自从Amason推出SimpleDB,基于key-value键值对的分布式数据存储系统受到了广泛关注,类似的系统还有ApacheCouchDB,以及最近重磅推出的Google App Engine的基于BigTableDatastore API等,毫无疑问,分布式数据存储系统提供了更好的横向扩展能力,是未来的发展方向。但是现阶段,对比传统的RDBMS,也还有一定的差距和不足。Ryan Park撰文指出了SimpleDB的10大不足之处:

1.数据完整性无法保证

类似SimpleDB的分布式数据存储系统目前还无法实现和RDBMS一样严格的完整性约束,例如唯一性约束和外键约束等,所以数据的完整性需要在应用中来实现。

2.数据一致性无法保证,将导致非常糟糕的用户体验

SimpleDB做写入操作做了优化,调用API时只需要写入数据到一台SimpleDB服务器即返回写入成功的信息,随后数据会被分布复制到更多的SimpleDB服务器上,而在分布完成之前无法查询到最新的数据。所以需要在应用中来处理这种查询延时导致的数据一致性问题。

3.数据聚合将需要更多的额外编码实现

SimpleDB没有实现诸如join,group by,sum/average,sort等,这些操作都需要在应用中来实现。

4.复杂查询和即席查询更难实现

SQL标准已经出现很多年,数据库引擎对于一些复杂的SQL查询做了足够多的优化。SimpleDB对于过于复杂的查询和条件不定的Ad hoc查询没有提供特别的支持,所以SimpleDB还不太适合数据仓库等OLAP应用。

5.数据聚合操作性能比RDBMS差

RDBMS引擎对于join,group by等聚合操作做了很多优化,优化器可以提供根据不同的情况使用诸如hash join,nested loop join等方式来实现。自己在应用中实现这些操作可能效率会不如成熟的RDBMS。当然,这一点有些牵强,在应用中实现有可能更坏也有可能更好,从分布式趋势来看,数据库将倾向于做越来越简单的数据存储,计算更多的应该交给前面的应用服务器来完成。

6.数据的导入导出,备份等操作更慢更繁琐

RDBMS提供了很多成熟的数据迁移和备份工具,这一点刚刚出世的SimpleDB等自然有不足,但这不是问题,只要有需求和时间,就会有工具。

7.SimpleDB并没有想象中的快

Todd Hoff在一篇文章中的数据:从SimpleDB的1000条记录的表中读取10条记录需要141ms,从100000条记录中读取10条记录需要266ms,而从1000000记录中读取10条需要433ms,这比RDBMS明显要慢很多。当然,对于分布式系统,数据量越大才能体现出优势。在小数据量的情况下,集中式比分布式肯定更有优势。

8.RDBMS也可以良好的可扩展性

列举了一些RDBMS的成功应用案例,如Facebook和Livejournal使用MySQL,myspace使用MS SQL Server,Salesforge.com使用Oracle。通过良好的应用设计、数据的垂直分割和水平分割、主从复制和群集等技术,传统的RDBMS也能实现不错的可扩展性,支撑大型的网站系统毫无问题。

9.超级可扩展性是一种过度设计

技术应该以适用为原则,过度设计是一种巨大的浪费。

10.SimpleDB非常有用,但也要用在合适的场合

SimpleDB并不是为了替代OLTP数据库而生的,它的key-value存储结构更加适用于处理半结构化的数据。好的产品也要用的合适的地方才能扬长避短。

Google的高可扩展架构与海量数据处理

Google需要处理数据真正可以称得上海量,这依赖于其分布式的高扩展架构,否则,再强的小型机大型机也扛不住互联网每天产生的“信息垃圾”。Google的Jeff Dean同学为我们解密了Google的高可扩展性架构,ppt可以从这里下载。

一、底层架构

负载并行分配到多个硬件机器上
软件必须采用容错处理,不依赖具体的某一个台机器运行
大量采用刀片服务器和PC Server,低端存储和网络设备
机器追求性价比而不是盲目的高性能
基于Linux

二、分布式系统

调度系统:Scheduling System
调度系统是一个底层支撑系统,负责调度监控Cluster资源

文件存储:GFS
Master节点负责管理文件系统元数据
Chunkserver存放具体数据,以64MB为单元分布
客户端通过master查找文件
客户端直接从chunkserver获得需要的数据
目前运行超过200套GFS群集
超过5000台机器
超过5PB数据
为10000台以上客户端提供服务

数据存储:BigTable
采用多维稀疏映射图模型,每一个数据单元Cell可以存储不同时间截的数据
将表按行分隔成Tablet,分布到不同服务器上存储
底层存储架构采用GFS
Master节点处理元数据和负载均衡
Tablet服务器存储数据
锁服务器(Lock Service)控制数据访问的一致性
超过500个数据单元
最大的单元存储超过6000TB的数据,使用了超过3000台机器
最忙的单元支撑了500000次以上的操作

数据处理:MapReduce
MapRedule是Google的批量数据处理工具,分为两大功能

MapReduce用于Google的大多数产品中,包括Google Earth,News,Analytics,Search Quality,Indexing等等

目前,调度系统/GFS/BigTable/MapReduce可以在同一个群集内协同工作

三、未来的发展方向

跨越数据中心的分布式系统
更高的自动化程度

开源,是一种精神

毫无疑问,开源运动最初更多的是一种精神运动,虽然最终不可避免的被商业化。Sun显然没有真正的理解开源,甚至没能合格的利用开源。虽然Sun一直在抱怨说向开源社区贡献了最多的源代码却没有得到应用的尊重,虽然已经将压箱底的JavaSolaris都整成了OpenJavaOpenSolaris,但看起来这更多的是被逼无奈,而不是真心的拥抱开源。

现在Sun说要对MySQL选择性开源,一些企业级新特性的源代码将不再开放,患得患失的小家子气一下表露无遗。保留的这些代码未必能吸引更多的客户,却让原本对于Sun收购MySQL持观望态度的开源人士找到了攻击和离开的借口,如此费力不讨好的事情,Sun居然能堂而皇之的在The 2008 MySQL Conference & Expo期间干出来,真是脑子进水了。

开源是一种精神,半推半就是不能赢得人心的。

Alexa排名算法大幅度修改

家里的台式机上装了个alexa工具条,今天偶然发现blog的排名出现了大幅度的上升,于是进去看了下,发现alexa的排名算法做了比较大的修改。原来alexa的排名的主要数据来源是alexa工具条,这个东西,除了一些个人站长或者专门帮别人刷排名的,估计安装的不多,所以得到的数据的准确度是值得怀疑的。想想以前国内多少网站靠着这个排名作为拉到风险投资的救命稻草,原来不过是建在沙滩上的城堡而已。每一次alexa排名算法的变化,都是有人欢喜有人叫,呵呵。

现在还拿alexa说事的应该不多了,web2.0们都喜欢说自己有多少注册用户有多少用户生成的内容了,没了关注度的alexa做出了最大的一个改变,不再过于依赖工具条的数据了。从一开始知道alexa,就对他们依赖工具条的数据来做排名就觉得很疑惑,他们居然说In recent months才收到用户的抱怨,借口而已吧,真正的原因,是一直无法获得足够的数据呢?还是一直写不出算法?

When Alexa began displaying rankings in 1998 it was with the goal of showing Alexa Toolbar users how popular any given site was within the Alexa community. We generated the rankings through an analysis of Internet usage by people who use the Alexa Toolbar. Since that time we’ve been delighted to see that the Alexa Rankings have become a yardstick by which website popularity is measured. We are grateful to the thousands of people who come to Alexa.com each day to check the Alexa Rankings.

In recent months we’ve heard from our Alexa users that understanding Internet usage beyond Alexa Toolbar users was increasingly of interest. Ask and you shall receive!

We listened to your suggestions, and we believe that our new rankings system is much closer to what you asked for. We now aggregate data from multiple sources to give you a better indication of website popularity among the entire population of Internet users.