Entries tagged with “Storage” from DBA notes

此为《程序员》杂志投稿。应该刊登在 2009 年第二期。

"预测"不是件容易的事儿，"回顾"就好操作的多。2008 年发生了很多大事，相比之下，数据库技术领域的这些事儿多少有些微不足道。

0) Sun 收购 MySQL

2008 年初第一笔业界大并购，在上一波.com 大潮中 Sun 赚得盆满钵满，在这一波 Web 2.0 大潮中，Sun 还要做 Web 2.0 中的这个"点"(Dot)? 我个人对此并不看好。

这是今年数据库领域的最大的事件，但也仅此而已，一年下来，MySQL 联合创始人 David Axmark 都因为"痛恨每天都要遵守的各种制度"从而离开了 Sun ，而到目前为止也没看到 Sun 针对 MySQL有什么新东西拿出来，倒是狂推预装了各项软件的硬件盒子。前不久发布的 MySQL 5.1 GA 质量更无法让人满意，很多 MySQL 旧将纷纷抱怨，连著名的 MySQL Performance Blog 也不失时机的抛出"MySQL 质量将不再如昔"的论断，大浇冷水。

1) Amazon 推出 SimpleDB

云计算喊了一整年， Amazon 也没闲着，不停地推出新服务。SimpleDB 服务让Jeff Bezos 把手伸向数据库服务，现在仍看不到该服务有大行其道的趋势，但是"提供数据索引与查询的核心数据库功能的 Web 服务" 无疑会逐渐吸引更多潜在的用户。到了年底，Amazon 干脆打出了在一段时间内 SimpleDB 免费的服务来招徕用户，用心良苦。

最近若干分析家下了论断 "未来网络产业将仅剩亚马逊与 Google 两强相争"，的确，Amazon 的技术实力不容小视，在 2009 年相信有更多精彩。

2) 主流存储厂商试水 SSD

让人没料到的是 EMC 作为业界存储领头羊，会率先推出支持 固态硬盘(Solid-State Drives, SSD) 的存储设备，Sun 、HP 等厂商也都不甘落后，纷纷宣布将拥抱 SSD。确实，SSD 的某些特性表现是如此抢眼，很多 DBA 都等着它来解决或者缓解 I/O 问题呢，毕竟这是近年来能看到的最大的硬件领域的突破。"钱能解决的问题就不是技术问题"，可惜，目前光有钱，买回来的 SSD 可能还是解决不了问题。SSD 的可擦写次数问题仍然让很多用户心下狐疑。

相信2009 年会是 SSD 爆发的一年，主流存储厂商都会纷纷推出支持 SSD 的产品。假以时日，SSD 应该不负众望。

3) Oracle 联手 HP 进军硬件领域

今年 Oracle 整体在 DB 方面实在没什么亮点，如果非要说有，那么在 Open World 上亮相的 Exadata Storage Server 倒是值得一提。

微软和 IBM 这一年来尽管都有升级产品推出，但实际上也就是升级产品推出而已，仍看不出什么新生机。其实很多用户已经非常厌倦不停地增加新功能的软件新版本，每发布一个版本不失时机的宣布打破什么 TPC-C 记录之类的事情已经难以引起用户兴奋。如何在廉价硬件上实现大规模平滑扩展是所有的数据库厂商必须要面对的问题。

4）面向列存储的数据库技术

面向列的数据库(Column-Oriented Database)这不是什么新技术，但是非常适合某些数据分析或者统计类的应用需求。常见的RDBMS 都是面向行（Row-Oriented Database）存储的，在对某一列汇总计算的时候几乎不可避免的要进行额外的 I/O 寻址扫描，而面向列存储的DB 能够连续进行 I/O 操作，减少了 I/O 开销，从而达到数量级上的性能提升。

其实在 Google BigTable / Hadoop HBase 中很早就看到这一思想的运用，在过去这一年中，列存储数据库也更多的引起了重视。

5) GreenPlum= MapReduce + SQL

MapReduce ，让很多面向数据分析的 DBA 还是挺眼馋的，GreenPlum 的出现把 MapReduce 和 SQL 有机的衔接起来，给海量数据分析能力带来了新的可能。年末的时候， GreenPlum 又宣布进军中国市场，不知道用户实际接受程度如何。

顺便说一下，GreenPlum 背后的大东家是 Sun。

6) 从 Drizzle 到 Percona XtraDB 存储引擎

MySQL 的生命力不在大公司手中，而是来自开源技术、Web 2.0 网站的需求上。Drizzle 这个"精简 MySQL" 版本的出现多少证明了这一点。Percona XtraDB 存储引擎的推出也值得 MySQL DBA 惊喜。

除此之外，DRBD、MySQL Proxy 与 Memcached 等 MySQL 相关组件的灵活搭配与定制，给用户解决超大规模应用上带来了更大的可能。数据库市场不可能不受经济危机的影响，商业数据库厂商日子要吃紧是可以想见的事情。

7）Hadoop 的生命力

