云计算中的存储

这是去年发在《程序员》杂志的一篇文章。当时写得比较急,现在看起来,有些观点有些武断。仅供参考。

引言, “The one that is without any tradeoff is to have the logical storage master up in the cloud” by Bill Gates.

2008 年的 IT 界,云计算是个热词。很多企业都在宣称自己提供云计算服务,很多人也都在讨论云计算(一些明显是凑热闹的,比如所谓的”云安全”),从业界公认的几种云计算的服务能力看,都绕不开存储这个基础支撑组件,dSaaS(data-Storage-as-a-Service) 更是把存储提到了首要的位置。而从我们目前能得到的信息来看,在存储层已经解决很好的,恐怕也只有 Google 和 Amazon 两家,至于其他公司可能都还在路上,即使是微软,尽管也有自己的 Dryad ,但是实际上,仍然处于理论阶段,产品化的路还有点距离。

Cloud_Computing_level.png

上面表格中的举例仅仅是为了举例,如果某家已经 “云计算了” 的公司大名不在上面,并非该公司”云”的不够彻底,应该只是笔者眼光差的原因而已。

越来越迫切的信息存储需求

根据 EMC 公司赞助 IDC 进行的研究计划 “Digital Universe” 的分析报告,在整个 2007 年,我们这个世界生成、占用的数字信息及复制总量大约是 281 Exabytes (1 Exabytes=1024 Petabytes ,1 Petabytes = 1024 TB 这里换算都按照二进制的换算),这个数据平摊到地球上的所有人,大约是每个人 45 GB的数据;截至到笔者写稿的时候,2008年到现在整个世界已经生成了大约 374 EB 的数据(可以到 “Digital Universe” 页面查看最新的数据,也可以下载一个评估工具,看看自己产生的数据是大约如何);到 2011 年,每年产生的数字信息大约是 1800 EB,10倍于2006 年产生的信息量。做为对比,Google 每天处理的数据大约是 20 PB 的样子,Google 的目标是要组织所有的信息,看来并非易事。

其他可参考数据:据美国国家档案馆工作人员估计,布什政府电子档案存储量大约为1亿GB,这一数字约为前总统克林顿两届政府档案总量的50倍,是国会图书馆2000万册编目图书内容总量的5倍。

每年激增如此庞大的信息量,加上已有的历史数据信息,对整个业界的数据存储、处理带来了很大的机遇与挑战。通过该研究能看出,在可用存储之间与信息生成总量之间不是严格匹配的,一方面多媒体领域信息增长过快,一方面因为不合理的存储分配、占用情形比比皆是。例如研究表明一封大约 1M 的邮件发出后,经过不同服务器的存储、备份、归档等最后总体占用空间竟然达到惊人的 50M 之多。正如云计算的初衷是为了充分发挥计算机闲置资源,提高总体使用率以便达到经济效益,云计算中的存储方面也应该能有效提高存储利用率而进一步创造价值,盲目的复制、堆积数据是没有出路的。工业界提倡节能减排,其实 IT 界应该提倡一下节约存储了。

什么是云存储 ?

其实,什么是云计算都很难有一个权威的定义,笔者在这里更愿意把”云计算中涉及的存储”简称为云存储(Cloud Storage)。云存储本身离不开云计算,更多的时候云存储是做为云计算的一个支撑组件。

云存储不是简单的在线存储或是网络硬盘,在线存储服务只是云存储能够提供的众多服务中的一种而已。

云存储的特点

云存储至少应该能够具备如下特点:

  • 高可靠性
  • 谈到存储,可靠性还是要排到第一位的。没有人喜欢买三天两头坏掉的硬盘,代表高科技形象的云存储可靠性也要加强。

  • 高可用性
  • 如果云存储服务不是针对在线用户的,那么没有什么实际意义,如果针对在线用户,不具备足够高的可用性也是没有意义的。Amazon 的 S3 服务给足够多的 Web 2.0 企业解放了在硬件存储上的压力,但是偶然的一次宕机会影响所有的 Web 2.0 用户;

  • 低成本
  • 云存储本质上还是规模化经济。如果成本不能有效的控制,那么云存储对厂家、对用户来说是没有意义的;

  • 高扩展性
  • 云存储组件应该具有足够高的扩展性,应该能够通过在线扩充存储单元进行有效的平滑线性扩展;

  • 自动容错能力
  • 因为低成本的,存储组件的损耗率应该很高,云存储厂商应该能在软件层做到自动容错而不是依赖硬件本身的容错;

  • 易管理性
  • 构建云存储系统,可管理性应该在设计之初就要考虑到,如果管理太复杂,很难做到低成本,稳定性、可靠性也会受到挑战。

  • 去中心化
  • 对元数据的管理不应该通过少数或者单一的管理节点来操作或者存储。

