|
" a6 Z( @8 ~2 a1 G5 e
引入 | 图解那些分布式数据库中的 DBMS
Y& X1 B. [/ `
; Z2 S& T6 f' a) g4 I. Z " D- A9 X) V7 E+ l" m' W
开篇：想必大家都有一个疑问？何为分布式数据库？OLTP，OLAP，HTAP？它又能够给我们带来什么？
8 Z! I, M* L4 g2 y/ a" a
. l% I7 p9 @& k1 d# k p 背景：在数据库技术 DBMS 领域，尤其是针对其中很多核心技术组成部分攻关的突破，国产化数据库一直都起着模范带头作用。许多国内互联网公司，包括现在很多成熟的技术框架，数据库都来自于国外。早期，依赖于核心技术的引进，在引进的基础上做上层应用，进而不断迭代。而现在核心技术自研，数据库自研等成了技术攻关的新浪潮。阿里曾一直提出“去 IOE ”的概念-其中 IBM 是服务器提供商，Oracle 是数据库软件提供商，EMC 则是存储设备提供商。 % S$ \) o _' x& Z$ Q/ W: x- j7 I
思考：
7 I: V6 ?6 n: X( k" V" G; I/ E 1、当使用 K8、Docker 容器化编排技术受到限制，假若 Oracle、MySql 数据存储等数据库软件不再向我们提供正常的服务？ & r7 T9 Z# o! O# B$ i
2、在我们的项目工程中，若是没有了这些数据库技术去提供正常的服务，如何能够去及时地采取补救的措施，使得业务能够平滑过渡，做到让用户无感知体验？ 5 O4 O, e6 ]1 A9 R* M
3、从传统关系型数据库到非关系型数据库，NOSQL ，NewSQL 再到数据湖，以及兼顾 OLAP 跟 OLTP 的各种分布式数据库-HTAP（混合事务/分析处理），在拥有自己的数据存储解决方案基础之上，现有技术框架体系是否能够较好适配，能否做到更好地兼容？
6 B4 N0 l3 L" Q8 I. | 场景：在现有渠道产品上的适配，推进国产化数据库进程，包括信创自主可控等领域，都值得作为技术人的我们去深思......
% l$ h8 f) A% _* q% O% \ 诚然，技术多元化是一个趋势，多语言并存，多数据库适配，多环境兼容......
6 e& Q) P/ J8 e( y4 m7 T2 j8 E 现状：Oracle，ElasticSearch，MySQL 架构 ' S1 o6 O" R: L8 X9 N4 M v' h
目前，在 Oracle 中多个业务库中，数据规模已经非常庞大，MySQL 中多个业务库，其单表数据量都已超过千万级别，数据每天在不断的增长...... * Y% i, s. W1 g* Y6 p' D( E' C
. K8 F, g8 T$ b7 f* c7 P6 I& H
尤其，在许多老旧的项目中，Oracle 视图数据量非常大，DMP 文件数百G，数据存储成本极其昂贵，这里也提供下大数据量的一些数据库导入导出方式（相比较工具导入导出或许速度更快一个数量级）
% k$ h4 V7 z& N! ? MySQL： * h2 h; ^0 J2 K: S! p7 m/ P
备份数据库命令： $ D: j5 m1 K% {* B7 r/ R3 Y7 c; S
mysqldump -u root -p 数据库名 > /home/user/2021.12.26.sql;. V( x) y% x7 S, k, K
/ V7 P, }% Q" C- J
只需导出表结构：
' t& J" N: n1 e' S0 W mysqldump -u applyun -p -d bi > /home/applyun/bi.sql;
/ z. f0 z* t9 L. a* B5 K
/ F! y; \% G2 f( V- Q P 数据库迁移导入：
! e* i9 F& o( ` f mysql -u root -p 数据库名 < /home/user/2021.12.26.sql;
: y s2 \' t$ k7 f! t& R
* V" p! c: l0 _2 ]' X( j, I3 s% [ Oracle：
5 a1 a* X" F! @, S$ o# H: U 数据库迁移导入： 1 O" z9 Q' R. P i& [
imp yd_dev_tmp/user@ip/orcl file=/home/oracle/xxx.dmp ignore=y full=y;+ s6 ?- n" T1 W6 H3 z4 y \
) C' B1 U c+ K- w" t1 l
% u! P+ v6 r5 ~: ` \$ { 成功导入数据泵. dmp 文件。（其中，可通过su - oracle进入oracle目录，dmp文件可上传到/home/oracle路径）
. M4 S f+ P' } 猜想： $ s8 _+ S. o K @+ H( `
当下的数据库技术体系，正如春秋时期百家争鸣的局面，已然无法像传统关系型数据库那样三足鼎立，各个大厂，尤其是互联网，根据其自身业务需求体系定制化了很多产品，像 OceanBase ，TiDB ，Vertica，ClickHouse，Greenplum......
$ |8 y* s' [7 T9 P& p; s 那么，拥有这么多的选择权，是不是意味着学习的成本会不断抬高，我们需要了解扩充的知识面更多？上述仅列举了正在项目中移植预研的几款 DBMS，更多详情请回顾->数仓进阶 | 记一次OLAP分析引擎演进思考过程 % l7 t6 ]5 ]2 H
构思： % h% U- M' G' ?) s
当我们的业务系统发展到一定规模，不论是累计数据量，亦或用户并发量。早期，通过单体架构进行设计，应付自如，再大就是分库分表，解决数据库单点瓶颈（I/O）。
. h8 {5 q' Y) Z0 F! b' m# |7 Z 随着业务持续发展，单机有着明显的单点效应，并且单机的容量跟性能都是极其局限的。 O1 N" E1 c8 d. a) o% F
进一步，对某些应用进行水平扩容，渐渐的，虽然各个应用服务器CPU都正常，但是你会发现还是有很多慢请求依然存在，究其缘由-单点数据库性能瓶颈？
+ R3 V4 Q/ W2 D9 Y# M n# {8 ^4 r 更进一步，数据库集群-主从架构，大部分读操作可直接访问从库，减轻主库的负担，但依旧还是无法解决主库写的瓶颈？
/ f) k0 X0 _( x: _, U 接下来，就是上述提到的分库分表，分库分表可作水平拆分-对表进行进一步拆分，垂直拆分-不同功能表放置不同的库，按业务功能进行拆分。 ; p+ M. @9 r& o) @& f) Q
然而，当相同的应用扩展越多，每个数据库的链接数，长久以往必会让数据库本身的资源再度成为瓶颈，简言之，资源隔离性依然不彻底->未形成单元化的雏形。
9 T# a. {: ?6 G
% q/ c8 B9 d. L# Z& J# N) B 再谈经典， 0 O' V, d/ `* b j
Google 三驾马车，在分布式系统工程实践领域：
! k+ A" G' B- E& d/ R& \* v7 U 《Google File System》、《Google MapReduce》、
9 _' n$ K1 L1 b9 k 《Google BigTable》在很大程度上奠定了业界大规模分布式存储系统的理论基础.
5 ?1 H; K9 t1 h: C* \' a 回到 CAP 理论，想必在分布式领域中这个著名的定理都有所耳闻，即 C 为数据一致性，A 为服务可用性，P 为服务对网络分区故障的容错性。
. B9 n9 ^9 b4 ` q: s1 B& W8 j& A 谈及 CAP，这里暂不详赘，各有各自不同深度层次的见解，但这里需要说明下的就是选择 CP 的分布式系统，并不代表可用性就完全没有了，比如像我们常用的中间件，为了增加可用性保障，往往提供了分片集群-复制的一些方案。
7 N- b7 N- u: O- ?1 W 包括常说的 BASE 理论-对 CAP 理论的延伸，核心思想-即使无法做到强一致性（Strong Consistency），但我们的应用可以采用适合的方式达能够到最终一致性（Eventual Consitency）。 0 E" p3 @! e# h$ f
从上述提到由单点现状->分布式架构演进构思的过程中，出现诸多不同阶段性痛点，想必这也是为什么那么多分布式数据库产品如雨后春笋般不断涌出？
) C5 h9 A" M( c# q OceanBase-中国第一款自主研发的分布式数据库（简称OB）
6 {: V6 Z# @2 R- k$ B2 r 企业级分布式关系数据库
3 x4 o `* _* i0 G a）数据强一致
' i6 b4 y6 D' j8 ^$ Y8 x. y0 t b）高可靠 1 x. W( L& H) b) q3 R
分区-副本机制
. _# l7 G* C0 y' p c）高性能 2 [* c7 x5 L2 t; S' f5 @
Paxos协议，在数据强一致的情况下，具有极高的可用性及性能 ) ?, c1 ]5 ?1 U8 U% G. g
d）在线扩展
# ^: {- q0 W4 H6 {- `2 D- b {' d7 z 当集群存储容量或是处理能力不足时，可以加入新的 OBServer
/ r0 S9 A9 s$ c6 J0 ~, z2 j6 S e）高度兼容 SQL 标准和主流关系数据库
, e* h* ^7 W- i f）低成本 ' @- l- X: f! w1 i
CPU、操作系统、数据库
+ |" z' k0 I# h* _( [7 g 如何既兼顾处理 TP 场景的能力，又具备 AP 场景的分析能力？
) Y+ w8 V( M1 a& y 想必 HTAP 架构希望打破 TP 和 AP 的边界，虽然存在很多技术难关需要攻克，一直在路上，期待 OceanBase（OB）一直会有新的突破......
+ y; M& r$ j7 k f$ F 延伸思考：HTAP（混合事务/分析处理），相比 OLTP、OLAP 能够给我们带来？OceanBase 又是如何支持 HTAP？
) j# |% s* H9 y$ i6 m 在高并发海量数据场景下，是否能让系统中诸多计算节点同时运行 OLTP 类型的应用和复杂的 OLAP 类型的应用......
6 J$ H% A* F% h5 g2 x( N" r
' K2 H1 G$ t, ~! b- L0 S, l, c( F3 M
. Z- o4 r/ @" s1 ?6 N/ H9 {
& ?4 t: l$ i! O3 G( ]6 _8 `' f | 
