Tag Archives: eBay

eBay 的Scalability最佳实践

用什么来衡量一天没有白过? 可能看到一篇好文章能算做一个条件。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–

eBay 的 Personalization Platform 采用 MySQL

过去写过很多关于 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 的存储一瞥

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

eBay 的数据层扩展经验

对于 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–