【产品名称】
【产品版本】
【问题描述】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)
1 个赞
感谢您的回复，TP,AP数据资源在同一机器上，AP业务不会影响到TP业务需要的机器资源吗？在这块又是怎么思考的呢？
事务模型也是percolator吗？
企业版支持基于cgroup的资源组隔离，可以针对TP和AP设置各自的资源组以及对应的资源配比，社区版本暂时不支持这个功能。
1 个赞
https://open.oceanbase.com/docs/community/oceanbase-database/V3.1.0/overview-1
官方文档写的是两阶段提交，为什么这里写的是三阶段提交呢
嗯好的，感谢解答