Tag Archives: Amazon

Amazon 的新服务:SimpleDB™

Amazon 真是酷到家了。在 S3EC2 之后又搞出来一个 SimpleDB™ 。Amazon 一手构造的计算环境中现在又加上了数据库,真是很有想象力的项目。

在 Web Service 上,Amazon 可以说是身体力行,领跑多年。S3 解决海量数据(非结构化)托管问题(虽然当下也是赔本赚吆喝),EC2 解决企业计算问题,SimpleDB™ 则针对结构化数据查询的解决方案,目前已经能够提供数据库的一些核心功能。对用户来说,你不再需要针对数据库的复杂的维护工作,也就是可以不用数据库管理员( DBA ) 了 。当然,DBA 也不用担心,这个工种不会消失,SimpleDB™ 针对的买方是那些只需用简单的关系型数据的 Web 项目,传统的 RDBMS 功能复杂,但是很多小项目其实只是用到一些核心的功能而已,如大家常说的增、删、改、查,这或许也是帕累托法则的运用吧。

RDBMS 当然不会消亡,SimpleDB™ 是 RDBMS 的竞争对手,也是 RDBMS 的一个补充(我非常奇怪为什么不叫做 WebDB,嘿)。从这一点上说,SimpleDB™ 还是开启了一片蓝海,只是海水比较深,没有足够技术船也过不去。

EOF

BTW: 虽然这个消息已经被很多人写了,我还是想写一下,毕竟这也是关于 DB 的事情

Updated: 小道消息,”SimpleDB stuff is Erlang on top BerkleyDB“,如果这么说,或许 Oracle 偷着乐呢

Amazon 的 Dynamo 架构

我在 DBAnotes.net 上记录过不少比较大的网站架构分析(eg: eBay [1], eBay [2]) ,Amazon 一直找不到太多的资料。国庆期间读到了一篇关于 Amazon Dynamo 的论文,非常精彩。Amazon Dynamo 这个高可用、可扩展存储体系支撑了Amazon 不少核心服务.

先看一个示意图:

Amazon_sosp.png

从上图可以看出,Amazon 的架构是完全的分布式,去中心化。存储层也做到了分布式。

Dynamo 概述

Dynamo 的可扩展性和可用性采用的都比较成熟的技术,数据分区并用改进的一致性哈希(consistent hashing)方式进行复制,利用数据对象的版本化实现一致性。复制时因为更新产生的一致性问题的维护采取类似 quorum 的机制以及去中心化的复制同步协议。 Dynamo 是完全去中心化的系统,人工管理工作很小。

强调一下 Dynamo 的”额外”特点:
1) 总是可写
2) 可以根据应用类型优化

关键词

Key: Key 唯一代表一个数据对象,对该数据对象的读写操通过 Key 来完成.
节点(node):通常是一台自带硬盘的主机。每个节点有三个 Java 写的组件:请求协调器(request coordination)、成员与失败检测、本地持久引擎(local persistence engine)
实例(instance);每个实例由一组节点组成,从应用的角度看,实例提供 IO 能力。一个实例上的节点可能位于不同的数据中心内, 这样一个数据中心出问题也不会导致数据丢失。

上面提到的本地持久引擎支持不同的存储引擎。Dynamo 上最主要的引擎是 Berkeley Database Transactional Data Store(存储处理数百K的对象更为适合),其他还有 BDB Java Edition、MySQL 以及 一致性内存 Cache 等等。

三个关键参数 (N,R,W)

第一个关键参数是 N,这个 N 指的是数据对象将被复制到 N 台主机上,N 在 Dynamo 实例级别配置,协调器将负责把数据复制到 N-1 个节点上。N 的典型值设置为 3.

复制中的一致性,采用类似于 Quorum 系统的一致性协议实现。这个协议有两个关键值:R 与 W。R 代表一次成功的读取操作中最小参与节点数量,W 代表一次成功的写操作中最小参与节点数量。R + W>N ,则会产生类似 quorum 的效果。该模型中的读(写)延迟由最慢的 R(W)复制决定,为得到比较小的延迟,R 和 W 有的时候的和又设置比 N 小。

(N,R,W) 的值典型设置为 (3, 2 ,2),兼顾性能与可用性。R 和 W 直接影响性能、扩展性、一致性,如果 W 设置 为 1,则一个实例中只要有一个节点可用,也不会影响写操作,如果 R 设置为 1 ,只要有一个节点可用,也不会影响读请求,R 和 W 值过小则影响一致性,过大也不好,这两个值要平衡。对于这套系统的典型的 SLA 要求 99.9% 的读写操作在 300ms 内完成。

