OceanBase架构设计

OceanBase

这次主要是记录一下在华东师范大学听的关于OceanBase的讲座。

OceanBase是一个分布式数据库,具备可扩展,高可用,高性能,低成本等核心技术优势,兼容MySQL并提供金融级数据库解决方案。

ali做的OceanBase个人感觉跟HBase有太多相似的地方。但是OB有很多优点,首先是高可用,OB使用了Paxos协议强同步。对于分布式数据库,使用Paxos协议使得备库尽量跟主库的数据相等

对于50万+数据量,写日志称为瓶颈,所以需要把内存加锁处理得足够好。

OB内存事务引擎支持B+Tree和Hash双索引,Hash索引主要是用于get操作,OB的update操作是append追加而不是覆盖。

OB SQL执行流程带来的启发,可不可以将之前语法分析,词法分析最后生成的Parallel Logical Plan存起来,下次读到相同数据时可以再取出

自己再看一下merge join和hash join.

OB存储引擎使用LSM结构,LSM结构的最大问题是怎么高效解决合并,因为数据库读数据是按块读取,所以会导致写入放大,即修改是只需要修改一条,但是却读了一个块,导致最后写入一个块。OB使用轮转合并解决

了解数据库数据之后做数据编码,数据编码之后再做针对该数据的压缩,空间更省,cache利用率更高,查询更快,OB默认lz4,用户可以选择zstd。lz4的编码速度是snappy速度的2倍,解码是snappy的三倍,对于读要求性能高的业务,解码速度是考核其的一个重要指标

对于OB,ali在做Hash索引时建立了动态可扩展Hash表,牛逼啊,bucket的大小竟然可以动态可扩展,每次扩展为2^x次需要去找论文看一下

OB 内存引擎的多版本并发控制需要使用全局,使得版本号一致

OB对于热点行,使用了一个诀窍,即对于多个线程对于一行同时读转换成将线程放入队列中一个一个读

OB的group commit个人感觉实际上就是HBase中memstore的flush。

同城部署不需要使用Paxos协议。

BlockCache怎么命中,怎么淘汰???

听了这节课最大的感受就是阿里在高可用和可靠性上考虑最多,跟自己平时项目做的完全不一样因为那时候自己根本不可能考虑这些。

最后get到2道阿里面试题

  1. hash%n,n怎么选,除了质数,更深层考虑

首先,为什么选择质数,因为哈希表设计的目的是尽量的随机散射,不希望这些在同一列上的元素(也就是冲突的元素)之间具有关系,所以采用素数作为哈希表的大小,避免模数相同的数之间具备公因式,如mod=8,第6列为6,14,22,30,有公因式2,容易发生哈希冲突。’mod = 7’,无公因式,较好 2. 对于类似于BlockCache的cache,怎么实现cache

Share