【IT168 技术】就像前面曾经提到：
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的突发故障导致的大量用户请求的堆积。