–待续–

更多阅读:Dynamo学习 — http://donghao.org/2008/10/dynamoni.html

Web 2.0 站点扩展性问题随感

最新一期《程序员》杂志上有篇《Web 2.0 构建要素》的文章,里面描述了一些 Web 2.0 的扩展性问题,这可能也是 Web 2.0 站点从小到大必须承受的苦恼。该文简单介绍了有些站点通过 Amazon S3 服务来解决存储扩展带来的压力。有些站点则必须自己动手构建最适合自身业务的技术方案。
很多比较成功的站点,有的时候会透露出一些关于站点扩展性的技术信息,像我收集的 Flickr 的开发者的 Web 应用优化技巧Technorati 的后台数据库架构Craigslist 的数据库架构等,往往是蜻蜓点水,看过之后让人心痒难当,可是更细节的东西又很难获取。尽管这些站点基本都是构建在 OpenSource 软件上,但这一点上看,似乎不够 Open ,唯一一个做的比较好的倒是要算 LiveJournal ,他们通过 Danga 站点贡献了几个经典的软件与一些很有参考价值的文档(如这篇对LiveJournal扩展性的介绍),是为很多后起 Web 2.0 站点必备的参考信息。
在国内,很多 Web 2.0 站点也同样面临着这样的问题,象豆瓣阿北还需要身兼 DBA, 而抓虾,虽然数据库已经有上亿级别的记录量,就上次我在北京和谌振宇聊天,感觉抓虾在扩展性上也是还有很多细节需要完善,在杭州,Yupoo 也因为日益增长的数据量而不得不着手考虑如何更为成功的实现分布式存储解决方案……
这些似乎表明,Web 2.0 站点扩展性问题越来越突出,已经成为制约 Web 2.0 发展的一个障碍,”多、快、好、省”的构建新型互联网应用,不知道正在让多少人犯愁。
在传统互联网领域,很多技术解决方案往往是软硬件厂商提出来,类似自上而下的推动,而 Web 2.0 站点变化太快,到现在为止,似乎只有 MySQL 一家公司是比较大的赢家,可是因为面对的客户情况各异,解决方案似乎无从说起(比较简略的实现案例倒是能找到几个),再者,这些站点基本上是把 MySQL 这样的产品当作基本工具,和其他软硬件相互结合,然后在这个上面灵活构建出很多具有创新性的应用。这是一种自下而上的变化。
另一方便,Web 2.0 架构方面的人才还是稀缺,这个架构不是指某一方面(比如Java)的架构,而是整个产品环境的架构,象 Flickr 技术大牛 Cal Henderson 这样的人几乎是可遇不可求。操作系统、网络、数据库、开发语言每样都能那起来并且能够涉及足够灵活的技术方案,这要求,也的确高了一些。或许有人说,一个人不行,那么多几个人分别负责某几个环节不就成了? 这又带来另外一个问题:人力成本。
上一篇 Blog 我提到五月份的”侠客行“大会,我倒是希望能有一群网络技术人才能够就 “Web 站点可扩展性” 这个话题作一番探讨,每个站点如果都说说自己的心得,那么汇集在一起参考价值会对整个 Web 2.0 环境起到很大的促进作用。
最后,还拿 MySQL 说事儿,去年网志年会上,就有人感叹,国内 MySQL 好手太少了,考虑到物以稀为贵,有的 Oracle DBA 已经开始学习 MySQL 啦.
EOF

卓越(Joyo)与 Amazon 接轨后的’智能’

卓越网似乎是在国庆前夕进行的改版? 没看到改版说明在什么地方,总之界面和 Amazon 的风格终于一致了,访问速度也快了很多。
登录进去看看,在”个人信息”页面看到如下内容:
Joyo 改版后的一个小Bug
我的 ID 怎么成了”礼品卡”?
“报告长官,我的确不是礼品卡!”
看来是 Joyo 数据迁移过程中字段映射的问题,这个值应该显示账户 ID 才对,而”礼品卡”是账户的类型。(这个账户就是根据礼品卡带的 ID 创建的)
虽然最后找到了地方修改了自己的 称呼, 但是第一次看到系统把我叫做”礼品卡”,还是觉得怪怪的,影响了用户体验。
EOF
Updated: 发现 Joyo 的 UI 有一处小 Bug , 左边栏”商品分类”的类别,最后一个的后面怎么还有个竖线呢?