云存储的关键技术与服务形式

要建设成功的云存储系统,高扩展性、高可靠性的分布式文件系统是一个关键因素。而硬件问题反而是次要的。

cloud_storage.png

云存储的服务形式见上表。

未完待续…

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

关于 SSD 的闲言碎语

前不久写给《程序员》的一篇文章里,个人预测在 2009 年,SSD (Solid-State Drive,固态盘) 在企业级市场能大展拳脚。上周参加了 EMC 的一个会议,提及了 SSD ,EMC 存储产品对 SSD 的引入也有一年了,做点 SSD 的科普知识应该是有必要的。

Wear Leveling

很多人对 SSD 的误解是:既然你可擦写次数有限制,比如 200 万次,那么不是没几天不久坏掉了,怎么说使用寿命还比物理硬盘长呢?

Wear Leveling 是有效提升 SSD 的 MTBF (Mean Time Between Failures)的一种技术手段。我们都知道木桶原理,对 SSD 硬盘也是这样,如果不停的对某个 Cell 擦写,那肯定很快就报废。 Wear Leveling 的基本思想就是利用算法保持所有的可擦写单位的次数是近似均匀的,这样就把写次数均匀的分散到各个 Cell 上。

Wear Leveling 翻译似乎还没有统一,有翻做均匀磨损、磨损分级、换位写入等。

对 Wear Leveling 粗略一点的描述大致是:假设更新某个数据块,假定8KB ,而可擦写块(erase block)是 256 KB,那么定位到当前数据位置后,将找个没写过或者写过次数更少的可擦写数据块写入,并不是对原来的位置反复更新。Wear Leveling 算法的效率直接影响 SSD 的寿命。

而 8K 到 256 KB 这个过程实际上是加大了 I/O 操作,称之为 Write Amplification (写放大)。当然 SSD 厂家另有其他技术尽量减少写的频率。

为什么 SSD 写入速度相对较慢?

用一句话解释:擦写块(erase block)比较大。

很明显这样做的目的是减少擦写次数,提升 SSD 寿命。但也影响了数据写入速度。

为什么 SSD 容量是 2 的幂次? 比如 32GB,64GB

这个我也不甚了了,猜测是因为 erase block 多数是 2 的幂次的缘故。物理硬盘的尺寸由来我也不甚清楚。

SSD 的擦写次数是不是致命的瓶颈 ?

这个问题太容易给用户带来疑惑。个人认为要依赖应用的特点和设计。对于合适类型的数据,基本不是问题。但对于某些特定的数据类型,那可能是灾难(比如数据库的 Redo Log)。

SSD 会给数据库应用的银弹么?

是曙光,但不会是银弹。对于密集写入的数据库应用来说,SSD 可能不会带来更多的好处。但是对于密集读的应用,那是有可能带来数量级上的性能提升。在未来若干年内,好的数据库应用仍然严重依赖于设计人员的能力和数据库管理员的优化技巧。

此外,还要期待数据库厂商针对 SSD 进行软件级别的优化。

是否从现在选择 SSD ?

典型的废话答案应该是:这取决于你的具体情况。

要看性价比,EMC 最早引入的 SSD ,性能是普通硬盘的 30 倍,价格大约也是 30 倍。而现在,在企业级市场,SSD 已经降到大约 10 倍普通硬盘的价格。如果再低一些,那绝对是比较有吸引力的。

EOF

其中观点仅供参考。SSD 有风险,玩家谨慎操作。而这篇文章中的有些观念有实效性,细节也可能不够准确。

Note: 这里的 SSD ,是说面向企业应用而不是面向个人消费品的。

再增加一个图:
SSD vs. HDD.png

关于移动 Web 设计的闲言碎语

前几天 3G 牌照下来,一时间 Buzz 信息很多,不过关于 3G 对 Web 技术影响的分析倒是并不多见。今天再次读了一遍这篇 2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009),加上这几天在分析使用 iPhone 上的某些 App 设计,还是记录一点笔记吧。