Yahoo! 公司在 2008 年表现不佳，但是 Yahoo! 支持的 Hadoop 项目可是左右逢源，再一次让我们认识到开放带来的生命力。Facebook、Amazon、AOL、阿里巴巴等公司（当然也包括 Yahoo!）都在纷纷构建 Hadoop 集群来解决大规模数据处理与分析问题!。期待在 2009 年 Doug Cutting，这位 Hadoop 项目的带头人不要被 Google 挖角。

N）2009 年会怎么样? 谁知道呢。

--EOF--

后记：这算是 2008 年末的时候数据库技术小观察吧。因为投稿的缘故，现在才发出来。在过去这短时间里，自己一些观点可能也有所变化。如有时间，再做补充或者修订。请注意该文的时效性。

补充：对于 SSD，最近一件重要的事件是 Steve Wozniak 加入了 SSD 厂商 Fusion-IO

接上一篇。这其实是一篇综述文章 :)

是否该建设云存储服务?

可能有些企业已经在战略中加上了云计算这个关键字，问题是，真的需要那么多云计算么? 如果在技术上、规模化不能有效的节约成本，那么跟风建设云存储服务是缘木求鱼。更多的企业是自身的存储建设都远远不到位，大谈云存储无疑是痴人说梦。至少在国内，我们的基础建设还和国外有一段距离，而内容审查与一些政策上的限制又会增加建设、运营成本。

是否该使用云存储服务?

回答这个问题之前，我建议先看看服务提供方是否真的是云存储服务，如果只是炒炒概念，用老的架构支撑，换汤不换药，那还是谨慎为妙。企业如果不能从技术上做些本质突破而节约成本，那么成本肯定要转嫁到消费者身上，如果消费者不买单，那该服务如何能长久? 和我们现实生活中很多山寨 IDC 类比一下就知道了，动辄听到某主机托管商一夜之间蒸发，用户欲哭无泪的事情。

如果使用云存储服务，不妨和竞争对手使用同一家服务商。出问题的时候大家都出问题，保证始终处于同一起跑线。

在国内，短期内还看不到有规模的云存储服务商。由于网络的问题，企业用户也不太可能去使用国外的服务（不排除将来 Amazon S3 这样的服务能在国内提供服务）。期待在未来的一段时间能看到一些变化，但这恐怕只是乐观的想法。

云存储的潜在问题

• 数据安全
同样是数据存储到云存储服务商那里，如果我的隐私数据被泄露了怎么办? 业务数据被竞争对手盗用了怎么办? 消除用户的顾虑仍然需要时间。
• 网络带宽问题
只有数据没有网络，好比鱼儿没有水。如何保证大规模数据的有效分发与负载均衡，这也是云计算提供方与使用方都需要考虑的问题。
• SLA 的问题
对于提供云计算存储服务的公司，用户很难看到他们严格执行SLA (Service level agreement) 。遇到大规模故障的时候，还做不到有效的为所有用户提供服务支持的能力。

云存储的钱途与前途

时值全球经济的寒冬，能够为用户省钱的服务相信也应该能够赚到钱。从用户的角度上看，云存储解放了自身的生产力，能够允许中小创业团队集中精力做发展业务，只要不形成恶性竞争，应该不用担心盈利的问题。

就以 Amazon的 S3 来说，基本上也很好的展示并实践了 Web 2.0 长尾理论：利用企业建设剩余的存储以及网络带宽能力而为广大中小网站提供服务，前途大好。相信 Google 推出类似服务也是指日可待的事情。但这个市场内应该不会出现过多的有力竞争者，有些存储厂商(比如 EMC) 也在进入这个领域，数据存储不是问题，但网络能力可不是那么好解决的事情。

云存储与传统存储：SAN 能否还能发挥余热?

从我们前面提到的云计算中的存储特点来看，SAN(存储区域网络)产品就暴露出一些不适合的应用场景，毕竟 SAN 是面向集中式计算的架构。另外，大家也都知道 SAN 产品一般不便宜(现在也有厂商在力推低端海量存储产品，后面会介绍)，而且，主机端如果用 HBA 卡，也会进一步提高成本；SAN 面向传统企业应用而设计的扩展能力难以满足云计算的需求。

目前尽管已经有一些企业在做集群存储然后打包出售，但相对还是在起步阶段。至少现在还看不到真正集群 SAN 产品的出现。当然，如果对云计算的存储部分不计成本的话，SAN 仍然可以在云计算中发挥一些作用，这倒是中了存储厂商的下怀。

不管怎么说，RAID 这个 SAN 中的概念在云存储中已经绝对不适合了。

集群 NAS 是否真的有机会 ?

有业界评论说集群 NAS 可能会演变成云存储的通用架构，我怀疑这是不是 Sun 公司的宣传手段，因为这事实上宣布了 ZFS 将是云存储中的一个关键点。

从现有的情形看，或许会有越来越多的在线存储服务拥抱集群 NAS 。但这不代表集群 NAS 前途光明能够在云存储大展拳脚。集群 NAS 最大的问题是海量数据的寻址是个麻烦事儿，然后是扩展性与容错性的问题，底层的容错性如果通过硬件来做，那么成本无疑会上升，这恐怕是企业不愿意接受的。

