转载时请务必以超链接形式标明文章 原始出处和作者信息及本版权声明。
链接：http://www.dbasky.net/archives/2009/02/ebay.html
修改Linux内核参数，减少TCP连接中的TIME-WAIT sockets
今天看了Fenng的一篇关于电子商务eBay公司的数据库文章,现在转载给大家，(声明：这个Fenng写的关于eBay公司的数据量，版权归Fenng所有)
作为电子商务领头羊的 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 用于数据复制.
架构
高分布式
拍卖站点是基于 Java 的，搜索的架构是用 C++ 写的
数百名工程师进行开发，所有的工作都在同样的代码环境下进行
可能是被采访者看到 eWeek 这篇报道，联系了采访者进行了更正。我还有点奇怪原来"两层"架构的说法。
其他信息
集中化存储应用程序日志;
全局计费：实时的与第三方应用集成(就是eBay 自己的 PayPal 吧?)
业务事件流：使用统一的高效可靠消息队列. 并且使用 Cookie-cutter 模式用于优化用户体验(这似乎是大型电子商务站点普遍使用的用于提高用户体验的手法)。
Bay 存储团队当时 12 个人，管理 13 套存储，总容量 2PB 左右(肖同学提示：现在超过 5PB）了，8000 个左右光纤口，可用性 99.94%，工作量肯定不小。每周要起用 10TB 存储，这些存储有 75 个 LUN(也就说平均每个 LUN 135GB 左右，这个数据有些怪异)。连接到 SAN 环境的主机大约有 1000 台，数据库集群有 600 个左右，据我所知，这里的集群应该只是指 Data Guard。
这么多的数据库，I/O 开销肯定不小，如何消除存储热点呢? 该文只是笼统的说通过存储层与主机层的数据分片达到的。如果应用上 I/O 均衡做的好一些，可能存储热点问题不会成为瓶颈。
这个存储环境的部署应该有好几年了。所以最近一两年比较火爆的存储虚拟化与 Provisioning 技术都没有大规模起用。个人觉得 eBay 这么大的数据量， Provisioning 技术对于 eBay 的环境会是比较适合的。
发表评论