淘宝的OceanBase

OceanBase架构图(引自 rdc.taobao.com)html

OceanBase 是淘宝研发的一套分布式 NoSQL 数据库系统。具体它是什么、怎样实现的，能够参考李震老师(花名楚材)的《OceanBase介绍》和杨传辉老师(花名日照)的《Oceanbase – 千亿级海量数据库》。这里我只是谈一下本身的感想，若有谬误，敬请指正。sql

OceanBase 相较于其它分布式存储系统，有一个特性是支持跨行跨表事务。这个特性太明星了，让几乎全部其它系统黯然失色。但实现这个是有代价和局限 的，OceanBase 只能使用单机接受更新，也就是说它的 UpdateServer 只能有一个（或者准确地说，一组）。因为 UpdateServer 失去了扩展性，OceanBase 的应用必须创建在单机可以知足增量更新和查询性能需求（查询能够经过从机部分缓解）的前提下（或者硬件性能的增加快于性能需求的发展）。为知足这一点，需 要对软件和硬件都进行很好的优化，幸运的是从淘宝核心系统团队成员的文章来看淘宝应该不缺这样的专家，也不缺买设备的钱。值得一提的是，每一个公司看来都有 本身的基因，看到 OceanBase 我脑子里就浮现出淘宝数据库架构中单机 Oracle 挂一堆 MySQL 的景象，何其类似啊！数据库

阳振坤老师（花名正祥）在《淘宝海量数据库之二：一致性选择》这篇文章中说 OceanBase 是支持强一致性的。若是 UpdateServer 没有从库的话， 可以很容易理解。但考虑到 UpdateServer 从库也提供读服务，且 UpdateServer 之间使用 binlog 进行同步，那么还可否保证强一致性这一点我比较怀疑。也许会有其它的辅助机制来保证这一点，例如在 MergeServer 上作必定的策略。架构

在高可用性方面，对 RootServer 的说明较少，不清楚 OceanBase 有没有实现 UpdateServer 宕机后的 Master 选举。因为使用 binlog 同步，可能宕机恢复方面仍是有一些风险的。nosql

将 MergeServer 和 ChunkServer 部署在一块儿是个很好的选择，这样查询时可以利用必定的局部性。但除非根据业务需求很是精妙地部署，不然不可避免须要请求其它 ChunkServer 上的数据。我不知道它的查询是 MergeServer->(UpdateServer, ChunkServer0, ChunkServer1...)，仍是 MergeServer->(UpdateServer, MergeServer0, MergeServer1)。不一样的模式有同的优缺点，若是 ChunkServer 只作存储的话，查询的过滤、合并应该是在 MergeServer 上作的。若是选用第一种方式请求，ChunkServer 间传输的数据没有过滤和合并，数据量较大；若是选用第二种方式请求，UpdateServer 的压力可能会被放大，视 MergeServer 封装的功能而定。分布式

OceanBase 的介绍中没有提到 Chunk 或者 ChunkServer 是否分主从，也没有提到总体更新机制。考虑到更新是以批量方式合并到 Chunk 中，也许为了简化，Chunk 或者 ChunkServer 只是互备，没有主从。为了保证 ChunkServer 合并 UpdateServer 上冻结/转储数据时查询的正确性，可能用两阶段提交，不过我想仍然是一个很复杂的过程。性能

早上起来就想到这里，之后有问题再补充吧。优化

PS: 以前将楚材错当成了阳振坤老师的花名，已更正之。.net