eBay 的数据层扩展经验

对于 eBay ，我盲人摸象一样写了好几篇 Blog ，暂列一下：

• eBay 的数据量
• eBay 的应用服务器规模
• eBay 的数据库分布扩展架构

今天又重新读了一下这篇《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--