|
10.5 特色功能
* N' @* u2 d( |) V5 O- n* W$ z虽然OceanBase是一个通用的分布式关系数据库,然而,在阿里巴巴集团落地过
- n0 g" Q3 f2 X6 I* ?. _9 d( ]2 ~程中,为了满足业务的需求,也实现了一些特色功能。这些功能在互联网应用中很! P' ~1 Q6 o8 a- Z a1 i
常见,然而,传统的关系数据库往往实现得比较低效。本节介绍其中两个具有代表' o, W+ a5 T6 A1 Y6 d" A: T% t
性的功能,分别为大表左连接以及数据过期与批量删除。% q4 b% B1 z% }
10.5.1 大表左连接. L' u/ G$ Y% g
大表左连接需求来源于淘宝收藏夹业务。简单来讲,收藏夹业务包含两张表" D0 l& c! h: C: U8 {
格:收藏表collect_info以及商品表collect_item,其中,collect_info表存储了用户的收
8 @, O% \7 R: f" |藏信息,比如收藏时间、标签等,collect_item存储了用户收藏的商品或者店铺的信3 j7 G$ b2 I: M! c3 o# ]; {
息,包括价格、人气等。collect_info的数据条目达到100亿条,collect_item的数据条- O% e) X5 p" j$ b# e+ c
目接近10亿条,每个用户平均收藏了50~100个商品或者店铺。用户可以按照收藏时
0 q! U" @6 ~. b间浏览收藏项,也可以对收藏项按照价格、人气排序。
+ k' B; @" k: i4 I. R A. X自然想到的做法是直接采用关系数据库多表连接操作实现,即根据collect_info中: m% E! f. ?8 b2 ?
存储的商品编号(item_id),实时地从商品表读取商品的价格、人气等信息。然
8 k# M+ C4 k6 b$ z7 v' g; Y8 }而,商品表数据量太大,需要分库分表后分布到多台数据库服务器,即使是同一个
: S: H3 _8 W; \" `# g) O- z! l用户收藏的商品也会被打散到多台服务器。某些用户收藏了几千个商品或者店铺,
' k7 @9 n; s X# c! m/ s L. m如果需要从很多台服务器读取几千条数据,整体延时是不可接受的,系统的并发能+ K! c' b' g0 t% Z8 g3 H
力也将受限。
5 [; f( I# h0 m" K另外一种常见的做法是做冗余,即在collect_info表中冗余商品的价格、人气等信 F% K* ]) H0 ~! q8 _
息,读取时就不需要读取collect_item表了。然而,热门商品可能被数十万个用户收* } k/ m- [/ Q& B8 m2 V. k4 j
藏,每次价格、人气发生变化时都需要修改数十万个用户的收藏条目。显然,这是, f& E+ c& P- w
不可接受的。
2 N" |8 B4 X- v( [7 W- ]这个问题本质上是一个大表左连接(Left Join)的问题,连接列为item_id,即右
8 d/ m' [, C# s9 ^/ V' B表(商品表)的主键。对于这个问题,OceanBase的做法是在collect_info的基线数据 D `! r5 y; d% ?0 }
中冗余collect_item信息,修改增量中将collect_info和collect_item两张表格分开存储。$ r; p* W5 x$ h+ ?8 Z% w
商品价格、人气变化信息只需要记录在UpdateServer的修改增量中,读取操作步骤如
5 y) {. Y" c6 A- b' @# V, s: g: h下:
) X7 D5 p* p% p' j; T* a1)从ChunkServer读取collect_info表格的基线数据(冗余了collect_item信息)。$ `) R6 u: A6 d- _. v+ P
2)从UpdateServer读取collect_info表格的修改增量,并融合到第1)步的结果: d' E- G/ e8 G# L4 t" A. d- F3 y
中。
5 h$ O% C3 B5 o3 d+ w# P/ u3)从UpdateServer读取collect_item表格中每个收藏商品的修改增量,并融合到; H& k- s7 C, E' e, b* t" F E7 Q
第2)步的结果中。9 i- B3 S: X$ y1 c, C* K
4)对第3)步生成的结果执行排序(按照人气、价格等),分页等操作并返回
; r$ w ^: |. e( O' f给客户端。
r" {$ z& L# HOceanBase的实现方式得益于每天业务低峰期进行的每日合并操作。每日合并! d9 X. \8 T' s! r3 z0 O3 [
时,ChunkServer会将UpdateServer上collect_info和collect_item表格中的修改增量融合: f9 r# Z) r4 q5 P. e
到collect_info表格的基线数据中,生成新的基线数据。因此,collect_info和* q) D5 A( f& d2 O0 `* a( I8 S
collect_item的数据量不至于太大,从而能够存放到单台机器的内存中提供高效查询0 L# q- |% W" V
服务。' J" J6 ?! X2 w) ^% ]2 N4 B
10.5.2 数据过期与批量删除2 z. G4 O* j% J6 @1 |* v5 E8 L. n. ^
很多业务只需要存储一段时间,比如三个月或者半年的数据,更早之前的数据
8 ^4 H- i7 H% _: _可以被丢弃或者转移到历史库从而节省存储成本。OceanBase支持数据自动过期功5 P2 X1 u; W7 ^
能。
. S4 Y- x7 b7 c8 K% ^OceanBase线上每个表格都包含创建时间(gmt_create)和修改时间' ^' p k" V; {& Q$ W, P3 ?4 Y& h
(gmt_modified)列。使用者可以设置自动过期规则,比如只保留创建时间或修改时
2 b; q% ?( o4 h: J间不晚于某个时间点的数据行,读取操作会根据规则过滤这些失效的数据行,每日. r# e. i- k; ^1 Y2 K
合并时这些数据行会被物理删除。
7 h2 d% o& N8 _( h2 H; }批量删除需求来源于OLAP业务。这些业务往往每天导入一批数据,由于业务逻
: K6 L: _; G6 I- B0 k" \7 a* i辑复杂,上游系统很可能出错,导致某一天导入的数据出现问题,需要将这部分出, i9 j8 j! \) I: i. A! ]+ s
错的数据删除掉。由于导入的数据量很大,一条一条删除其中的每行数据是不现实
5 ~0 f! y2 _" z. h3 n的。因此,OceanBase实现了批量删除功能,具体做法和数据自动过期功能类似,使
/ u9 Y: @' A6 K7 Y6 [, m用者可以增加一个删除规则,比如删除创建时间在某个时间段的数据行,以后所有
' m$ q7 y. o; W! c的读操作都会自动过滤这些出错的数据行,每日合并时这些出错的数据行会被物理
, t9 Y g: L+ k3 k删除。) O. H o! M# {7 T( D) h, d9 ^6 i
8 n% g, H7 l: ^( F: n3 _+ b& y( V
; ]& f* k7 I u6 U" t |
|