淘宝OceanBase架构笔记

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

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

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

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

将 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: 之前将楚材错当成了阳振坤老师的花名，已更正之。