标签： Database

淘宝OceanBase架构笔记

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

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

Infobright 数据仓库

最近有部分工作涉及到了 Infobright 数据仓库，就浏览了一些相关的资料，感觉很受启发。下面写一些感想，如有谬误，还请指正。

简单的来讲，Infobright 主要有下面的一些优点：

1. TB 级的数据存储和高效查询。大数据量存储主要依赖自己提供的高速数据加载工具（百G/小时）和高数据压缩比（>10:1），高效查询主要依赖特殊设计的存储结构对查询的优化，但这里优化的效果还取决于数据库结构和查询语句的设计。

2. 高数据压缩比，号称一般能够达到 10:1 以上的数据压缩率。高数据压缩比主要依赖列式存储和 patent-pending 的灵活压缩算法。

3. 与主要 BI 分析工具的兼容性。兼容性这点主要依赖与 MySQL 的集成，作为 MySQL 的存储引擎自然地能够保证与 BI 分析工具的兼容。

除了上面的优点外，它也有一些限制：

1. 不支持数据更新。这使对数据的修改变得很困难，这样就限制了它作为实时数据服务的数据仓库来使用。用户要么忍受数据的非实时或非精确，这样对最（较）新数据的分析准确性就降低了许多；要么将它作为历史库来使用，带来的问题是实时库用什么？很多用户选择数据仓库系统，不是因为存储空间不够，而是数据加载性能和查询性能无法满足要求。

2. 不支持高并发。虽然单库 10 多个并发对一般的应用来说也足够了，但较低的机器利用率对投资者来说总是一件不爽的事情，特别是在并发小请求较多的情况下。

3. 没有提供主从备份和横向扩展的功能。如果没有主从备份，想做备份的话，也可以主从同时加载数据，但只能校验最终的数据一致性，这会使得从机在数据加载时停服务的时间较长；横向扩展方面，倒不是 Infobright 的错，它本身就不是分布式的存储系统，但如果把它搞成一个分布式的系统，应该是一件比较好玩的事情。

在架构方面，Infobright 给我展示了不少新想法，算是受益颇多吧。首先是按列存储，然后把列数据切成小块（Data Pack），进行压缩和统计（DPN, Data Pack Node），然后再对多块数据之间进行知识关联（Knowledge Node），最后对整个表形成知识网格（Knowledge Grid）。虽然说 Infobright 没有提供索引结构，但它 Knowledge Grid 中的 Numerical Histogram、Character Map 和 Pack-to-Pack 结构，怎么看都和 bitmap 索引脱不了关系。只是它的组织形式不像传统数据库中的索引罢了。

其实我们在设计类似的分布式表格系统时，也可以实现类似于 Knowledge Grid 的结构。这个结构未必跟 Infobright 的一样，但是如果在压缩的基础上，基于系统查询模式（分布式系统的查询模式一般相对简单，复杂的也做不来），存储一些辅助的块统计信息以及块之间的关联信息，对于减少查询的资源消耗，提高查询效率会非常有帮助，这也正好是针对分布式表格系统很难建立索引这一缺点的弥补。

参考链接：

这篇文章对 Infobright 及其安装方法进行了基本介绍，最后的一个查询速度对比有些夸张（105:1），我觉得这可能跟查询条件正好能匹配上 Knowledge Grid 中的信息所致；这个博客很有趣，从 2010 年 3 月 8 日到 5 月 8 日之间的文章全是 Infobright 相关的，写的还是挺详细的；Brighthouse: An Analytic DataWarehouse for Ad-hoc Queries 是一篇相关的 08 年 VLDB paper；此外官网上的白皮书不能直接下载，但在搜索引擎中能搜到一些。