導(dǎo)讀

“

去IOE，最近這幾年比較火的話題，市場上也有不少成功的案例。也有不少企業(yè)也想去Oracle，今天就聊一聊去Oracle 有哪些難題？

Top1 Oracle 太強

Oracle 和MySQL對比（或其他開源數(shù)據(jù)庫）。不客氣的說Oracle 相對其他數(shù)據(jù)庫，功能或者SQL優(yōu)化器方面遙遙領(lǐng)先。

例如：MySQL8.0才開始執(zhí)行hash join。

高可用 Oracle 有rac 穩(wěn)的一逼。

#現(xiàn)在的MySQL8.0 能和Oracle的9i持平就很不容易了。

“

推薦一個艿艿寫的 6000+ Star 的 SpringBoot + SpringCloud + Dubbo 教程的倉庫：https://github.com/YunaiV/SpringBoot-Labs

Top2 Oracle的存儲過程觸發(fā)器對開發(fā)人員太友好

很多業(yè)務(wù)開發(fā)，把業(yè)務(wù)的邏輯封裝到Oracle的存儲過程，觸發(fā)器中了。

這樣會簡化業(yè)務(wù)邏輯代碼，Java的程序員只要調(diào)用接口即可。

而MySQL首先就是要禁用存儲過程、觸發(fā)器、視圖。

#enmmm 要執(zhí)行去Oracle 就得把這一些存儲過程、觸發(fā)器，轉(zhuǎn)換為業(yè)務(wù)的代碼。

Top3 開發(fā)人員的思想

因為上述原因，oracle的功能、觸發(fā)器、存儲過程等等要強于MySQL。

開發(fā)人員可能默認(rèn)數(shù)據(jù)庫可以搞定一切，實在不行上“一體機”。

秒殺、AP類的SQL、各種都可以往數(shù)據(jù)庫里面懟，Oracle都懟進(jìn)去了MySQL也可以懟進(jìn)去。

#redis不就是存存儲Session...

“

推薦一個艿艿寫的 3000+ Star 的 SpringCloud Alibaba 電商開源項目的倉庫：https://github.com/YunaiV/onemall

Top4 沒操作過沒信心

對應(yīng)Oracle to MySQL這個操作而言不僅僅涉及到單獨的數(shù)據(jù)，還涉及到業(yè)務(wù)的改造。

往往不是一個部門就能絕對的事，因為沒信心沒實際操作過。

會有風(fēng)險擔(dān)心（這點沒毛病），對于未知的事務(wù)本應(yīng)該有敬畏之心。

這點可以在小的不重要的業(yè)務(wù)先練練手。多部門直接配合多磨煉磨煉。

也對其他組件多多了解。

還有對操作過程中引發(fā)故障的擔(dān)當(dāng)。

Top5 技術(shù)儲備不足

本身的技術(shù)儲備不足，基礎(chǔ)平臺沒完善。例如Redis，Kafka 大數(shù)據(jù)等等。

Oracle同步MySQL的工具、MySQL分庫分表的工具、MySQL to 大數(shù)據(jù)組件的工具.... 都屬于基礎(chǔ)組件。

還有MySQL本身的高可用，MySQL的監(jiān)控等等。

Top6 人力投入大，對DBA要求高

從技術(shù)選型上來看，不僅僅是從Oracle到MySQL或者PG，還可能遷移到ES甚至是hbase等。這就對DBA有較高的要求。人力的投入和對DBA的要求可能也是去O難的重要原因之一。

“

例如：

像小明以前的公司，信息化建設(shè)以來幾億花費建立起來的系統(tǒng)，幾乎都是oracle的解決方案。在服務(wù)業(yè)務(wù)的角度來看，去IOE的象征意義遠(yuǎn)大于實際意義，傳統(tǒng)行業(yè)求穩(wěn)不求新，行政壓力、技術(shù)壓力（原有供應(yīng)商資源和技術(shù)棧將大比例更換）、財政壓力都蠻大的。

總結(jié)

去Oracle不容易，其實最大的阻力來自老板的決斷，也可能是公司對這件事的看法。這個操作是“自上往下推”的一個操作，以kpi的方式去實施。

若想做的更好建議招一個經(jīng)驗豐富的架構(gòu)師吧，全方位的評估（去Oracle不單單是DBA能完成的活）。

總結(jié)

以上是生活随笔為你收集整理的想与 Oracle 说“再见”，太难了!的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。