分布式文件系统

在开源领域，以 MogileFS 为代表的分布式文件系统能够用于一些相对规模较小的分布式存储场景，很多 Web 2.0 自己的分布式存储就是借鉴 MogileFS 搭建的，不过毕竟 MofileFS 的Meta 信息仍是集中存储、管理的，在更大规模恐怕有些吃力。

此外，Kosmosfs（http://kosmosfs.sourceforge.net/）、Lustre(http://www.lustre.org) 等也都在不断发展中，相信能够给有兴趣研究云存储的技术人员一些借鉴。也有一些软件厂商将其专有的分布式文件系统和存储打包在一起销售，而存储厂商也有的在结合自己的存储产品做一些尝试。目前还很少有相对成熟度的东西进入用户视野。

更多分布式文件系统列表参见维基百科的文件系统列表介绍。

分布式文件系统举例：拥抱开源 Hadoop 的 HDFS

尽管我们接触不到 Google 大名鼎鼎的 GFS （Google File System），但我们能免费获取 Hadoop 的 HDFS (Hadoop Distributed File System)。HDFS 相对上述的 ZFS 来说，属于专门针对廉价硬件设计的分布式文件系统，在软件层内置数据容错能力。Hadoop 目前的案例多数用在数据分析与并行计算上，倒是很少看到有支撑给互联网应用的数据服务，但相信随着其在开放环境中的快速成长， Hadoop 将不断壮大。

（HDFS 架构示意图. from: http://hadoop.apache.org/core/docs/current/hdfs_design.html 关于 Hadoop 也请参阅《程序员》杂志 2008年10月刊的文章。）

速成版存储方案成本评估

云计算中存储的起步容量，我们不妨按照 1PB 可用空间来准备。近年来，随着磁介质存储能力的提升，企业存储的价格也是一降再降，$2.00/GB 的底线早已突破，现在Sun 的Thumper 声称可以达到 $1.20/GB 的成本。(注：企业存储[不是个人消费品]的磁盘价格一降再降，而且有很重要的商业因素，具体的成本应该还要更低一些，只是不知道哪位朋友有更为准确的数字)

粗略估算一下，2PB 的原始容量成本大约是 250 万美元左右(List Price)。单位机柜空间密度最高的已经能够做到4U的机存储48TB的原始容量(目前能看到密度最高的了)，这样最小只需要大约 45 个 4U 的机柜空间。其他方面，加上本地的工业电力价格，大致的硬件总体开销还是可估量的。软件方面，这个存储本身是基于 Sun 的 ZFS，内置的操作系统，成本也是可以控制的。

山寨云存储方案设想

在山寨精神盛行的今天，没准儿已经有人在搭建一套山寨版的云存储方案呢。比如目标定在 1PB 可用容量，预计至少需要如下的东西:

选择廉价的刀片服务器(自己"生产"就不必了)，内置足够多的大硬盘，硬盘速度无所谓，预计每台机器预装4T容量(1T*4，坏了就整台机器替换)，大约需要 500台服务器，总容量2PB，确保每一份数据都至少冗余在另外的物理机器上，冗余后，起码能得到1PB容量(如果备份的数据启用压缩，没准儿能提供更多空间呢)。机架物理空间怕是需要 1000 U多一些，每个标准机柜是42U，怎么也要准备 25 个机架吧，再加上网络交换机什么的... 然后是电力与空调散热问题。

再弄一套 Hadoop ，定制一下跑起来 ...当然，山寨与否，关键是拼技术团队，一味的拿来主义注定只能跟风。

其实，这篇文章也是一篇山寨文。

--EOF--

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

引言, "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 ，但是实际上，仍然处于理论阶段，产品化的路还有点距离。

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

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

根据 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 用户；
• 低成本
云存储本质上还是规模化经济。如果成本不能有效的控制，那么云存储对厂家、对用户来说是没有意义的；
• 高扩展性
云存储组件应该具有足够高的扩展性，应该能够通过在线扩充存储单元进行有效的平滑线性扩展；
• 自动容错能力
因为低成本的，存储组件的损耗率应该很高，云存储厂商应该能在软件层做到自动容错而不是依赖硬件本身的容错；
• 易管理性
构建云存储系统，可管理性应该在设计之初就要考虑到，如果管理太复杂，很难做到低成本，稳定性、可靠性也会受到挑战。
• 去中心化
对元数据的管理不应该通过少数或者单一的管理节点来操作或者存储。

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

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

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

未完待续...

前不久写给《程序员》的一篇文章里，个人预测在 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 ，是说面向企业应用而不是面向个人消费品的。

再增加一个图：

数据库巨头 Oracle 一向不怎么涉足硬件领域，但这并不等于没有硬件方面的野心(过去折腾过几次都失败了)。这次在 Oracle Open World 上一下子宣布了两款 Exadata 系列的存储产品。一个是 Oracle Exadata Storage Server ，另外一个叫做 HP Oracle Database Machine 。

