OceanBase的基线数据采用了分布式B+树(类似于BigTable/HBase)的组织方式,例如:
·每个表按主键组成一个B+树,主键由若干列组成;
·一个叶子节点包含表的一个前开后闭的主键范围(rk1,rk2]内的数据;
·每个叶子节点内部按主键范围划分为多个块(block)并内建块索引(block index);
·每个块的大小通常在8KB~64KB之间并内建块内的行索引;
·数据压缩以块为单位,压缩算法由用户指定并可随时变更;
·每个叶子节点的大小可在一定范围内波动(例如上下50%);
·叶子节点可能合并或者分裂;
·所有叶子节点基本上是均匀、随机地分布在多台机器(称为chunk server)上;
·通常情况下每个叶子节点有2~3个副本;
·叶子节点是负载平衡和任务调度的基本单元;
·允许bloom filter;
……
一旦一个叶子节点被访问,它的块索引(block index)将会进入到内存cache中,这使得后续访问中定位块(block)时不再需要访问磁盘;反过来,如果一个叶子节点长时间不被访问,它的块索引也可能被从内存cache中淘汰出去。近期访问过的块(block)也常常能进入cache。
虽然有许多相似的地方,OceanBase数据结构与BigTable也有明显的不同:
·主键由若干有序列组成,而不是无结构的binary string;
·值有多种数据类型(数值,字符串,时间…),而并非binary string一种;
·类似于DBMS的schema并且根据schema进行强制数据类型检查和表关联等;
·支持按列存储,但没有BigTable的column family及qualifier;
·支持稀疏表,也支持稠密表;
·叶子节点的每个副本同时提供服务;
·不支持一个cell多个时间(timestamp)版本;
……
由于许多情况下业务数据往往是稠密的结构化数据,所以OceanBase增加了稠密数据格式,以减少数据量、方便业务并缩短数据操作时间,此外在schema中定义合适的数据类型可以避免数值类型的“字符串->数值操作->字符串”的转换等。
由于叶子节点(基线数据)的每个副本同时提供读服务(基线数据不需要写入),因此少量chunk server的故障并不增加系统的查询和修改的响应时间:即使没有cache,OceanBase对比较简单的查询的响应时间一般在几毫秒~十几毫秒之间,对比较简单的修改的响应时间在十几毫秒到几十毫秒之间,避免了少量chunk server的突发故障导致的大量用户请求的堆积。
本文出自:http://tech.it168.com/a2012/0312/1323/000001323304.shtml