这篇文章提到了如下五点:

  • 简单的可选项(Simple options) 如无必要,勿增实体。基本的、核心功能就行了。
  • 留白(White space) 我觉得 UCWeb 针对 iPhone 的设计就很一般,完全是把 iPhone 当成小屏幕显示器设计的。堆砌的网址站看起来不方便,点击起来并不方便,倒是应该弄个 LOGO 或许更好。
  • 少用图片(Lack of images) 这倒是和上一条矛盾。能少用就少用,而不是不用。而用了图片,如果方式不合适,还不如不用。
  • 用子域名而不是用 .mobi 域名(Sub-domains instead of .mobi or separate domains) 精简域名长度,精简!用 “i.” 就很好,别用 “mobile. “。
  • 内容优先(Prioritized content)
  • 只有设计是没有用的。

我的额外建议:

  • 可点击的目标锚点一定要大。因为你的手指肚更大 :) 如果一个手指尖范围内还有其它可点击目标,很容易误点。最简单的方式就是看看 iPhone 自己桌面菜单设计。而我之所以说 Taobao 商城 iPhone 版设计的不错,也是因为这一点考虑得很地道。Gmail for iPhone 的设计上,用户浏览邮件内容的时候,那个 “Inbox” 的按钮就设计的非常不好。很容易误点击到 “Archive” 按钮上。
  • 分页设计 对于分页的链接,一定要隔开一些,如果”上一页”、”下一页”挨在一起,用户会很困扰。毕竟,手持设备没有鼠标,用户不可能具备”精确点击”的能力。
  • 登录框设计 在 iPhone 上登录某些站点是非常痛苦的一件事情。可考虑的事情:如果用户 ID 是邮件地址的话,是否考虑无需用户输入”@” 字符? [iPhone 2.2 固件已经改进了许多]

另外,2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009) 还提到了设计中的常见挑战以及需要慎重考虑的地方,这篇文章信息量还是挺大的。

EOF

唠叨完了,发现基本上是针对 iPhone 说事儿的,我还不是标准的移动互联网用户。

此文作者:, 位于 Web 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Cookie, iframe 与 P3P 的那点事儿

且说我使用有些网络服务的时候常常能遇到比较怪异的问题。昨天在某个页面遇到个 Redirect Loop 错误提示:

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

同样的问题,同样的页面,同样是 Firefox 浏览器,以前就遇到过,提交给相关负责人之后没了响应,后来也忘掉了。同事说是我浏览器版本的问题,后来发现这和”是否接受第三方 Cookie” 的设置有关:

[x] Accept cookies from sites
[ ] Accept third-party cookies

我的浏览器不接受第三方 Cookie。设置接收后该页面显示正常。

搜索了一下,发现之所以该页面是这样,还是因为页面用了 iframe 而导致的问题,比较通用的办法是设置 p3p http header

这个 P3P(Platform for Privacy Preferences Project),要搞明白,可真是有点小孩没娘,说来话长。简单的说,就是个协议,通过其声明它是好人,允许我收集浏览器用户行为吧… 可现实中,大家都可以说自己是好人,背地里没准儿干啥坏事呢。这就是其分歧所在。[参考] 国内多数网站,都不关注这个 P3P。隐私问题可能没国外(微软的隐私声明)重视吧。

再说 Firefox ,过去的几个大版本中,对 Cookie 的处理方式还是有很大变化的。

这个问题影响最大的还是 Facebook 等开放平台的应用,使用了 iframe 就会遇到(eg: FriendFeed 遇到过,估计还比较头疼)。

对于浏览器来说,第三方 Cookie ,默认情况下,浏览器接受与否,是个大问题。如果不接受,会给很多用户带来混淆,如果接受,则在隐私问题上,有很大的挑战。

实际上,Firefox 的开发者在这个地方的处理方式也在摇摆当中(参见), 不过能确定的是 “the ability to make decisions based on p3p policies was removed for firefox 3″。

各家浏览器在这个地方都可能有 Bug。比如 IE7 曾经有的 Cookie 问题,IE8 Beta 也有类似问题

或许,最好的办法就是别去种这个 Cookie 了… 网站开发者,你们愿意么?

EOF

更多阅读:Windows Internet Explorer (Pre-Release Version 8) Privacy Statement
微软 Cookie 说明

另请参见文本后面 axis 同学的留言。