Exadata Storage Server 架构分析

该产品基本上可以看成是山寨版的存储集群。只是山寨主人财大气粗，所以比较唬人。

如上图，是基于所谓的 Cell 的，每个 Cell 就是一个存储模块，乍看上去好像 HP 的 MSA 系列的东西 ，考虑到这东西能扩展能大柜子，又很像 HP 的 EVA 产品的变形(早就听说 EVA 准备推出 Cluster 的形式)，不过接下来又看到每个 Cell 有自己的 CPU、内存、NIC，莫非就是个 PC ? 等我下载了一份 Data Sheet 看了一下，居然就是个 PC 服务器 ......

从上图大致能看出来，Oracle 主要的还是想卖软件，企业管理器、念念不忘的 Automatic Storage Management(ASM)，还有山寨版 RHEL --OEL 也在这个框架内。

名词解释：iDB

iDB - the Intelligent Database protocol. 这是这套系统中的一个亮点。iDB 在数据库核心层实现，直接映射操作到存储，减小不必要的开销。如果 iDB 真的能有效提升 IO 能力，那这个产品还是值得一用的。每个 Cell 是有计算能力的，实际上相当于 DB 把 SQL 扔给 Cell， Cell 返回结果给 DB 。iDB 能够运行在 InfiniBand 之上。

InfiniBand

Oracle 的 RAC 集群是 "Share Storage" 的，DB 节点间的高速通信其实是很容易撞上天花板。如果要提升集群能力，只靠 DB 本身的能力其实不大现实。这个 Exadata 的设计思路就是希翼通过硬件集群的能力来扩大 Oracle 本身的 I/O 能力，而 InfiniBand 交换机成了核心的组件。

实际上，InfiniBand 交换机的数量会是问题，只用一个，可靠性不高，用两个，成本又上去了。这个无疑会让用户左右摇摆。

HP Oracle Database Machine

相当于一个打包好了的产品，预装了 Oracle 企业版 Linux 与 Oracle DB 11g 软件，面向数据仓库环境。假想敌是 Teradata ?

结论

流水帐写了这么多，最后我个人认为该产品是否能被市场接受还要看定价，如果足够便宜，那么会有用户拿来做中低端的应用，如果 Oracle 必须要把内置的软件卖出价钱来，那恐怕竞争力并不是很强。

这并非一个会让人多么激动的产品。

--EOF--

附加：价格列表

这两天关注了一下基于 SAN/NAS 的集群文件系统的产品。找到了关于 Alexa 的一则旧闻，之后又发现了一篇关于 AOL 部署 SAN 文件系统的文章。

Alexa 的相关数据

Alexa 超过 1000 台 Linux 服务器 Farm，每半年增长 300T 新数据。经过了同类产品的选型后，最后选择了 Ibrix 融合文件系统。

SAN 使用的是 HP Modular Smart Array (MSA1000) ，最大支持 12T ，Cache I/O 最大 3 万个，算是个中低端的阵列。Amazon 没有透漏这套系统的吞吐能力，只是说 Ibrix 这套系统能达到 1T 的 I/O 聚合能力，单个 NameSpace 可达 16PB 容量。

不过从现在的一些迹象上来看，Amazon 对存储层重新做了改造。这套解决方案被替换掉了也说不定.

AOL 的相关数据

原有状况：3000 台主机通过 10000 多个光纤通道端口连接到传统的 SAN 上。其中有 8PB 的非结构化数据，分布在大约 1000 台 文件服务器上。管理维护的复杂度可想而知。

解决方案：文件服务器采用直连的磁盘，每个 12 块 700GB 的 ATA 磁盘，然后通过 Ibrix 融合文件系统进行集群化。

看起来，Ibrix 提供的解决方案很有竞争力。现在一些比较大的用户对于存储层的集群的需求越来越多，快成为趋势，一揽子解决方案还是有必要的，毕竟不是每家技术能力都强如 Amazon、Google ，有的时候用第三方的成本是能小于自己动手 DIY 的。

--EOF--

前年在帖子里介绍过 eBay 数据量超过 2PB，这么大的数据量管理和规划是需要一些艺术的，可惜网络上能得到的信息太少。最近又找到一篇关于 eBay 存储的介绍，这篇文章通过访问 William Crosby-Lundin (这位老兄现在已经跳槽到 SalesForce了)披露了一些数据，虽然该文距离现在有一年了，还是对我有不少参考价值。

