Q1 目前國產數據庫與Oracle相比主要欠缺在哪些方面？

孔再華：我所在的民生銀行正在做數據庫國產化改造，選型時全面分析了國產數據庫相比于Oracle等傳統商業數據庫的欠缺之處。

一、性能。我們看到目前國產數據庫在性能上多數會偏重于某個方向，有些是OLTP的性能較好，有些則是OLAP的性能較好，所以從HTAP的角度來說，國產數據庫與Oracle相比還是存在一定的差距。

但也不妨從另一個方向考慮：我們是不是因為性能這個問題才做國產化改造的呢？顯然不是。所以我們需要解決的是怎樣去克服數據庫國產化的性能問題。一方面，不同性能類型的數據庫，需要采用不同的國產化方案；另一方面，像分布式數據庫、內存數據庫這樣一些超融合的數據庫，也是可以“彎道超車”的地方，我們可以將自身的需求融入到這些數據庫里進行改造和實現。

二、功能性。Oracle等傳統商業數據庫經歷了幾十年的發展，功能已相當成熟，周邊生態也非常完善，這些對于“年輕”的國產數據庫來說還有很長的路要走。

在這個問題上，目前國產數據庫可粗略分為兩種類型，一種是研發之初就朝著接軌Oracle生態的方向，照著Oracle的功能做一遍，總體來說可能做到80%-90%，還存在一定欠缺；另一種則是跟Oracle完全不同，但其實數據庫在保障性能和主要功能的前提下，有很多功能差異是很正常的，比如Oracle和DB2就是很不一樣的兩款數據庫，所以我們也不能僅僅參照Oracle來做對比。

當然這些功能差異也是我們需要克服的困難，對于原本用得很熟練的功能，國產化后我們可能需要另找一些替代方案，甚至聯合一些國內廠商或第三方廠商去改善這些功能和生態環境。所以國產數據庫在功能性方面的欠缺，需要大家共同努力。

三、可用性。像Oracle這么成熟的數據庫，在每次新版本發布時都還會有大量bug的修復，但由于目前國產數據庫的使用率還不算高，大家探坑的機會也就不多，使用起來才發現有不少bug也是可以預見的情況。所以在可用性這方面同樣需要大家共同努力，一起去踩坑，一起將國產數據庫推向更好的方向。

Q2 Oracle往往與應用耦合度較高，遷移過程中會涉及應用遷移和改造，如何評估改造量和改造難度？如何保障兼容性？

孔再華：這是一個非常好的問題，也是我們目前面臨的最大痛點。我們銀行之前在使用Oracle的過程中，在應用開發時大量使用到Oracle提供的一些功能，國產化后就面臨著很大的改造難度。所以說，怎么進行改造和遷移？怎樣評估改造難度？確實是很關鍵的問題。

我們做國產數據庫選型時，一般會看它們對Oracle的兼容性。很多國產數據庫都會聲稱，自己對Oracle的兼容性能達到百分之九十幾。那到底是百分之九十幾呢？其實這個準確的數據無需較真，因為剩下的百分之幾也都是我們在遷移過程中經常會碰到的東西，為了做好遷移工作，我們少不了需要一定的借力。

在應用改造遷移方面，我們最大的難點是：怎樣評估應用里有哪些東西是不兼容的？

這時就需要利用一些工具，比如代碼掃描工具、SQL抓取工具等。我們聯合了一些第三方的廠商，讓他們按照我們的需求開發一些工具，使用這些工具掃描代碼就能把里面的SQL全部掃描出來，或者掃描數據庫，無論是生產環境還是測試環境的，都可以把曾經跑過的SQL全部找出來。當拿到這些東西之后，我們再放到一個評估的工具里去驗證，原來的語法是否能在新的數據庫里執行。對于不能夠執行的語法，則需要推薦一些建議去進行改造。

所以這些工具的成熟與否，跟我們遷移改造的過程是否順利息息相關。工具如果好用，遷移起來就更便捷，如果不好用，那很多時候都需要人為判斷、人為尋找替代方案，甚至人為地把整個應用進行改造，而不僅僅是改造SQL。

在數據庫遷移方面，金融行業很多數據庫都是7*24小時工作的，我們并沒有太多時間去做離線的數據遷移，所以要評估在數據遷移的過程中，DDL的對象過去是否可行？數據離線的時間是否被允許？

關于DDL的對象，首先，從Oracle遷移到國產數據庫，肯定有相關材料介紹一一對應的關系。然后，需要一個遷移工具，這個工具負責將原有Oracle里的字段類型、對象，轉換成國產數據庫的對象。經評估，現有的開源工具和商業工具，對于我們遷移到國產數據庫中的一些規則類型的改造都稍顯不足，所以我們跟相關的廠商合作，把這些規則梳理好、把相應的工具造出來，并且在我們遷移過程中不停加以完善，這個工具就會變得越來越好使。

由此，我們在DDL的轉換上問題就不大了，但接下來問題比較大的是存儲過程這塊，還有一些用到Oracle自身函數的東西。同樣的，我們也需要進行詳細的梳理，然后打造相關的工具。其實我們以往不推薦大家去使用存儲過程，因為使用了存儲過程就相當于跟對應的數據庫綁定了。我們一直推薦大家簡單地使用數據庫，因為數據庫作為后端最核心的一個提供服務的組件，需要很高的可用性，所以還是要盡量給數據庫減負，而不是一味地依賴數據庫的這些能力。如果之前已經這么干了，就只能通過工具，逐個發現不適合的地方進行改造。如果未來自己有機會做新數據庫的開發，一定要避免使用觸發器、存儲過程等這些跟數據庫耦合度很高的東西。

當解決了這些問題之后，接下來就是關于數據遷移這塊。如果是從Oracle遷移到其它數據庫，可能會有些不錯的方法可以做在線遷移。因為Oracle本身或者一些第三方廠商都具有在線遷移工具，這些工具會通過掃日志的方式同步數據，然后在需要做切換時，停業務同步最后一段數據，切換業務到新的國產數據庫。

但也有可能這些工具并不支持你選用的國產數據庫，這種情況就需要單獨造一個離線工具進行評估，從Oracle到國產數據庫里怎么改造。最好還是找廠家協助寫一個在線遷移工具，這個在線遷移最好不要落地，能夠去并發、不落地地將Oracle的數據查詢出來，放到國產數據庫里去。

對于一些特別大的表，我們可能還需要提高它的并發，還需要工具提供單表并發的功能。通過寫一定的查詢語句，把單表里的內容拆成更多份，然后每一份之間再進行并行，提高遷移速度。

總體來說，做替代Oracle的國產化改造其實非常困難，但這注定是一個任務，是一個目標，我們就是要這么去干！以上我所講述的，就是怎么在各環節采取合適的方式來加快國產化改造的建議，希望能對大家有所啟發。