|
2 |, l+ s6 f9 r 引入 | 图解那些分布式数据库中的 DBMS
2 p( ~$ H* J& W/ {- z % t* ]' {& i8 t
( p1 {2 x% }. ^% }- c5 ~- o) w% _ 开篇：想必大家都有一个疑问？何为分布式数据库？OLTP，OLAP，HTAP？它又能够给我们带来什么？
6 M) x7 P' M* G: Y
* X8 m" I" w" k7 C& H 背景：在数据库技术 DBMS 领域，尤其是针对其中很多核心技术组成部分攻关的突破，国产化数据库一直都起着模范带头作用。许多国内互联网公司，包括现在很多成熟的技术框架，数据库都来自于国外。早期，依赖于核心技术的引进，在引进的基础上做上层应用，进而不断迭代。而现在核心技术自研，数据库自研等成了技术攻关的新浪潮。阿里曾一直提出“去 IOE ”的概念-其中 IBM 是服务器提供商，Oracle 是数据库软件提供商，EMC 则是存储设备提供商。
! Z" P& w8 |" p 思考：
; N. h3 M5 [6 n# k" M4 N0 b 1、当使用 K8、Docker 容器化编排技术受到限制，假若 Oracle、MySql 数据存储等数据库软件不再向我们提供正常的服务？
/ j( W) V3 z+ h# n3 N4 } 2、在我们的项目工程中，若是没有了这些数据库技术去提供正常的服务，如何能够去及时地采取补救的措施，使得业务能够平滑过渡，做到让用户无感知体验？ - w3 M& ^5 n0 o, N
3、从传统关系型数据库到非关系型数据库，NOSQL ，NewSQL 再到数据湖，以及兼顾 OLAP 跟 OLTP 的各种分布式数据库-HTAP（混合事务/分析处理），在拥有自己的数据存储解决方案基础之上，现有技术框架体系是否能够较好适配，能否做到更好地兼容？
, F8 z4 y3 {. }& H" o3 s9 \ 场景：在现有渠道产品上的适配，推进国产化数据库进程，包括信创自主可控等领域，都值得作为技术人的我们去深思......
* n9 J3 F9 V; Z3 T5 q 诚然，技术多元化是一个趋势，多语言并存，多数据库适配，多环境兼容...... % O7 r1 j3 J3 R, E1 \
现状：Oracle，ElasticSearch，MySQL 架构
( ?, R1 W; [' P& B3 d 目前，在 Oracle 中多个业务库中，数据规模已经非常庞大，MySQL 中多个业务库，其单表数据量都已超过千万级别，数据每天在不断的增长......
6 Z! l! n" m l6 P$ B2 B; _ ( M c" c+ `! s) k
尤其，在许多老旧的项目中，Oracle 视图数据量非常大，DMP 文件数百G，数据存储成本极其昂贵，这里也提供下大数据量的一些数据库导入导出方式（相比较工具导入导出或许速度更快一个数量级）
; B0 a- w; ]3 V' W7 A- R4 x6 h MySQL： 5 Q" I/ g* Y! l# V3 r9 [( t* j3 B
备份数据库命令： * B( \( g( {$ A d, n, a; ~
mysqldump -u root -p 数据库名 > /home/user/2021.12.26.sql;# \0 S2 k4 Z+ F3 v
/ o4 s4 R" t G: }6 `) u
只需导出表结构：
+ v4 i C7 S. M0 S* z: v; F mysqldump -u applyun -p -d bi > /home/applyun/bi.sql;' a7 D) E- e0 m' g5 N) r
6 L" f7 K9 Y) }4 ? G 数据库迁移导入：
8 Q6 |+ }( e: a2 t" ^ mysql -u root -p 数据库名 < /home/user/2021.12.26.sql;- K H5 J9 C8 E* W9 j
0 C1 O$ c. W7 O& R4 S5 ?) C; }- R0 d
Oracle： : @. t: W/ [3 Z4 }& |
数据库迁移导入：
9 ?$ w' W9 Q' S6 R- G8 `# `) X imp yd_dev_tmp/user@ip/orcl file=/home/oracle/xxx.dmp ignore=y full=y;+ |% Y1 b4 a& Y, B# l h* R
% d0 H/ e- K }8 y/ G8 a / Z; j) [. o6 H2 `7 b
成功导入数据泵. dmp 文件。（其中，可通过su - oracle进入oracle目录，dmp文件可上传到/home/oracle路径） 0 O0 f v6 n% s' r
猜想：
" y- _4 W, u9 z8 a4 O9 B9 H 当下的数据库技术体系，正如春秋时期百家争鸣的局面，已然无法像传统关系型数据库那样三足鼎立，各个大厂，尤其是互联网，根据其自身业务需求体系定制化了很多产品，像 OceanBase ，TiDB ，Vertica，ClickHouse，Greenplum...... 2 x, q5 A% G9 `* R G, i
那么，拥有这么多的选择权，是不是意味着学习的成本会不断抬高，我们需要了解扩充的知识面更多？上述仅列举了正在项目中移植预研的几款 DBMS，更多详情请回顾->数仓进阶 | 记一次OLAP分析引擎演进思考过程
) p' k2 G/ I9 Y7 d' l- g0 } 构思： 8 ]4 Z7 W3 d$ A) M' g5 o7 i# A
当我们的业务系统发展到一定规模，不论是累计数据量，亦或用户并发量。早期，通过单体架构进行设计，应付自如，再大就是分库分表，解决数据库单点瓶颈（I/O）。
* s y' T/ {& }! i+ n* \& E& ~% W 随着业务持续发展，单机有着明显的单点效应，并且单机的容量跟性能都是极其局限的。
+ w" o7 B8 i# h& g3 d 进一步，对某些应用进行水平扩容，渐渐的，虽然各个应用服务器CPU都正常，但是你会发现还是有很多慢请求依然存在，究其缘由-单点数据库性能瓶颈？
9 C4 R" f- f- _& {2 H! x 更进一步，数据库集群-主从架构，大部分读操作可直接访问从库，减轻主库的负担，但依旧还是无法解决主库写的瓶颈？ 2 U' O7 l# t: j! b: D" R) O
接下来，就是上述提到的分库分表，分库分表可作水平拆分-对表进行进一步拆分，垂直拆分-不同功能表放置不同的库，按业务功能进行拆分。
% v* Z7 N0 t+ z$ C. u6 J# d% u7 Y5 k 然而，当相同的应用扩展越多，每个数据库的链接数，长久以往必会让数据库本身的资源再度成为瓶颈，简言之，资源隔离性依然不彻底->未形成单元化的雏形。
4 N* p% L% A3 O " ^6 Y3 d. E, ]" N/ U
再谈经典， 1 j' c y0 t A% W) y
Google 三驾马车，在分布式系统工程实践领域： , a$ X/ [ s/ w: z, R. o
《Google File System》、《Google MapReduce》、 9 z P: h4 @' G* X% a( ?
《Google BigTable》在很大程度上奠定了业界大规模分布式存储系统的理论基础. : m6 ^& A* Z# p# {3 S v$ ^0 x
回到 CAP 理论，想必在分布式领域中这个著名的定理都有所耳闻，即 C 为数据一致性，A 为服务可用性，P 为服务对网络分区故障的容错性。
- q- D1 ?6 r6 [ 谈及 CAP，这里暂不详赘，各有各自不同深度层次的见解，但这里需要说明下的就是选择 CP 的分布式系统，并不代表可用性就完全没有了，比如像我们常用的中间件，为了增加可用性保障，往往提供了分片集群-复制的一些方案。 . @0 R* a( J7 F# _9 [: h, X& ~
包括常说的 BASE 理论-对 CAP 理论的延伸，核心思想-即使无法做到强一致性（Strong Consistency），但我们的应用可以采用适合的方式达能够到最终一致性（Eventual Consitency）。
/ E- H" `! g7 w$ }9 \5 m4 v+ F& n 从上述提到由单点现状->分布式架构演进构思的过程中，出现诸多不同阶段性痛点，想必这也是为什么那么多分布式数据库产品如雨后春笋般不断涌出？ . U$ C4 c; R6 Z5 k* c
OceanBase-中国第一款自主研发的分布式数据库（简称OB）
S, W5 v/ u: } }8 k 企业级分布式关系数据库
5 P/ d( i# T; O7 x1 H# Y; ]9 t a）数据强一致 - W9 Z+ d6 {( G- A$ I: d: F1 B
b）高可靠
9 ]) q6 |' Y% o. }9 _5 j. G 分区-副本机制 3 ]( Y3 M9 L$ e
c）高性能 % k- y0 K- e! D) t5 l/ x
Paxos协议，在数据强一致的情况下，具有极高的可用性及性能 C/ H Y6 a8 f4 c/ Q9 v
d）在线扩展 % }* }3 i: j1 C" q, T
当集群存储容量或是处理能力不足时，可以加入新的 OBServer ( c6 A5 E6 F3 W% A
e）高度兼容 SQL 标准和主流关系数据库
v9 |- X1 z. X/ b5 V& u7 w' o f）低成本 ( s% t& Z. {# b" ]+ ]9 M' x# _* J/ N
CPU、操作系统、数据库
9 W: o3 s5 _# d3 h, u' a6 y 如何既兼顾处理 TP 场景的能力，又具备 AP 场景的分析能力？ 2 N0 @8 K3 |% \ w/ Z' n3 M# y
想必 HTAP 架构希望打破 TP 和 AP 的边界，虽然存在很多技术难关需要攻克，一直在路上，期待 OceanBase（OB）一直会有新的突破......
. U4 }) |- C6 X) q 延伸思考：HTAP（混合事务/分析处理），相比 OLTP、OLAP 能够给我们带来？OceanBase 又是如何支持 HTAP？
5 h( u0 n* y2 s$ ]* F' o 在高并发海量数据场景下，是否能让系统中诸多计算节点同时运行 OLTP 类型的应用和复杂的 OLAP 类型的应用...... 9 A& j% a% ~: D5 R- R; q8 s
% P6 P5 J! ?$ G* v4 G$ H$ A/ e) N# F, Y i$ n
/ s+ o* C. E. K* f
0 E2 G X* k* I$ @% c0 {9 I4 n | 