eBay 存储团队当时 12 个人，管理 13 套存储，总容量 2PB 左右(不要刻舟求剑，现在超过 8 PB，2008-08-04） 了，8000 个左右光纤口，可用性 99.94%，工作量肯定不小。每周要起用 10TB 存储，这些存储有 75 个 LUN(也就说平均每个 LUN 135GB 左右，这个数据有些怪异)。连接到 SAN 环境的主机大约有 1000 台，数据库集群有 600 个左右，据我所知，这里的集群应该只是指 Data Guard。

这么多的数据库，I/O 开销肯定不小，如何消除存储热点呢? 该文只是笼统的说通过存储层与主机层的数据分片达到的。如果应用上 I/O 均衡做的好一些，可能存储热点问题不会成为瓶颈。

这个存储环境的部署应该有好几年了。所以最近一两年比较火爆的存储虚拟化与 Provisioning 技术都没有大规模起用。个人觉得 eBay 这么大的数据量， Provisioning 技术对于 eBay 的环境会是比较适合的。

有的时候，盲人摸象也是一种乐趣呀。

补充一下，超过 140 套集群。另外，提醒一下，这些数据是随着时间而变化的。切莫刻舟求剑。

--EOF--

Refer :

Our systems process in excess of 20 billion newly added records per day, 40TB being added every 24h, serving thousands of users and delivering hundreds of millions of queries per month in a true global 24x7 operation with distributed teams around the globe on systems over 8 PB in size (largest cluster >3PB), processing more than 30 PB of data per day.

这几天存储行业比较大的一个新闻是 EMC 宣布在高端 Symmetrix 产品支持 SSD (固态盘, Solid State Drive)，注意是基于闪存(FLASH)的固态盘。不到半年前，和一些存储厂商的朋友提及 SSD 仍有人不知为何物，现在似乎一夜之间 SSD 到处都是了。EMC 虽身为市场的领先者，也敢于吃螃蟹，来者不善。

EMC 这次采用的 SSD 是 STEC 公司 Zeus-IOPS 产品线的产品。这一型号号称随机读操作的 IOPS 能达到 52000 个，采用 SLC (single-layer cell )，写也可以达到 17000 个 IOPS。只从这个数字看，单块 SSD 的性能是机械硬盘的 30 倍还多。在可靠性上，SETC 据说实现了 ECC 机制.

现有的机械硬盘的虽说在单位容量上还在不停的增加，但是性能基本上是到了瓶颈，即使用于高端存储的高速硬盘，IOPS 的能力基本上也就是 150 个左右。而 SSD 单块就能提供几万个 IOPS ，且耗电量极小，平均故障间隔时间(MTBF)又是普通硬盘的10倍之多, 这对以期得到高 IOPS 的 DBA 来说, 简直是银弹。

但是(什么都怕这个"但是")，但是 SSD 的有它固有的缺点。其中一个就是可擦写次数(这个在几个新闻稿里面可算是一笔带过的)，尤其是基于 Flash 的 SSD。传统磁盘虽然有它的缺陷，但是可擦写次数几乎是无限次的。

听听来自竞争对手的声音或许也能让我们多点心眼。HDS 的 CTO Hu Yoshida 在 Blog 上撰文，提出了他对 SSD 能否被市场接受的三点疑问：

• 1) 价格因素：SSD 大约是普通磁盘驱动器的 30 倍.
• 2) 磁盘供应商多数是初创公司，主流磁盘生产厂家并没有上阵呢.
• 3) Flash SSD 可擦写次数有限.

如果说前两条只是竞争对手的 FUD 的话，那么最后一条还是会令 EMC 销售很头疼，如何让客户消除这个疑虑是有些难度的。STEC 官方的技术参数是可擦写次数能达到 200 万次。这样看的话，在高端存储上用 SSD 还是有比较合适的应用场景：在 EMC 提倡的 “智能分层存储” 前提下由 SSD 提供密集读的操作能力。

--EOF--

插播一则广告：来自 ITpub 的朋友请帮忙投一票。
拉票这事情我还真的干得不多，第一次搞，脸皮虽然厚也有些发烧，因为已经有DBA在说“熙熙攘攘"了。

有些 Linux 数据库服务器用的比较低端的存储，因为业务的变化，有时候需要新增一些 LUN。Linux 服务器添加 LUN 后必须要重启动 ? 有的时候存储厂商工程师也这么说，不过这似乎是一个一直被误解的信息。

从专攻存储的同事那里得知利用 QLogic FC HBA LUN Scan Utility 这个脚本即可无需重启动系统而识别新添加的 LUN。也无需对 QLogic FC driver 的重新 Load。

场景：Linux Server + QLogic 的 HBA 卡 。以 QLogic 的 Qla2340 HBA 卡为例。下载该脚本(顺便说一下，该页面的 QLogic FC HBA Information Utility 也比较有用)。然后看一下脚本说明文件。

用法最简单只需要运行：

# ./ql-dynamic-tgt-lun-disc.sh

脚本会提示在没有活动 IO 的情况下运行。其实问题不大的了。 之后确认 OS 识别到新设备:

 # fdisk -l 

如果系统中有 PowerPath ,还需要运行：

# powermt config 

OK。多少提高了一点系统可用性，你可以不用向老板申请停机维护了。

附：另外一篇参考文档.

--EOF--

今天参加了 EMC 组织的存储技术培训。因为频繁被电话打扰，导致听课效果并不是那么好。很多内容似曾相识，只是都断断续续的，几乎每次培训都是这样的，总有"断点"。

