数据库画像,怎么做?
共 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换了吧,怎么样?”我希望这篇文章,可以给你一些灵感。
往期精彩: