无论从数据量还是访问量，OceanBase不再能够是一个单机系统，即使一台单机能服务高达几个TB的数据、提供几万QPS的服务能力，因此，分布式系统不可避免，然而，内部如何实现拆表(拆库)以及如何实现数据库的事务，成为了一个很大的挑战和十分艰难的抉择：

一种选择是当前数据库的常用的水平拆库，淘宝在这方面已经有很多实践。通常的做法是对主键进行hash或者取模(其实是一种特殊的hash)，把数据分布到不同的DB服务器上，客户端通过路由或规则访问特定的数据库，将整个系统的数据和访问负载分散到多台服务器上，降低了单台机器的负载压力。但这种做法存在一些弊端：

第一，   数据和负载增加后添加机器的操作比较复杂；

第二，   许多跨行/跨表的修改通常涉及到多台机器，难以支持事务；

第三，   有些范围查询需要访问几乎所有机器；

第四，   RDBMS单机数据量小(例如许多情况下MySQL单机支撑200GB左右的数据时会有较好的性能)，可能消耗较大的机器资源；

最关键的是，这种方法早在多年前就被几乎所有关系数据库厂商采用并积累了丰富的经验，而OceanBase项目团队没有任何理由做得更好。

还有一种选择分布式B+树(类似于BigTable和HBase)，按主键的范围动态拆库，即把整个表看成主键的B+树，每个叶子节点(大约两百多MB)对应一个连续的主键范围，叶子节点可能因为修改删除等变得太大或太小从而进行分裂或者合并，容错、故障恢复以及负载平衡等都以叶子节点为单位(关于BigTable的更多信息可参加另外一篇博客：云计算之分布式表格系统或者BigTable论文原文：“Bigtable:  A Distributed Storage System for Structured Data”)。

这种架构的好处是系统易于扩展：简单地增加机器就可以，并且少量突发的机器故障对使用者甚至是透明的，负载平衡也比前一种方案更好，范围查询很容易实现且高效。

然而，这个架构最大的困难是事务的实现，因为BigTable只有单行事务，而OceanBase需要跨行跨表的事务。这个问题困扰了项目团队不短的时间才得到解决(参见“系统架构(二)”)。理论分析和代码实现都表明这个方法非常地简单、高效。

后来有机会拜读了Google的关于分布式事务的文章(“Large-scale Incremental Processing Using Distributed Transactions and Notifications”)，感受了其优秀的设计，也体会了它的复杂度，同时也发现，虽然它通过使用15000个CPU核达到了创纪录的11200 tps (TPC-E benchmark)，但它的平均事务响应时间为2s-5s，并不符合淘宝业务的平均几毫秒~几十毫秒的响应时间的需求，而且开发一个类似的系统及其底层BigTable和GFS等系统所需要的时间人力物力和技术挑战也是巨大的。(关于Google的分布式事务，欢迎感兴趣的朋友访问一个友人的wiki：

http://nosql-wiki.org/wiki/bin/view/Main/GoogleDistributedTransactions