上午是 CLARiiON 的简单介绍，在模拟操作的时候我发现了以前漏掉的一个盲点：Binding LUN 的时候，那个 Alignment Offset 的选项到底是干啥的? 讲师简单说了一下，感觉不太对路子。刚才闲下来，查找了一下这个信息，大致搞明白了这个 ”Alignment offset“。

用 ”Alignment offset EMC“ 作关键字搜索到的第一篇文档是 Dell 工程师写的。这里面用了一个词 "signature block" , 莫名的一个词，我相信是 Dell 工程师自己发明的(用 Metadata 不就得了)。另外两个关键词是 "Windows" 和 "31.5KB" ，为啥是 31.5KB ，不知道。接下来在 EMC 的 Powerlink 网站上找到了比较详细的说明。

首先确定一下，这个问题更多是影响 Windows 系统。

老的 BIOS 代码，使用 ”柱面、磁头、扇区数“这一套机制而不是 LBA （Logical block addressing ）的模式来寻址。Linux 的 fdisk 工具还是 Windows 磁盘管理器，在每个格式化的设备上都放置一份 MBR 。这个 MBR 占用 63 个隐含扇区 (63*512=31.5KB, Bingo!)。这个问题在 Windows 上存在，在 VMware 上也存在，offset 同样是 63。 在有些 Linux 上，因为 Boot Loader 的不同，也会有类似的问题。

无视 Alignment offset 会导致的问题:

如图所示，一个 IO 会分裂到两个 Disk(Device/LUN) 上去，后果很严重。和我以前描述过的 4k Offset 问题本质上是一样的。只是这个是针对文件系统的。

那么，如何校正这个 ”对齐偏移量" 呢?

存储厂商的推荐是如果用 Snap View / SAN Copy 等存储级别的操作的话，不要折腾，用系统默认的就成，否则，用主机端的解决方案。

主机端的解决方案分为 Windows 32位、Windows 64 位、Linux、VMware 几种。

1） 对于 32 位的 Windows ，使用 Windows 系统资源包的 diskpar.exe 来设定 offset ( 据说 Windows 2003 SP1 上的 diskpart.exe 已经具备了 diskpar.exe 的功能。refer)

2）对于 64 位的 Windows ，GPT(GUID Partition Table)类型的分区默认有 32M 保留区，MBR 类型的分区自动校准。不存在这个问题。这就是 64位 的 Windows 众多优点之一啊。

3) 对于 Linux ，fdisk /dev/{devicename} 然后进入 expert 模式, 然后输入 b ...

4) 对于 VMware，分为两种情况。虚拟机层（用虚拟机下操作系统的方案) 以及 ESX 服务器层 (fdisk).

上面几个步骤描述不详细，更详细的介绍你需要寻找一份白皮书： EMC CLARiion Best Practices for Fibre Channel Storage ，这个白皮书有针对 Flare 不同版本的，Flare 2.6 对这个问题有了比较好的改进。

是的，有的时候白皮书就在那里，只是没有人注意，没有看而已。

--EOF--

在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。

Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)

简单的说 YouTube 的数据流量, "一天的YouTube流量相当于发送750亿封电子邮件.", 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,"每天有10亿次下载以及6,5000次上传", 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.

Web 服务器

YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)

视频

视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。

出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 "迷你 Cluster" 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些"漏网"的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。

数据库

YouTube 用 MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。

最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是"分区",这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)

YouTube 也用 Memcached.

很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?

--EOF--

在 HDS 发布新产品 USP V 后两个月，EMC 宣布推出 DMX-4。

DMX-4 似乎没什么亮点。官方说明也就这么几个：后端终于支持 4GB 通道了(HDS 可是老早就支持了); 将支持 750GB SATA 盘。至于性能提升，说得比较模糊，大约是 1/3 的样子。在软件方面没有什么大的变化。 本来听说 DMX-3 将有一次微码升级才能支持端到端的 4GB。看来这次微码升级直接变成 DMX-4 了。

等闲下来收集一点资料，看看现在存储服务成本最低能控制到多少.

--EOF--

HDS 在5月中旬正式发布了高端存储新产品: Universal Storage Platform V (USP V)。这个产品应该只是 TagmaStore USP 的升级版，其定位是和 EMC 的高端存储 DMX－3 进行竞争，目前市场上也只有这两家在高端上有一拼，IBM 那用两个 p5 570 拼起来的盒子很多人都信不过。

看官方介绍，说 USP V 在性能上有很大提升，iops 达到了 350 万(USP 是 250 万)，这样的数字怕是不能说明什么，毕竟是最理想情况出来的数据。而从规格列表上看，Cache 最大容量仍然只是 256GB，而且，没有特别介绍 Cache 算法有什么改进。估计总体性能和 USP 相比也仅仅是有所提升，肯定不能达到 "飞跃" 的层次。

存储能力，相对与以前的版本的确是很惊人了，最大 247PB (内部最大 332T)，这倒是挺唬人的，估计也只能是用来唬人。在连通性方面也有所增强，这个在意料之中。当然，还是 Crossbar 交换式架构，这是第四代了。

