|
1 x! ^2 x' s7 s; b: h8 B0 e& c
引入 | 图解那些分布式数据库中的 DBMS 1 h2 k a6 D. g& C9 C! t: S4 D
@! {6 C# r) j
5 T9 e! F x) C( `) F+ Q R+ u 开篇：想必大家都有一个疑问？何为分布式数据库？OLTP，OLAP，HTAP？它又能够给我们带来什么？ * O% Y$ p( i1 Y& `/ r, J+ _/ P
A0 G. _1 |: Y; z$ X. R
背景：在数据库技术 DBMS 领域，尤其是针对其中很多核心技术组成部分攻关的突破，国产化数据库一直都起着模范带头作用。许多国内互联网公司，包括现在很多成熟的技术框架，数据库都来自于国外。早期，依赖于核心技术的引进，在引进的基础上做上层应用，进而不断迭代。而现在核心技术自研，数据库自研等成了技术攻关的新浪潮。阿里曾一直提出“去 IOE ”的概念-其中 IBM 是服务器提供商，Oracle 是数据库软件提供商，EMC 则是存储设备提供商。
" x/ q! ?: g9 |) A8 ] 思考：
- c8 n9 D1 ] j- x5 j( b0 b 1、当使用 K8、Docker 容器化编排技术受到限制，假若 Oracle、MySql 数据存储等数据库软件不再向我们提供正常的服务？ 2 [" ]- F, Z- O5 G4 m5 g( X
2、在我们的项目工程中，若是没有了这些数据库技术去提供正常的服务，如何能够去及时地采取补救的措施，使得业务能够平滑过渡，做到让用户无感知体验？ $ X, M2 X7 `0 ?; J1 z9 A: B
3、从传统关系型数据库到非关系型数据库，NOSQL ，NewSQL 再到数据湖，以及兼顾 OLAP 跟 OLTP 的各种分布式数据库-HTAP（混合事务/分析处理），在拥有自己的数据存储解决方案基础之上，现有技术框架体系是否能够较好适配，能否做到更好地兼容？ , c5 c9 c0 w7 v' w. O
场景：在现有渠道产品上的适配，推进国产化数据库进程，包括信创自主可控等领域，都值得作为技术人的我们去深思......
; x. }1 ^2 B( J1 Z0 t1 S 诚然，技术多元化是一个趋势，多语言并存，多数据库适配，多环境兼容...... - q" X, W& D+ c6 F- s3 j
现状：Oracle，ElasticSearch，MySQL 架构
; v7 G+ U8 l" B3 w$ Q 目前，在 Oracle 中多个业务库中，数据规模已经非常庞大，MySQL 中多个业务库，其单表数据量都已超过千万级别，数据每天在不断的增长...... 6 ~# Z9 M9 N9 G1 {, w
( J* n& t$ b4 x* f& }) Y
尤其，在许多老旧的项目中，Oracle 视图数据量非常大，DMP 文件数百G，数据存储成本极其昂贵，这里也提供下大数据量的一些数据库导入导出方式（相比较工具导入导出或许速度更快一个数量级）
, m( `: I/ A! f* J. e, g MySQL：
5 W! v s- J! Y ^5 K, x+ l2 K 备份数据库命令：
3 f4 d/ N* o# p5 y6 b/ C mysqldump -u root -p 数据库名 > /home/user/2021.12.26.sql;; \% Z/ C- V- }" b$ a+ m
; g9 N) B) Z. H0 { z# p8 d 只需导出表结构： - g8 I3 y5 c7 x9 M; Y4 W
mysqldump -u applyun -p -d bi > /home/applyun/bi.sql;7 E9 w" R" g. D1 W
* Q0 G% O6 ~" Q- ]7 ?
数据库迁移导入：
9 v- V2 H* e6 x6 w. t$ r$ s, I mysql -u root -p 数据库名 < /home/user/2021.12.26.sql;
O/ f; K! t' ~) h( {" D0 v
6 Z1 m- D" F; D2 s# x, D. ^ Oracle：
% S/ X8 e7 r4 X4 Q5 J! f 数据库迁移导入： + c. Q: b$ h4 ]3 S) E
imp yd_dev_tmp/user@ip/orcl file=/home/oracle/xxx.dmp ignore=y full=y;( a3 N; \1 P. o
. S8 ^' ^, j( A6 w
- `1 z" y( `. g1 l y: U 成功导入数据泵. dmp 文件。（其中，可通过su - oracle进入oracle目录，dmp文件可上传到/home/oracle路径）
( |. t5 s0 m3 M6 Y) P9 P9 ~8 M) B 猜想： 6 n! k" {# B2 W) r
当下的数据库技术体系，正如春秋时期百家争鸣的局面，已然无法像传统关系型数据库那样三足鼎立，各个大厂，尤其是互联网，根据其自身业务需求体系定制化了很多产品，像 OceanBase ，TiDB ，Vertica，ClickHouse，Greenplum......
! o# X5 Q3 S. T3 i 那么，拥有这么多的选择权，是不是意味着学习的成本会不断抬高，我们需要了解扩充的知识面更多？上述仅列举了正在项目中移植预研的几款 DBMS，更多详情请回顾->数仓进阶 | 记一次OLAP分析引擎演进思考过程 / a2 {( ~* n. b, D( W a1 I$ _
构思：
4 @# J1 R1 o* o. @$ o* D# Y 当我们的业务系统发展到一定规模，不论是累计数据量，亦或用户并发量。早期，通过单体架构进行设计，应付自如，再大就是分库分表，解决数据库单点瓶颈（I/O）。
- [+ K& V+ A+ N( ]1 S 随着业务持续发展，单机有着明显的单点效应，并且单机的容量跟性能都是极其局限的。
1 @# h: z* E; F/ W" ?+ c% B( n 进一步，对某些应用进行水平扩容，渐渐的，虽然各个应用服务器CPU都正常，但是你会发现还是有很多慢请求依然存在，究其缘由-单点数据库性能瓶颈？ 4 |' X' ]2 X) `; R: f
更进一步，数据库集群-主从架构，大部分读操作可直接访问从库，减轻主库的负担，但依旧还是无法解决主库写的瓶颈？ 1 A9 v- O# e* [) D+ ^
接下来，就是上述提到的分库分表，分库分表可作水平拆分-对表进行进一步拆分，垂直拆分-不同功能表放置不同的库，按业务功能进行拆分。
+ a9 J f, `( c& t% O 然而，当相同的应用扩展越多，每个数据库的链接数，长久以往必会让数据库本身的资源再度成为瓶颈，简言之，资源隔离性依然不彻底->未形成单元化的雏形。 . K' W8 V# x9 M& n! |1 f' x: X8 {
6 g _0 l7 |% h" _6 Z
再谈经典， ; N5 c( M4 [4 x! K8 ^( c
Google 三驾马车，在分布式系统工程实践领域： 0 O0 R" O% X/ k. B
《Google File System》、《Google MapReduce》、 5 I0 q+ u B7 Z- ?
《Google BigTable》在很大程度上奠定了业界大规模分布式存储系统的理论基础. 9 ~: z& j( U- q
回到 CAP 理论，想必在分布式领域中这个著名的定理都有所耳闻，即 C 为数据一致性，A 为服务可用性，P 为服务对网络分区故障的容错性。
( e1 }- D/ u1 ~7 K 谈及 CAP，这里暂不详赘，各有各自不同深度层次的见解，但这里需要说明下的就是选择 CP 的分布式系统，并不代表可用性就完全没有了，比如像我们常用的中间件，为了增加可用性保障，往往提供了分片集群-复制的一些方案。 + {$ C% j" |1 H) j+ w) D
包括常说的 BASE 理论-对 CAP 理论的延伸，核心思想-即使无法做到强一致性（Strong Consistency），但我们的应用可以采用适合的方式达能够到最终一致性（Eventual Consitency）。 / v9 h0 P0 O9 C9 Q( a* _1 h6 I
从上述提到由单点现状->分布式架构演进构思的过程中，出现诸多不同阶段性痛点，想必这也是为什么那么多分布式数据库产品如雨后春笋般不断涌出？ . P$ Z/ M0 \5 W# Z. B; d' ^2 _
OceanBase-中国第一款自主研发的分布式数据库（简称OB）
0 ]+ w2 m4 q5 y; c, J 企业级分布式关系数据库
# M( I, S ]* q% m/ {2 f# e a）数据强一致 + J: s2 A8 p! V3 M, ?! `) p0 L
b）高可靠 2 d {3 o, ?. I* b# o
分区-副本机制
* {+ U( R& ?, W! x, D) g c）高性能 / K- f y1 B5 n* D/ M0 a
Paxos协议，在数据强一致的情况下，具有极高的可用性及性能
, ~* D$ n, R$ ]; ^/ u ^ d）在线扩展
2 r4 m# B) O5 G. \' I: h 当集群存储容量或是处理能力不足时，可以加入新的 OBServer
# u% j" d7 v+ ~3 v, E e）高度兼容 SQL 标准和主流关系数据库
$ [, |& @. k/ M' G8 U8 @; s f）低成本
* v8 v$ G: s# j. w8 s CPU、操作系统、数据库
3 n" \+ A, U `# K8 U 如何既兼顾处理 TP 场景的能力，又具备 AP 场景的分析能力？
& O) H4 a! K1 t. A 想必 HTAP 架构希望打破 TP 和 AP 的边界，虽然存在很多技术难关需要攻克，一直在路上，期待 OceanBase（OB）一直会有新的突破...... 7 O, C2 [: ^/ m+ J
延伸思考：HTAP（混合事务/分析处理），相比 OLTP、OLAP 能够给我们带来？OceanBase 又是如何支持 HTAP？
" @) |2 D3 U- r" u 在高并发海量数据场景下，是否能让系统中诸多计算节点同时运行 OLTP 类型的应用和复杂的 OLAP 类型的应用......
" [7 H2 A/ \6 J6 r9 @$ D/ l+ X6 }3 W" I% P, O
' p1 @% z B1 a: G( f/ ~+ X
4 F$ m2 w# q6 ^3 s' V# P2 i) q6 ?2 \5 z& ]1 w( t
| 
