OceanBase——海量结构化数据的分布式存储解决方案.docx

OceanBase——海量结构化数据的分布式存储解决方案 OceanBase是为满足海量结构化数据存储需求而设计的。她具有良好的可扩展性，同时提供结构化数据的支持，较好地支持了业务相对复杂的系统对海量数据存储的需求。 介绍 随着互联网的进一步普及，互联网应用的用户进一步增长，对现有的很多架构提出了挑战。这在存储系统方面尤为突出。 首先，互联网应用需要存储的数据直接由用户生成，而不再是由应用提供者提供。随着用户量的增长，用户生成的数据量也随之增长，对系统能支撑的数据量提出了更高的要求，进而对底层的存储系统的可扩展性要求也越来越高。 随着移动互联网用户的增多，用户在线时间大大增长，这对服务的可用性提出了更高的要求，任何时刻服务不可用影响的用户数可能都很大。 用户对服务的用户体验要求也越来越高，用户体验的一个重要因素便是响应时间，底层存储系统的响应时间非常关键。 很多应用开始阶段为了开发效率，往往不会太多的考虑系统的可扩展性，尤其是底层的存储系统，比如数据存储大多使用类似MySQL的关系型数据库。这在开始阶段工作的很好，随着用户数的增长，扩展性的问题越来越突出。由于使用传统的关系型数据库，现有的数据模型通常较为复杂，使得其向很多NoSQL产品（比如key/value系统）迁移比较困难。 OceanBase在设计的时候便考虑了以上的问题，她兼顾了NoSQL存储系统的可扩展性和传统关系型数据库在数据结构表达上的便利性，为解决以上问题提供了一种新的思路。 本文介绍了OceanBase的设计与实现，并简单介绍了其在淘宝收藏夹应用中的使用。第二部分介绍OceanBase的数据模型。第三部分介绍客户端的接口。第四部分介绍了其具体的实现。第五部分展示OceanBase的性能数据。最后一部分我们介绍OceanBase在收藏夹中的应用。 数据模型 OceanBase支持应用的概念（这类似与数据库中的schema），一个应用可以创建多张table，table中包含一系列的列。table之间支持基于列的关联（join）关系。应用在使用前需要先创建数据模型，并支持在运行过程中动态修改数据模型。 Rowkey 每张表都需要指定一个rowkey，rowkey的最大长度可以在创建时指定，??内容为二进制字符串（Binary String）。Rowkey在一张表内需要确保唯一（这和关系型数据库中的主键类似），OceanBase在内部存储时，数据按照rowkey排序。一张表的数据会根据rowkey动态的切分，切分后的单位为tablet，tablet由startKey和endKey指定其负责的数据的范围。 OceanBase的rowkey还支持split属性。该属性指定了rowkey内容的一个前缀，当数据在被动态切分时，系统会确保split后前缀内容相同的rowkey所对应的数据不会被切分至多个tablet中。 比如在淘宝的收藏夹应用中，用户可以收藏某个店铺，也可以收藏某件商品。用户的一条收藏记录可以由{userId, object type , object id}唯一确定，所以将其作为rowkey，分别表示收藏者的用户Id，被收藏对象的类型（店铺或者商品）和被收藏对象的Id，其中userId为一个8字节的整型。我们为了确保同一个用户的收藏在动态切分时分布在同一个tablet中，则可以指定rowkey在8字节的位置split。 Column 一张表可以创建多个列，OceanBase中列支持的数据类型包括： 类型说明Int整数，范围为[-2^63, 2^63]Varchar字节流，可以指定其最大长度，比如varchar(1024)Datetime表示自1970-1-1 00:00:00到现在的秒数Precise_datetime表示自1970-1-1 00:00:00到现在的微秒数Create_time和Precise_datetime类似，该列的值由数据新增时系统自动生成，不支持修改。Modify_time和Precise_datetime类似，该列的值由数据更新时系统自动生成，不支持修改。关联 为了简化对有关联的数据的查询操作，OceanBase支持在创建表时指定表之间的关联关系。当客户端查询时，服务器端根据表之间的关联关系定义，自动将相应的数据合并，然后将合并后的数据结果返回给客户端。 比如下面的关联关系定义： Join=rowkey[8,16]%collect_item_info:item_name$item_name,item_price$new_price 该关联关系定义了当前表和collect_item_info表之间的关联关系，关联关系由该表rowkey的8-16字节与collect_item_info的