存储引擎和事务模型

【产品名称】

【产品版本】

【问题描述】oceanbase的存储引擎、事务模型都是什么样的

同问

1 个赞

oceanbase 存储引擎原理是 lsm tree。 写操作都是 append ,不会修改老的数据块。

跟同样使用lsm tree的其他分布式数据库产品不一样的地方在于,ob的写增量会尽可能的在内存中不落盘(事务日志会强制落盘)。由于增量只记录变化的数据,所以ob的内存可以容纳更多的数据增量,而不需要像其他数据库那样频繁的做数据文件的checkpoint。 当然内存大小是有限的,当增量内存使用水位到达阈值的时候,增量内存中的数据就会转储到磁盘数据文件中。这点类似 checkpoint。这个频率很低。在ob的tpcc测试中,1500台机器组建的集群,即使那么大的写入量,如果不是测试规范要求最长必须半小时checkpoint一次,ob的增量内存可以维持很久。真实的业务一天可能也就转储几次。最终在业务低峰期ob自动发起合并操作,将内存中的增量和磁盘上的基线数据在内存中合并落盘。这个大部分是连续的大io。

所以ob的数据写随机io很少,对ssd寿命很友好。

OB的事务支持acid,分布式事务是内部细节,对使用者(业务方)透明。ob的内部分布式事务是xa协议,三阶段提交,强一致。这点区别于其他分布式事务的最终一致性的解决方案。

ob的oracle租户和mysql租户的事务隔离级别是一样的,都跟oracle的readcommitted和serializable保持一致。



这回答太官方了,看缓存机制描述那感觉像是rocksdb改的

rocksdb 的原理也是lsm tree。 lsm tree 是一个技术。ob代码也开源了,可以看看有没有rocksdb的代码。

rocksdb的问题不少。比如说 写放大,io bound 等。

1 个赞

麻烦问下ob是如何解决写放大这个问题的?底层存储引擎TP和AP是用一个吗?

ob的tp和ap底层存储引擎是一个。  内存里会用到一些列存技术。其他就看 sql 引擎的能力。都是一套产品,不区分tp和ap。

ob的存储引擎设计 可以看看公众号文章:首发!OceanBase存储引擎的设计哲学和应用实践 (qq.com)

感谢您的回复,TP,AP数据资源在同一机器上,AP业务不会影响到TP业务需要的机器资源吗?在这块又是怎么思考的呢?

事务模型也是percolator吗?

企业版支持基于cgroup的资源组隔离,可以针对TP和AP设置各自的资源组以及对应的资源配比,社区版本暂时不支持这个功能。

1 个赞

https://open.oceanbase.com/docs/community/oceanbase-database/V3.1.0/overview-1

官方文档写的是两阶段提交,为什么这里写的是三阶段提交呢

仔细看看这个:PowerPoint 演示文稿 (alipayobjects.com)

说两阶段也是对的,细分就是三阶段:prepare、precommit、commit 。

嗯好的,感谢解答