体验一把Oceanbase单机版

最近从蚂蚁拿到了OceanBase的安装包，也先来体验一下OceanBase。因为我们的测试环境最近安装了十来种数据库，只能先安装一个单机版的OceanBase，无法体验OceanBase完整的功能。OceanBase是一个云数据库，在底层开始就是按照多租户设计的，每个租户都有独立的内存，CPU等的资源隔离。

Oceanbase是基于谷歌的五分钟原则设计的数据库系统（谷歌认为如果某个数据5分钟内会被访问至少一次，那么这个数据最好是放在内存中），是采用LSM-TREE作为存储引擎的。因此需要大量的内存来存储SST 。操作系统的物理内存可以尽可能多的交给OB SERVER，由OceanBase自己管理。

从上面的一张图里可以看到OB的内存使用策略。通过memory_limit_percentage参数可以设置最多有多少OS的内存可以给OB使用。这个参数的建议设置值是如果服务器内存为384GB，则设置为80%，如果服务器内存为512GB或者更高，则设置为90%。从这个策略也可以看出，OB还是比较吃内存的，为了有比较好的性能，建议给OB的服务器配置多一点内存。

为什么OB这么吃内存呢？这要从OB的存储引擎LSM-TREE说起，LSM-TREE存储引擎实际上是一种以内存为主存，磁盘为持久化内存的存储引擎。数据被写入时，只有WAL日志会落盘，而被写入的数据会存储在内存表memstore中。当写满一个memstore后，会创建一个新的内存表，继续写入新数据。对于某条数据的update，会直接在内存表中写入一条新纪录，而不会找到老记录去UPDATE，这个机制也是最终实现OB MVCC的基础。最终，OB会通过一个COMPARE & MERGE机制来实现这些版本的合并。OB的这种存储引擎和TiDB，HBASE等十分类似。另外除了内存表之外，OB还有BUFFER CACHE机制，用于存访访问较多的PAGE，进一步提高OLTP业务的性能。从这种机制可以看出，内存越大，OB的并发写入性能越好。

从上面的那张图可以看出，留给OB SERVER使用的内存又被system_memory_percentage参数分为两部分。其中（1-system_memory_percentage）被用于OB SERVER，system_memory_percentage被用于OB SERVER内的各个租户。

对于每个租户，都有独立的实例内存，实际上每个租户对于传统数据库来说，都类似于一个独立的实例。因为每个独立的实例都有自己独立的内存结构，不同的租户会在内存上有物理隔离。每个租户实例的内存被分为两个部分。一部分用于存储memstore，由租户个性化的参数memstore_limit_percentage来确定其百分比。而剩余的租户实例内存则作为row cache,block cache使用。从这个结构上来看，OB的租户隔离做的还是很彻底的。每个租户可以被我们看作一个独立的数据块实例。这种从底层开始设计的多租户架构，会比那些以前没考虑多租户，后面加上一些控制，共享实例的多租户架构有更好的租户独立性。

我们先来看看租户内存中的一些主要对象。最重要的就是KVCACHE，这个CACHE类似于Oracle的BUFFER CACHE，用于存储常用的数据，不过和BUFFER CACHE不同的是，OB的KVCACHE不仅仅用于存储数据，所有的KV结构的数据都可以使用KVCACHE来做缓冲。除此之外，还有用于缓存执行计划的PLAN CACHE,缓冲SQL的SQL AREA等结构。

这种混合CACHE是容易因为某种数据突然暴涨而导致整个CACHE出现性能问题的，为了解决这个问题。OB引入了一系列的参数来控制各种数据在KVCACHE中的优先级。下图是控制这些优先级的参数列表。

在SYS租户上存在的KVCACHE如下图：

在普通用户租户上存在的KVCACHE如下图：

分配给MemStore的内存并不是都能够被用于Memstore的写入，这是因为我们前面说过的LSM-TREE 存储引擎的CM的原因。当memstore做MERGE的时候，也需要消耗大量的物理内存。CM操作需要和数据写入操作竞争内存资源，为了确保CM进行时，能够确保正常的数据写入工作，需要一个参数来对这种情况的内存进行控制，这个参数就是freeze_trigger_percentage。这意味着，当CM操作发生时，整个OB数据库的写入性能是受到限制的，因为只有一部分MEMSTORE内存可以被用于新数据的写入，而大部分内存都要被用于freezen。

简单的分析了OB的内存结构后，我们先来体验一下我们实验室新装的OB数据库。为了和Oracle有一个对比，因此我们使用与Oracle兼容的引擎obclient去连接OB数据库。OB数据库也可以直接用MYSQL直接去连接。

登录进去后很像Oracle的SQL*PLUS，不过通过HELP看到命令的差异还是很大的。首先我们来感受一下一些简单的操作。

通过alter sesson命令居然成功的设置了时间的显示格式，sysdate,systimestamp，dual这些也是和Oracle并无两样。

DESC命令是可以用的，而且令人惊喜的是v$sysstat依然存在，这对于做数据库监控与性能优化的人来说是一个福音。不过听蚂蚁的朋友说，目前v$sysstat的数据还不是很完备，随着新版本的迭代，会逐步完善，目前这张视图所能带给我们的有用信息还不多。

我们创建一张测试表，可以看出v$sysstat有610条记录，从上面的例子可以看出，rowid,rownum这些伪列都是存在的。更有意思的是，我不小心写错表名的时候，报错信息也是ORA-00942，和Oracle是完全相同的。

对于唯一索引的键值冲突，提示也是ORA-00001。下面我们来看看行锁的情况。

首先锁住几条记录，然后再开一个会话去修改同样的数据：

没毛病，OB默认的是通用数据库的悲观锁，这个与坊间传闻的OB默认使用乐观锁是不符的。后来和蚂蚁的朋友沟通发现，一起按OB 1.0以及以前开源的OB版本都是默认为乐观锁的，所以给了大家这么一个错觉。2.x或者更高的版本，肯定都是默认的悲观锁。这对于应用开发的移植来说是十分关键的。

今天简单的用了用OB，没有做深入的分析，不过从与oracle数据库的兼容性来说，还是不错的。特别是看到OB的benchmark配置指南中所说的，OB的Benchmark测试可以模拟为Oracle数据库进行测试。

虽然jdbc还是使用了独立的驱动，并没有和Oracle完全兼容，不过从上面的兼容性测试来看，普通的SQL，包括应用向OB迁移的工作量并不会太大。当然一些复杂的统计分析的SQL还需要做一定的适配性修改，一部分是因为性能问题，一部分是因为语法上的略微不兼容。不过这种工作的总体工作量还是比较小的。这对于今后要做国产化数据库替代的客户来说，是一个好消息。