数据库画像,怎么做?

有关SQL

共 1771字,需浏览 4分钟

 ·

2021-01-15 13:52

点击蓝色“有关SQL”关注我哟

加个“星标”,天天与10000人一起快乐成长

图 | L



2008年,阿里提出去[IOE]的口号;

2014年,12306,去O上云;

2017年,联通首次3省去O上云;

2019年,陆金所脱O;

这里的O是指 Oracle 数据库。为什么脱[ O ],并不是本文重点。怎么脱才是!

大约2008年,那时我还在MES/ERP开发岗位上,做得热火朝天。foxpro + sql server 2000 的编程玩得如鱼得水。何止996,007我都愿意,单身有时间。


突然有一天,接到主管通知:

“ 大家准备下,我们要换 Oracle 了” 

“啥子是 Oracle” 

“宇宙最强数据库”

至今我还记得主管一脸憨笑。希望他也会记得我那张便秘的脸。


换就换咯,那怎么换呢,一张张表自己去建,自己去导数据么。后续我也不知道,谁拿钱谁做,反正我没拿到。既然项目是迁移完了,那肯定是有人做了的。一个信息办公室都你我大眼瞪小眼,别问了,谁都没做,是外包公司干的。

切到Oracle之后,我也没多想。反正不难吧。直到最近,看到这本书《Efficient Database Optimization -Architecture, Specification and SQL Skills》 又名《数据库高效优化》,我才想起来,异构数据库迁移,这事儿真没想过,可能真不是原本我想的那么简单。

去 O,你想好了?

从2008年喊口号去IOE,到现在2021年了,13年过去了,你们的 Oracle 还活着吗,如果要迁移,会做哪些工作呢?

  • 评估迁移风险和工期
  • 设计新架构
  • 边设计边测试边上线

那这里面哪部分最重要呢?显然没第一步,往下都不能存在。如何有效评估风险和工期是难点。一定要迁移数据库的话,数据库画像跑不了。

具体来说,数据库画像可以分为这三个部分:

  • 数据库物理结构
  • 运行时统计信息
  • SQL 审核总结

干说,太抽象。我不想你们中途离场,所以先放个图,再解说。没耐心的,看个大概就行。后面有代码,直接上手撸。

后台回复“数据库画像”,拿Python代码,自制画像。该版权属于PingCAP

说明:挑重点讲,不废话

数据库物理结构:除了数据库本身的存储大小,尤其还要注意收集每日甚至每小时增量。增量统计信息,直接影响容量策略和备份策略

运行时统计信息:都知道Oracle有强悍的RAC集群,如果新切换的数据库不能支撑那么大的并发,其实架构是有很大必要调整的。比如分库,分表,读写分离。

SQL审核总结:这是预估工作量最难的地方。比如超长的SQL数量,PL/SQL方言的SQL有多少,3个表以上Join的SQL有多少,等等,都将影响工作量的评估。

以下规则,来自于 PingCAP: https://github.com/bjbean/oracle-estimate-report 你有权自定义各类阈值。


规则说明 
· * 大表判断规则1_物理大小: 1000 M 
· * 大表判断规则2_记录数: 1000000 
· * SQL超长标准: 200 字符 
· * ANTI SQL: 指包含关键字(not in、not exist)的语句 
· * Oracle Syntax SqL: 指包含关键字(rowid、rownum、decode、partition、rullup、cube、sampling、rank、percentile、ntitle、top、bottom、period、lead、lag的语句 
· * Join 3+ Table SQL: 关联3个及3个以上表的语句 
· * SubQuery SQL: 包含子查询的语句 


当有一天,你的老板也向你提出,“哎,我们把Oracle换了吧,怎么样?”我希望这篇文章,可以给你一些灵感。



--完--





往期精彩:


本号精华合集(三)

如何写好 5000 行的 SQL 代码

如何提高阅读 SQL 源代码的快感

我在面试数据库工程师候选人时,常问的一些题

零基础 SQL 数据库小白,从入门到精通的学习路线与书单












浏览 39
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报