Entries tagged with “eBay” from DBA notes
用什么来衡量一天没有白过? 可能看到一篇好文章能算做一个条件。infoQ 上的这篇 Scalability Best Practices: Lessons from eBay 会让每个架构师都比较激动的。
过几天估计 infoQ 中文站就翻译这篇文章了，所以只记录一点自己的想法好了。在其中的 7 个实战经验中，每一条都值得写篇学习笔记，我比较关注面向 DB 的几条。
水平切分
对于 eBay 这样个头的大 Web 应用，如果数据不能分片，就无从谈及扩展。这个话题我之前描述过一点，文章中提及数据库层的切片要比应用层复杂许多，我想其中最大的一个难点就是不同用户之间的关联数据问题吧，否则就完全可以根据用户范围或者群体划分到不同的 DB 上。现实的应用总是如此复杂，让每个架构师都早生华发啊。
避免分布式事务
其中提到的前 Inktomi 工程师 Eric Brewer 提出的 CAP 定理： Consistency (C), Availability (A), Partition-tolerance (P) ，最多能同时选择两个。三个不能同时实现。对于 eBay ，选择的是 A 和 P，牺牲了一致性，而通过系统的其它手段(比如事件系统)来追回事务的完整程度。BTW: 这次倒是没有提及 BASE :)
虚拟化所有层次
这样做的目的是为了达到编程上的方便以及运营操作的灵活性。通过 eBay 的 O/R 层实现了对数据库的虚拟化。这样应用程序开发者无需关注数据存在哪里的。
Cache
其中提到了 Cache 的应用场景：针对缓慢改变的数据、只读为主的数据、元数据、配置信息和静态数据等。 把握这个原则是很关键的。我个人就看到有病急乱投医的设计者把数据一股脑的扔进 Cache，潜在的麻烦很难消除。
强烈推荐大家直接点过去看一下该文。
补充：关于 BASE。
Basically Availble
Soft-state
Eventual Consistency
--EOF--
在修改后的 《闲谈 Web 图片服务器》 一文中也提及了"IE 浏览器的连接数问题"，这也是个有趣的话题。值得补充记录一下。
这个数据来自 Roundup on Parallel Connections ，这是一篇好贴，里面的每个线索几乎都值得一读(Opera 9 的连接数我做了修改)。以前经常看到某些优化 IE 或者优化 Firefox 的插件或工具，其工作原理也不过是针对这些相关的网络参数合理组合罢了。 好多朋友说 Opera 快，其实可能就是压缩和连接数两个做的更适合现在的网络吧。我不太相信内置解析器什么的真能比其它浏览器有什么质的领先。
其中 Firefox 3 的连接数目前还处于不确定中。对于网站维护人员，这是个非常值得重视的信息，我们总说蝴蝶效应，这恐怕就是最直接的例子了。一旦 IE 8 确定了新的默认连接数，并且短期内大量用户下载，有些网站如果不做调整的话，很可能会被击垮。
--EOF--
过去写过很多关于 eBay 数据平台架构的帖子，过去eBay 的信息架构里 DB 都是采用 Oracle 的，大多数 DBA 朋友也都知道 eBay 在 Oracle 方面的技术搞得非常好。这次的 The 2008 MySQL Conference & Expo 披露出来的信息，eBay 在 MySQL 上做了很大胆的尝试，eBay Personalization Platform 就是用 MySQL 打造的。Sun 当然不会放弃这个大好的宣传机会(这两家在技术上的合作一向也比较多)，所以年度最佳应用给了 eBay (一同获奖的还有 Virgin Mobile France 和 Facebook )。
面临的应用场景：客户端 Cookie 最大 4K，如果要传递更多定制化信息就不好搞了。作为电子商务站点，肯定有要为用户提供更具有关联性的商品信息的业务需求，这样就要跳出原有的窠臼。通过数据库集群来存储类似的信息就是有必要的，但 eBay 原有 Oracle 数据库上的压力已经很大。
eBay 采用 MySQL Memory Engine 做数据库 Cache 层解决方案(如果纯粹用 Memcached 类似的方案也不太适合的，读写比例接近)， eBay 工程师 Igor Chernyshev 对内存引擎做了质的改进，而这些改进是开放出来的(Mysql-heap-dynamic-rows 项目，对 VARCHAR 列的内存开销算法做了革命性的改进)。另外一个 Patch 扩充了并发能力，一台普通的 Sun 4100 上能支撑 20000 个并发连接。每秒钟处理 13000 个 TPS，读写各半。25 台机器组成的集群，每天支撑 40 亿次的读写请求，为每个用户传递的定制数据平均大小 40 K，从 4K 到 40K ，足够多的定制信息可以存储了。
架构示意图(来源)：
这个个性化平台系统虽说关键，但是存储的数据并非不能丢失的。这也是 eBay 大胆采用 MySQL 的一个考虑因素吧。
MySQL 更大规模部署时代似乎来临。
--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.
对于 eBay ，我盲人摸象一样写了好几篇 Blog ，暂列一下：
今天又重新读了一下这篇《The eBay Architecture --Striking a balance between site stablility, feature velocity, performance, and cost》，觉得数据层的扩展经验也很有意思。
通过功能划分不同数据库，然后根据主要访问路径水平分割数据库。这句话太空了，类似 MySQL DB 大家常采用的 Shard 思路。
减小 DB 资源开销
数据库上没有业务逻辑。这包括：不用存储过程; 只有少量比较简单的触发器。
把CPU 开销比较高的工作迁移到应用上。这包扩：参考完整性检查(嗯，检查一下你的 DB 是否再用外键? ); 连接(Join), 排序。
应用服务器尽量 Prepared 语句以及绑定变量的广泛使用。
最小化 DB 事务
自动提交(Commit)大多数主要的数据库写操作。 客户端绝对没有事务(业务逻辑) 。这包括: 单个数据库通过匿名 PL/SQL 块进行事务管理; 没有分布式事务。对于"事务", 相关信息可以从 eBay 首席架构师 Dan Pritchett 的访谈得到确认。没有事务更没有分布式事务这一点比较关键，这也是因为 eBay 的商业逻辑天然性质(否则也不容易做)，所以可以做到 Scale Out，而最近了解到 Paypal 则因为交易逻辑比较复杂，只能是 Scale Up. Paypal 的技术信息一向比较封闭，谁能告诉我一点额外的信息呢?
--EOF--
在过去的 Blog 中, 我(插一嘴：这里的"我" 如果替换成 "Fenng" 似乎有些自恋, 也不是我喜欢的行文语气, 可发现转贴不留名的行为太多了,他大爷的)曾经介绍过 《eBay 的应用服务器规模》 , 也介绍过 《eBay 的数据量》，在这篇文章中提到过 "eBay 购买了 Quest Share Plex 全球 Licence 用于数据复制"，这个地方其实没有说开来。
对于 eBay 这样超大规模的站点来说，瓶颈往往最容易在数据库服务器上产生，必定有一部分数据(比如交易记录这样不容易水平分割的数据)容易带来大量的读操作，而不管用什么存储，能承担的 IO 能力是有限的。所以，如果有效的分散 IO 的承载能力就是一个很有意义的事情。
经过互联网考古学不断挖掘，路路续续又现了一些蛛丝马迹能够多少说明一些问题。客观事实加上主观想象，简单的描述一下。见下图：
通过 Quest 公司的 Share Plex 近乎实时的复制数据到其他数据库节点，F5 通过特定的模块检查数据库状态，并进行负载均衡，IO 成功的做到了分布，读写分离，而且极大的提高了可用性。F5 真是一家很有创新性的公司，虽然从这个案例来说，技术并无高深之处，但方法巧妙，整个方案浑然一体。
F5公司专门为Oracle 9i 数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验(EAV)进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的 ICMP/TCP 层进行健康检查。
这个图来自一篇《F5助力eBay数据库服务器负载均衡》的软文，真是一篇很好的软文，国外恐怕不会出现这样"含金量"极高的东西。
当然，这个技术架构可不算便宜。Quest 的 Share Plex License 很贵，而且，对于每个结点来说，都需要数据库 License 与硬件费用。但优点也很多：节省了维护成本; 数据库层面的访问也能做到 SOA; 高可用性。
国内的一些厂商比较喜欢给客户推存储级别的解决方案。通过存储底层复制来解决数据分布以及灾备问题。这个思路似乎太传统了，对于互联网企业来说多少有点过时。
BTW: 对 Amazon 的存储架构非常感兴趣，谁/哪里能提供点线索呢?
--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 示意图如下：
作为电子商务领头羊的 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 用于数据复制.
应用服务器
应用服务器有哪些特点呢?
非常有意思，根据eWeek 的该篇文档，昨天还有上面这段划掉的内容，今天上去发现已经修改了:
架构
- 高分布式
- 拍卖站点是基于 Java 的，搜索的架构是用 C++ 写的
- 数百名工程师进行开发，所有的工作都在同样的代码环境下进行
可能是被采访者看到 eWeek 这篇报道，联系了采访者进行了更正。我还有点奇怪原来"两层"架构的说法。
其他信息
- 集中化存储应用程序日志;
- 全局计费：实时的与第三方应用集成(就是eBay 自己的 PayPal 吧?)
- 业务事件流：使用统一的高效可靠消息队列. 并且使用 Cookie-cutter 模式用于优化用户体验(这似乎是大型电子商务站点普遍使用的用于提高用户体验的手法)。
后记
零散作了一点流水帐。作为一个 DBA, 或许有一天也有机会面对这样的数据量。到那一天，再回头看这一篇电子垃圾。更新：更详细信息请参考：Web 2.0: How High-Volume eBay Manages Its Storage。可能处于 Cache 的问题，好几个人看到的原文内容有差异
--EOF--
订阅更新
如果喜欢用 RSS reader 获取信息，可以订阅这个 Feed 以便获取 “eBay” 将来的更新内容.