软件方面新加了一些关键特性，Thin Provisioning，好像都翻译成"精简自动配置", 面向存储虚拟化。这个功能简单的理解似乎就是能虚拟出来一个大的存储池(在实际磁盘并不足的情况下)，然后对存储空间按需分配，以后用多少添加多少实际的硬盘。某种情况下能减少总体拥有成本(TCO)。这个功能 Netapp 和 EMC 的 NAS 产品应该据有的。我怀疑在高端存储上未必能有多大作为。另外, HDS 的监控软件仍然不够好，启用这样功能的用户，监控上可要费心思了。

HDS USP V 真正的支持 4GB FC ，包括各个环节。 这一点要比 EMC DMX-3 先进，DMX-3 只是部分支持。

下面这个图是 USP V 的规格列表(PDF，版权是 HDS 的):

Internet Archive(IA) 这个站点大家应该都不陌生。IA 旨在建立所有互联网站点的"档案库"，如果说 Google 是互联网的数据库的话，那么 IA 就是互联网的数据仓库了，定期对每个 Web 页面保存快照，数据量之大可想而知。

先看看 IA 每天需要面对的处理能力：
存储超过 850 亿个 Web 页面；
每天大约 600 万次的下载；
Wayback Machine 收到大约 1000 万次点击，每秒钟要处理 100-200 个点击;
每天10万次左右通过 URL 查找;
每天 400 万次返回请求;
存储的内容包括本文、音频、视频...等各种 Web 可见的格式。

显然 IA 需要的是一种前所未有的存储解决解决方案--廉价、可靠、低功耗...总之用起来要省钱。IA 的志愿者不得不考虑自己动手建立符合他们需要的存储系统，这下子可不简单，2004 年，第一个 100GB 容量的近线存储投入使用 。IA 的志愿者之一 Saikley 干脆抽身而出成立了 Capricorn Technologies 公司，专为类似组织提供存储解决方案。前面提到的 100TB 容量的产品即为该公司 GB 系列的产品。现在 IA 已经采用 PS(PowerStore) 系列的 PetaBox，是量身定做的，装机容量 1.5T，目前容量已经超过 3PB(怕是远远超过 3PB 了)。PS 系列产品每节点原始容量可以达到 3T，使用日立 Deskstar 硬盘，仅仅占 1U 的机柜空间。IA 也在站点上介绍了定制的这台 PetaBox 的一些规格要求以及参数。

PetaBox 也是 Linux 在企业级应用取得成功的一个范例。

PetaBox 存储产品给存储界带来了不小的震撼。每 GB 的成本仅仅是 2 美元。这还是 2005 年的价格，现在应该更便宜了。搜索了一下，这家公司目前还没有进入中国。

PetaBox 系统通过一个集中式的 PXE 启动服务器运行在 Debian 或是 Fedora Linux ，通过 Nagios 进行整个环境的监控。 管理成本也并不高--每 PB 一个人。

--EOF--

前面我在《eBay 的数据量》中介绍了一些道听途说来的关于互联网巨头 eBay 服务器架构的信息，不过还缺了一点关键数据。

在 Oracle 站点上的一篇题为 The eBay Global Platform and Oracle 10g JDBC 的白皮书，有能看到一些数据。

在 2004 年的时候，eBay 的应用服务器采用了 IBM WebSphere，部署在 WinNT 上，硬件是 Intel 双 CPU 奔腾服务器。服务器数量是 2400 台。在《eBay 的数据量》中我们知道，eBay 的是集中式处理 Log 的，每天会有 2T 的 Log 数据产生，现在只会更多。这些应用服务器分成不同的组，通过一个统一的 DAL(database access layer) 逻辑层访问 135 个数据库节点。

这篇白皮书已经发布了两年，相信在这两年的时间里，服务器规模又会扩大了许多。

eBay 的 SOA 架构 V3 示意图如下：

(插播一则新闻：竞拍这本《Don’t Make Me Think》，我出价 RMB 85，留言的不算--不会有恶意竞拍的吧? 要 Ping 过去才可以，失败一次，再来)

Craigslist 绝对是互联网的一个传奇公司。根据以前的一则报道：

每月超过 1000 万人使用该站服务，月浏览量超过 30 亿次，(Craigslist每月新增的帖子近 10 亿条??)网站的网页数量在以每年近百倍的速度增长。Craigslist 至今却只有 18 名员工(现在可能会多一些了)。

Tim O'reilly 采访了 Craigslist 的 Eric Scheide ，于是通过这篇 Database War Stories #5: craigslist 我们能了解一下 Craigslist 的数据库架构以及数据量信息。

数据库软件使用 MySQL 。为充分发挥 MySQL 的能力，数据库都使用 64 位 Linux 服务器, 14 块 本地磁盘(72*14=1T ?), 16G 内存。

不同的服务使用不同方式的数据库集群。

论坛

1 主(master) 1 从(slave)。Slave 大多用于备份. myIsam 表. 索引达到 17G。最大的表接近 4200 万行。

分类信息

