分类归档: Arch

eBay 的存储一瞥

前年在帖子里介绍过 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 24×7 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.

Yupoo! 的网站技术架构

又有机会爆料国内 Web 2.0 网站的架构了。这次是 Yupoo! 。非正式的采访了一下 Yupoo!(又拍网) 的创建人之一的阿华（沈志华）同学，了解了一些小道消息。

作为国内最大的图片服务提供商之一，Yupoo! 的 Alexa 排名大约在 5300 左右。同时收集到的一些数据如下：

带宽：4000M/S (参考)
服务器数量：60 台左右
Web服务器：Lighttpd, Apache, nginx
应用服务器：Tomcat
其他：Python, Java, MogileFS 、ImageMagick 等

首先看一下网站的架构图：

该架构图给出了很好的概览(点击可以查看在 Yupoo！上的大图和原图，请注意该图版权信息)。

关于 Squid 与 Tomcat

Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问，对此阿华的解释是”目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确很差，后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去，所以命中率彻底提高了”

对于应用服务器层的 Tomcat，现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代，而 YPWS/YPFS 现在已经用 Python 进行开发了。

名次解释：

YPWS–Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的 Web 服务外，可以增加针对用户、图片、外链网站显示的逻辑判断，可以安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。
YPFS–Yupoo File System 与 YPWS 类似，YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。

【Updated: 有网友留言质疑 Python 的效率，Yupoo 老大刘平阳在 del.icio.us 上写到 “YPWS用Python自己写的，每台机器每秒可以处理294个请求, 现在压力几乎都在10％以下”】

图片处理层

接下来的 Image Process Server 负责处理用户上传的图片。使用的软件包也是 ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了(我个人感觉，效果的确好了很多)。”Magickd“ 是图像处理的一个远程接口服务，可以安装在任何有空闲 CPU资源的机器上，类似 Memcached的服务方式。

我们知道 Flickr 的缩略图功能原来是用 ImageMagick 软件包的，后来被雅虎收购后出于版权原因而不用了（?）；EXIF 与 IPTC Flicke 是用 Perl 抽取的，我是非常建议 Yupoo! 针对 EXIF 做些文章，这也是潜在产生受益的一个重点。

图片存储层

原来 Yupoo! 的存储采用了磁盘阵列柜，基于 NFS 方式的，随着数据量的增大，”Yupoo! 开发部从07年6月份就开始着手研究一套大容量的、能满足 Yupoo! 今后发展需要的、安全可靠的存储系统“，看来 Yupoo! 系统比较有信心，也是满怀期待的，毕竟这要支撑以 TB 计算的海量图片的存储和管理。我们知道，一张图片除了原图外，还有不同尺寸的，这些图片统一存储在 MogileFS 中。

对于其他部分，常见的 Web 2.0 网站必须软件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面采用不少相对比较成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。这也是一个 Web 2.0 公司所必需要走的一个途径。

非常感谢一下 Yupoo! 阿华对于技术信息的分享，技术是共通的。下一个能爆料是哪家?

–EOF–

豆瓣的 Web 服务器

豆瓣最近发布新功能有些”疯狂”，所以服务器也有新的部署。看到阿北同学在豆瓣广播里说：

豆瓣的第二台应用服务器终于投入了使用。Hongqn 忙了一晚上就完成了部署。第一台服务器支撑到 500 万动态PV/天，服务 On Demand 即时分布式部署......

500 万 PV , 还是动态 PV, 是个很惊人的数字。因为，如果都能达到一台机器支撑 500 万，那么国内稍有点规模的网站(就说动态 PV 上亿的吧)，只需要 20 台 Web 服务器就够了。事实上，即使比较强调技术的网站怕也要上百台 Web 服务器的规模。

我们知道豆瓣用 Lighttpd 做 Web 服务器。从侦测到的数据看，目前线上有两个版本。

$ curl -I http://www.douban.com
HTTP/1.1 200 OK
.....(无关内容略)
Server: lighttpd/1.4.15

另外一个版本：

$ curl -I http://www.douban.com/people/ahbei/
HTTP/1.1 200 OK
.....(无关内容略)
Server: lighttpd/1.4.18

其实豆瓣服务器还有个更为惊人的性能数字。从这个 Powered by Lighttpd 的列表来看，豆瓣在一台 Gentoo 服务器上的记录是 1200 万/天的点击量。这应该是动、静态页面混合情况下的吧。

有同事对这个数据有些好奇，问我到底豆瓣是用啥做的服务器，其实这个问题我也问过阿北，他们就是自己攒的 PC 服务器，然后把性能发挥到极致。阿北也表示过，即使现在豆瓣流量激增个十倍啥的性能也不会是问题。这也是从起始就考虑扩展性的收益吧。

这里这位老兄用七个 Mongrels 实例(也是一台Server)跑了 55 万 PV (thanks Robin 纠正) 就蛮自豪的，所以豆瓣的一台跑了”500 万动态 PV” 的确非常惊人。

Updated 2008-1-17 0:57:09

阿北留言了。主要是上面的有的数据还是旧的:

Lighty 网站上的数字很久没有去更新了。现在豆瓣的web服务器(lighttpd)每天估计2500万 Hits, 高峰时间大约1000 req/s (这里说的是主要输出HTML/CSS/JS和小图片的一台前端。大图片有另外的web服务器)。
我在广播里说500万PV/天的是应用服务器，就是lighty和mysql之间跑python的那台。现在豆瓣大多数PV来自注册用户，每个页面都需要几到十几种类的动态数据。
现在的服务器只是单片双核的opteron。换4核的话，应该能到一台1000万PV/ 天。

友情提醒，留言很精彩，敬请查看。不过在这个 Blog 上留言的确用户体验很糟糕(我也很烦),相信本周末能得到解决。

–EOF–

Google 的计算能力仍是独步武林

从 Greg Linden 的文章看到的数据：Google 的 MapReduce 平均每天处理 20 Petabytes 的数据。每天能跑完 10 万个工作任务。光是 07 年 9 月，就用掉了 11081 个”机器年” ，跑了 220 万个 Mapreduce 任务。这个计算能力是惊人的。

Yahoo! 也用 Hadoop 实现了 Mapreduce , 我个人感觉和 Google 可能还有一段距离。光有计算环境还不行，还要有应用程序来实现功能，Google 已经实现了超过 1 万个应用程序，Yahoo! 有多少呢?

这方面估计微软更没戏了，要是弄个不包括 “Window” 的 Windows 服务器集群估计还能差不多，否则，光是一个视窗要耗费多少计算资源? 如果服务器规模是几万、几十万台，计算能力的浪费是惊人的。微软的对抗计划是 Dryad.

所以说啊，Google 的计算能力仍是独步武林，虽然有不服气的，但有什么办法? 这方面 Google 就是强啊

–EOF–
补充：
更多的数据(来源):