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


  • http://zhu1.blogspot.com 木匠

    9月份把>仔细读过一遍, 需要配合实际需求使用.
    eBay 前CTO, 来我们公司,也谈到了数据库的分割(split),
    从三个维度:
    1) 功能
    2) 读/写
    3) 大表本身, 比如根据键值 (something like partition key)
    http://zhu1.blogspot.com/2007/10/2008-technical-vision-ebay-cto.html

  • http://xiuse.net.cn 秀色美食网

    楼主是高手呀

  • http://www.20ju.com 草根网

    好文,收藏至20ju.com

  • littlez