|
10.5 特色功能8 M7 v w8 o u. x8 G/ k: X# s
虽然OceanBase是一个通用的分布式关系数据库,然而,在阿里巴巴集团落地过
( H$ k2 f1 V6 F8 J6 \6 h2 ?程中,为了满足业务的需求,也实现了一些特色功能。这些功能在互联网应用中很
* y+ r% U( l7 x常见,然而,传统的关系数据库往往实现得比较低效。本节介绍其中两个具有代表7 Z) A& g* i7 ` _. C T+ K% I
性的功能,分别为大表左连接以及数据过期与批量删除。
! _6 |% \% A" e. L# K1 G+ D. ^10.5.1 大表左连接
' W: w r! g7 N, b9 `3 Z大表左连接需求来源于淘宝收藏夹业务。简单来讲,收藏夹业务包含两张表 U2 ]2 y8 |6 k- P" W
格:收藏表collect_info以及商品表collect_item,其中,collect_info表存储了用户的收
: `2 K( i; |7 ]% x, t/ a. ^% O藏信息,比如收藏时间、标签等,collect_item存储了用户收藏的商品或者店铺的信
! a/ E) P0 I: x; H! k4 E7 m* M1 ?息,包括价格、人气等。collect_info的数据条目达到100亿条,collect_item的数据条
; {0 \) Z! s, X/ i; C6 x/ K$ p目接近10亿条,每个用户平均收藏了50~100个商品或者店铺。用户可以按照收藏时
# d7 j! k3 K7 Y$ Y( a* _; D间浏览收藏项,也可以对收藏项按照价格、人气排序。
2 \) u8 p3 g. M* j! G3 K自然想到的做法是直接采用关系数据库多表连接操作实现,即根据collect_info中1 d+ D6 @0 w5 e1 O/ f; @
存储的商品编号(item_id),实时地从商品表读取商品的价格、人气等信息。然- v0 H9 X% ~+ t* P# z
而,商品表数据量太大,需要分库分表后分布到多台数据库服务器,即使是同一个- @- J( A9 @ \" `9 i b
用户收藏的商品也会被打散到多台服务器。某些用户收藏了几千个商品或者店铺,
' i o- {$ F# R% L9 I/ {3 ^如果需要从很多台服务器读取几千条数据,整体延时是不可接受的,系统的并发能
, I% K U* ?' C: k, k7 B: P. K力也将受限。
, U. L0 {* W8 G) b5 G- @6 ]1 O5 C) F另外一种常见的做法是做冗余,即在collect_info表中冗余商品的价格、人气等信
- ?5 ~, j. c9 [9 v5 I5 V, d( m息,读取时就不需要读取collect_item表了。然而,热门商品可能被数十万个用户收
9 I5 i1 z; e1 H+ _8 g藏,每次价格、人气发生变化时都需要修改数十万个用户的收藏条目。显然,这是
% F i% v; D, o, U; U9 Y2 d$ L: g不可接受的。# D5 ` S6 W3 z F' z
这个问题本质上是一个大表左连接(Left Join)的问题,连接列为item_id,即右
/ N$ O+ \8 P/ N. S2 `, E& H; F表(商品表)的主键。对于这个问题,OceanBase的做法是在collect_info的基线数据. G+ b% ?0 U# X9 }
中冗余collect_item信息,修改增量中将collect_info和collect_item两张表格分开存储。
9 `, q; R+ Z% M v3 f* L$ }: b5 H# [商品价格、人气变化信息只需要记录在UpdateServer的修改增量中,读取操作步骤如6 T$ A* O I1 e, [
下:2 Y2 b; `9 J* q7 f
1)从ChunkServer读取collect_info表格的基线数据(冗余了collect_item信息)。
8 o( m; y6 `! U2)从UpdateServer读取collect_info表格的修改增量,并融合到第1)步的结果' C- @( T# x5 q8 q$ r+ [& C7 }
中。3 ^* i0 Y: \1 c$ h
3)从UpdateServer读取collect_item表格中每个收藏商品的修改增量,并融合到' l3 L, P: r1 |& w$ ^% {8 E
第2)步的结果中。1 L# U5 Z9 N* `' C: H
4)对第3)步生成的结果执行排序(按照人气、价格等),分页等操作并返回
6 {4 \0 E/ F% c5 D给客户端。5 |9 D F# T( q: ^% ]
OceanBase的实现方式得益于每天业务低峰期进行的每日合并操作。每日合并& }- x {$ v' ?2 Y% `$ r
时,ChunkServer会将UpdateServer上collect_info和collect_item表格中的修改增量融合0 e. W6 V/ u3 z( Q k- D! r
到collect_info表格的基线数据中,生成新的基线数据。因此,collect_info和+ s% q% ^3 U& h
collect_item的数据量不至于太大,从而能够存放到单台机器的内存中提供高效查询
: }- A" Q- y8 F服务。3 l0 Q0 m% Y$ o2 T z
10.5.2 数据过期与批量删除
" `& k7 J3 I# E9 z很多业务只需要存储一段时间,比如三个月或者半年的数据,更早之前的数据
: |6 `$ Y' {3 C$ u. n2 r可以被丢弃或者转移到历史库从而节省存储成本。OceanBase支持数据自动过期功
V7 ~. J" S- R6 F& Z! N$ d! |9 _能。8 }( f1 n% Y. R3 X4 O
OceanBase线上每个表格都包含创建时间(gmt_create)和修改时间1 P! e% D( J) p2 ~! ?
(gmt_modified)列。使用者可以设置自动过期规则,比如只保留创建时间或修改时 _4 v7 X2 A0 U9 {$ ?
间不晚于某个时间点的数据行,读取操作会根据规则过滤这些失效的数据行,每日
3 z. ]$ `: R" n Y合并时这些数据行会被物理删除。
" _) n1 B3 F. }, K0 O H批量删除需求来源于OLAP业务。这些业务往往每天导入一批数据,由于业务逻" b$ A* l/ ^' ~
辑复杂,上游系统很可能出错,导致某一天导入的数据出现问题,需要将这部分出
$ r( V9 C! K2 w& s' r1 `- U错的数据删除掉。由于导入的数据量很大,一条一条删除其中的每行数据是不现实: o/ d- A0 t( C. y. f: @- t
的。因此,OceanBase实现了批量删除功能,具体做法和数据自动过期功能类似,使
/ v! f+ m1 l3 @# W" Q5 D* ]用者可以增加一个删除规则,比如删除创建时间在某个时间段的数据行,以后所有
^. G ?- c, x! \( g0 q" e的读操作都会自动过滤这些出错的数据行,每日合并时这些出错的数据行会被物理6 u4 T; F2 C+ f1 M3 `
删除。
9 n6 E" ^5 j3 |/ Q8 r$ N' j. B) F3 k3 z8 y: d
: a/ B* S( Q+ I- B
|
|