淘宝数据库OceanBase SQL编译器部分 源代码阅读--Schema模式
什么是Database,什么是Schema,什么是Table,什么是列,什么是行,什么是User?我们能够能够把Database看作是一个大仓库,仓库分了非常多非常多的房间,Schema就是当中的房间,一个Schema代表一个房间,Table能够看作是每一个Schema中的柜子,行和列就是柜子中的格子。User就是房间的主人。简单来说,Schema是包含表,列,索引,视图等数据库对象的集合。
OceanBase中的强Schema
OceanBase要求schema强类型约束,也就是要预先定义好schema。这与传统的数据库基本同样,与非常多nosql的schema-free大相径庭。
也就是说,OceanBase的数据模式是基于关系模型的。关系模型通过关系分解消除数据结构的复杂性,获得了对数据查询的能力和灵活性。而关系模型的缺点也是由于关系分解,使得在须要“组装”的数据时要进行join操作,而join则是相当耗时的操作。
大部分的NoSQl产品以MongoDb为代表,是基于文档模型的,类似json的bjson格式,因此能够存储比較复杂的数据类型,而且能够避免了join操作。在获得数据结构的可扩展性的同一时候,则失去了对通用数据查询语言(SQL)的支持。你须要又一次学习这些NoSQL产品的查询语言。
关于关系数据库与NoSQL的对照,这里有一篇好文推荐给大家:
OceanBase中Schema的格式
依据OceanBase官方文档的介绍:
OceanBase 中的schema 表示为纯文本的ASCII码文件, 採用常见的配置文件的形式. 分成各个 section. 每一个section 下有多个配置项, 配置项名称和配置值之间用”=”连接.
OceanBase 中 schema 是以应用为单位的, 一个应用一个schema文件. 一个应用中能够包括多张表, 每张表中能够包括多个列, 以及多个联表(join)关系.
我们以以下一个样例test1.ini
文件来逐个梳理Schema的各个部分。文件内容例如以下:
[app_name]
name=collect
max_table_id=1003
[u_collect_item_id]
table_id=1001
table_type=1
column_info=1,2,item_name,int
column_info=1,3,new_price,varchar,20
rowkey_split=0
rowkey_max_length=9
max_column_id=3
[collect_info]
table_id=1002
table_type=2
column_info=1,2,item_name,int
column_info=1,3,item_price,varchar,20
rowkey_split=8
join=rowkey[8,16]%u_collect_item_id:item_name$item_name,item_price$new_price
rowkey_max_length=17
max_column_id=3
[collect_item_id]
table_id=1003
table_type=2
column_info=0,2,item_name,varchar,20
column_info=0,3,new_price,int
rowkey_split=0
rowkey_max_length=9
max_column_id=3
应用的信息
[app_name]
section为应用的信息。其它section每个代表一张表。
眼下主要有两个配置项: name
:用来配置应用的名称, 是一个长度不超过128位的字符串.max_table_id
:用来记录当前已经使用的最大的table_id.
在OceanBase中, 每一个表都由table_id唯一标识, 且table_id不能够被反复使用. max_table_id 这个配置项, 主要是为了方便 schema 生成程序记录已经使用过的table_id.
表的信息
Schema定义文件里,除了[app_name]
外的其它section都是一张表的信息。
section名就是表名,因此上面文件里定义了3张表u_collect_item_id
,collect_info
,collect_item_id
.table_id
:配置项配置了这张表在OceanBase系统中的唯一id,
由schema 生成工具自己主动生成. 在OceanBase系统中, id的取值范围是0-65535.系统会保留0-1000的table_id供系统自身使用.
table_type
:用来配置表是内存表还是磁盘表. 由于一张表的动态数据存储在UpdateServer上,动态部分不受table_type影响,
所以table_type实际上表示了ChunkServer上的静态部分是放到内存中还是放到磁盘上. 该配置项取值为 1 的时候, 表示静态部分放到磁盘上, 为2的时候, 表示静态部分放到内存中.
rowkey_max_length
:用来配置表中主键的最大长度.
rowkey_split
:配置表在存储的时候的拆分限制.
由于一个表的数据可能放到多个tablet上存储, 这个值告诉ChunkServer, 在分裂数据到不同tablet时哪些数据是不应该被分开的, 比方, 当这个值为9的时候, 表示主键前9个字节全然同样的记录不应该被分到两个不同的tablet中.
max_column_id
:配置本表中已经使用过的最大的列id,
由schema 生成程序维护并使用, 防止对列id的重用.
compress_func_name
:可选项, 配置这个表在存储时使用的压缩算法名字.
block_size
:可选项, 配置表在存储成sstable时,採用的block大小.
use_bloomfilter
:可选项, 配置表是否使用布隆过滤器,
非零值为使用.
rowkey_is_fixed_length
:可选项, 配置主键是否是固定长度值.
非零值表示主键是固定长度的. 假设不配置该项, 默认主键为固定长度.
列的配置
column_info
:配置项中的内容是详细描写叙述一列的,
用”,”分开, 其内容包括列属性, 列id, 列名, 列类型.
列的属性:取值为0或者1. 为0表示该列仅仅有动态数据(仅仅存在于UpdateServer); 为1表示该列既有动态数据又有静态数据(既存在于UpdateServer 又存在于 ChunkServer).
列id:是这个列在表中的唯一标识, 该值由schema生成程序生成, 不能够被重用. 列id必须大于1, 系统保留id为1的用于表示主键.
列名:是一个长度不超过128位的字符串.
类型:列的数据类型.
所以样例中的 column_info=1,3,item_price,varchar,20
表示 : 列名字是 item_price; id 是3; 静态数据放在磁盘上; 类型是 varchar, 长度是20个字符.
由于OceanBase的联表(join)设计,使得某些仅仅有动态数据的列是有意义的, 这样的列一般在转储过程中会通过join运算转储到其他表中.
联表(Join)关系的配置
联表(join)关系是OceanBase提供的简化关联查询的有力手段. join
:这个配置项里描写叙述的是join关系的详细内容
我们看一个样例: join=rowkey[8,16]% collect_item_info:item_name$item_name,item_price$new_price
这一行表示当前表的一个join关系. join=rowkey[8,16]%collect_item_info
是表示用当前记录的主键的第8-16字节(闭区间) 与表collect_item_info
进行join操作. “:”后的内容表示详细发生join的列.
用”$”分开的两个列分别被称为參与join操作的左列和右列. join操作总是用右列的值合并到左列的值上, 然后将合并的结果返给用户(左列和右列的值都不发生变化, 合并仅仅体如今反给用户的结果中).
所以上述的表达是说, 当訪问当前表的时候, 假设訪问到列
或者
item_name
. 则须要以当前主键的 8-16 字节为主键查找表
item_price
. 假设查到记录, 则用其
collect_item_infoitem_name
列的值与当前记录的item_name
的值做合并, 用其new_price
列的值与当前记录的item_price
的值做合并,
将合并的结果作为终于值返给客户.
以上的格式介绍出自OceanBase的官方文档 doc/OceanBase的schema.docx
Schema的管理
下面讨论基于OceanBase0.3版本号。
Schema由RootServer进行管理,包含Schema配置文件合Schema管理器两部分。RootServer能够通过
和
switch_schema
来切换不同的schema配置文件和不同的schema管理器
switch_schema_manager
。
ObSchemaManagerV2
bool ObRootServer2::get_schema(ObSchemaManagerV2& out_schema) const;
/* 从本地读取新schema, 推断兼容性 */
int ObRootServer2::switch_schema(int64_t time_stamp, ObArray<uint64_t> &deleted_tables);
void ObRootServer2::switch_schema_manager(ObSchemaManagerV2 *schema_manager);
Schema的代码组织
与配置文件的结构类似,表、列和join联表分别相应了3个类。
class ObJoinInfo;
class ObColumnSchemaV2;
class ObTableSchema;
(应用信息[app_name]的相关代码在哪?)
这三个类主要功能就是对配置文件里的各个属性进行get和set。各种属性在上节已经有较具体的介绍,不再反复。
Schema管理器
Schema管理器ObSchemaManagerV2
负责管理每一个Schema中的TableSchema,ColumnSchema,JoinInfo。拥有TableSchema,ColumnSchema,JoinInfo的get和set函数。
Schema管理器ObSchemaManagerV2
相应了一个完整的Schema配置文件。能够从配置文件解析生成相应的TableSchema,ColumnSchema,JoinInfo。一个配置文件里能够配置多对张表,每一个表有多个列,体如今数组table_infos_
和columns
上。,此外,还有两个ObHashMap结构以列Id和列名作为key,用于加速列的查询。
class ObSchemaManagerV2
{
public:
/*省略其它方法,成员变量*/
bool parse_from_file(const char* file_name, tbsys::CConfig& config);
bool parse_one_table(const char* section_name, tbsys::CConfig& config, ObTableSchema& schema);
bool parse_column_info(const char* section_name, tbsys::CConfig& config, ObTableSchema& schema);
bool parse_join_info(const char* section_name, tbsys::CConfig& config, ObTableSchema& schema);
bool parse_expire_info(const char* section_name, tbsys::CConfig& config, ObTableSchema& schema);
};
private:
char app_name_[OB_MAX_APP_NAME_LENGTH];
ObTableSchema table_infos_[OB_MAX_TABLE_NUMBER];
ObColumnSchemaV2* columns_;
hash::ObHashMap<ObColumnNameKey,ObColumnInfo,hash::NoPthreadDefendMode> column_hash_map_;
hash::ObHashMap<ObColumnIdKey,ObColumnInfo,hash::NoPthreadDefendMode> id_hash_map_;
int64_t join_table_nums_;
uint64_t join_tables_[OB_MAX_TABLE_NUMBER];
其它涉及Schema管理的模块
在OceanBase系统中,用户的读写事务都会发给MergeServer。MergeServer解析这些读写事务的内容,比如词法和语法分析、schema检查等。对于仅仅读事务,由MergeServer发给对应的ChunkServer分别运行后再合并每一个ChunkServer的运行结果;对于读写事务,由MergeServer进行预处理后,发送给UpdateServer运行。
因此在MergeServer中也存在一个Schema管理的接口ObMergerSchemaManage
.
ObMergerSchemaManager
管理SchemaManager
,能够获取,加入和释放ObSchemaManagerV2
,schema
manager 最多有
(默觉得4)个
MAX_VERSION_COUNT
的实例。我们能够通过
SchemaManagerget_schema
来获取Schema管理器ObSchemaManagerV2
。还能够通过add_schema
,release_schema
来加入或释放ObSchemaManagerV2
。假设实例到达上限时继续加入,则会删除最旧的一个实例,然后在加入新的SchemaManager
实例。
const ObSchemaManagerV2 * get_schema(const ObString & table_name);
const ObSchemaManagerV2 * get_schema(const uint64_t table_id);
int add_schema(const ObSchemaManagerV2 & schema, const ObSchemaManagerV2 ** manager = NULL);
int release_schema(const ObSchemaManagerV2 * schema);
总结
与传统数据库类似,OceanBase要预先定义schema。採用ASCII配置文件对Schema进行配置。一个应用使用一个schema文件. 能够包括多张表, 每张表中能够包括多个列, 以及多个联表(join)关系.RootServer负责管理Schema配置和Schema管理器。
欢迎光临我的站点----蝴蝶忽然的博客园----人既无名的专栏。
假设阅读本文过程中有不论什么问题,请联系作者,转载请注明出处!