1 主 12 从。 Slave 各有个的用途. 当前数据包括索引有 114 G , 最大表有 5600 万行(该表数据会定期归档)。 使用 myIsam。分类信息量有多大? "Craigslist每月新增的帖子近 10 亿条"，这句话似乎似乎有些夸张，Eric Scheide 说昨日就超过 330000 条数据，如果这样估计的话，每个月的新帖子信息大约在 1 亿多一些。

归档数据库

1 主 1 从. 放置所有超过 3 个月的帖子。与分类信息库结构相似但是更大， 数据有 238G， 最大表有 9600 万行。大量使用 Merge 表，便于管理。

搜索数据库

4 个 集群用了 16 台服务器。活动的帖子根据 地区/种类划分，并使用 myIsam 全文索引，每个只包含一个子集数据。该索引方案目前还能撑住，未来几年恐怕就不成了。

Authdb

1 主 1 从，很小。

目前 Craigslist 在 Alexa 上的排名是 30，上面的数据只是反映采访当时(April 28, 2006)的情况，毕竟，Craigslist 数据量还在每年 200% 的速度增长。

Craigslist 采用的数据解决方案从软硬件上来看还是低成本的。优秀的 MySQL 数据库管理员对于 Web 2.0 项目是一个关键因素。

--EOF--

作为电子商务领头羊的 eBay 公司，数据量究竟有多大? 很多朋友可能都会对这个很感兴趣。在这一篇
Web 2.0: How High-Volume eBay Manages Its Storage(从+1 GB/1 min得到的线索) 报道中，eBay 的存储主管 Paul Strong 对数据量做了一些介绍，管中窥豹，这些数据也给我们一个参考。

站点处理能力

• 平均每天的 PV 超过 10 亿 ;
• 每秒钟交易大约 1700 美元的商品 ;
• 每分钟卖出一辆车A ;
• 每秒钟卖出一件汽车饰品或者配件 ;
• 每两分钟卖出一件钻石首饰 ;
• 6 亿商品，2 亿多注册用户; 超过 130 万人把在 eBay 上做生意看作是生活的一部分。

在这样高的压力下，可靠性达到了 99.94%，也就是说每年 5 个小时多一点的服务不可用。从业界消息来看，核心业务的可用性要比这个高。

数据存储工程组控制着 eBay 的 2PB (1Petabyte=1000Terabytes) 可用空间。这是一个什么概念，对比一下 Google 的存储就知道了。每周就要分配 10T 数据出去，稍微算一下，一分钟大约使用 1G 的数据空间。

计算能力

eBay 使用一套传统的网格计算系统。该系统的一些特征数据：

• 170 台 Win2000/Win2003 服务器；
• 170 台 Linux (RHES3) 服务器；
• 三个 Solaris 服务器: 为 QA 构建与部署 eBay.com; 编译优化 Java / C++ 以及其他 Web 元素 ;
• Build 整个站点的时间：过去是 10 个小时，现在是 30 分钟;
• 在过去的2年半, 有 200 万次 Build，很可怕的数字。

存储硬件

每个供货商都必须通过严格的测试才有被选中的可能，这些厂家或产品如下：

• 交换机: Brocade
• 网管软件：IBM Tivoli
• NAS： Netapp (占总数据量的 5%，2P*0.05, 大约 100 T)
• 阵列存储：HDS (95%，这一份投资可不小，HDS 不便宜, EMC 在 eBay 是出局者) 负载均衡与 Failover: Resonate ;

搜索功能： Thunderstone indexing system ;
数据库软件：Oracle 。大多数 DB 都有 4 份拷贝。数据库使用的服务器 Sun E10000。另外据我所知, eBay 购买了 Quest SharePlex 全球 Licence 用于数据复制.

应用服务器

应用服务器有哪些特点呢?

• 使用单一的两层架构(这一点有点疑问，看来是自己写的应用服务器)


• 330 万行的 C++ ISAPI DLL (二进制文件有 150M)


• 数百名工程师进行开发


• 每个类的方法已经接近编译器的限制

非常有意思，根据eWeek 的该篇文档，昨天还有上面这段划掉的内容，今天上去发现已经修改了:

架构

• 高分布式
• 拍卖站点是基于 Java 的，搜索的架构是用 C++ 写的
• 数百名工程师进行开发，所有的工作都在同样的代码环境下进行

可能是被采访者看到 eWeek 这篇报道，联系了采访者进行了更正。我还有点奇怪原来"两层"架构的说法。

其他信息

• 集中化存储应用程序日志;
• 全局计费：实时的与第三方应用集成(就是eBay 自己的 PayPal 吧?)
• 业务事件流：使用统一的高效可靠消息队列. 并且使用 Cookie-cutter 模式用于优化用户体验(这似乎是大型电子商务站点普遍使用的用于提高用户体验的手法)。

后记

零散作了一点流水帐。作为一个 DBA, 或许有一天也有机会面对这样的数据量。到那一天，再回头看这一篇电子垃圾。

更新：更详细信息请参考：Web 2.0: How High-Volume eBay Manages Its Storage。可能处于 Cache 的问题，好几个人看到的原文内容有差异

--EOF--