去O的話題，可謂由來已久。從十年前阿里提出了這一口號，並率先在公司內部實現了數據庫的總體去O開始，到後面從互聯網公司到傳統企業也紛紛跟進，能夠說去O的理念已逐步深刻人心。但到直到如今，咱們能夠看到Oracle在國內的市場依然佔有至關大的比例。即便在對外的不少去O宣傳中，也大可能是以非重度O記案例或非關鍵業務系統居多，大量核心、關鍵業務系統仍然採用O的方案。那形成這一現象的緣由是什麼呢？本文嘗試對去O可能存在的難點及應對策略加以分析。下面文字表明我的觀點，僅供參考。
前端
1. 難點：功能完備度數據庫
Oracle從上世紀七十年來發展而來，通過4、五十年的發展，其功能的完備程度達到至關高的水平。能夠說，Oracle仍然是數據庫業內功能最爲強大的一款產品。從早期關係模型的實現、率先提出集羣理念、到引入多模異構存儲、軟硬件一體化、人工智能在數據庫的應用等等。Oracle在產品能力上不斷加強。在本世紀早期的一段時間內，開源、大數據、雲等確實對Oracle形成了必定的衝擊，但後者加速迭代更新速度，能夠說如今Oracle更是一個「全能」選手。在各個領域，均有着不俗的表現，甚至從某種程度來說，技術選型採用Oracle基本均可以知足功能須要。但也正是這一現象，形成去O的選擇是困難的，很難找到一款產品能夠完美替代Oracle的所有產品能力。因此，去O的過程每每不是一個簡單的「蘋果換桔子」的問題，而是須要從應用架構、基礎架構、數據庫架構綜合考慮，進而形成較大的困難。舉個簡單的例子，不少案例中是採用MySQL做爲Oracle的替代方案。但在真正使用中，會發現不少問題。排除底層的內核差別等外，僅從承載數據規模來看，二者的差別就很大。當數據量增大後，容量、性能問題暴露出來，你不得不去考慮使用相似分庫分表等方案來解決，但這勢必會帶來應用架構的調整。在應用經過改造、引入中間件等解決這一問題後，又會發現數據分片後的總體分析變的困難，此時又須要引入分析類產品，還要解決數據同步等問題。能夠看到一個看似簡單的底層數據庫技術選型的改變，變得愈來愈複雜。若是上述過程是在「在線」的狀態下完成，這個過程又將難上加難。綜上可見，Oracle全面而強大的功能，是在去O中不得不去面對的問題。
安全
應對策略微信
在應對策略上，首先要接受這一事實，功能差別是客觀存在的。不存在一個完美的產品能夠替代Oracle。此時能作的更可能是細化場景分析，找出更適合項目狀況的技術方案（或方案組合）。細化場景的目的，就是在於對功能需求作減法，找出替換功能邊界，進而爲後面的選型提供參考依據。若是是一個重度O的用戶，就須要梳理全部場景，提出若干種差別化的技術方案來知足不一樣的須要。甚至針對同一場景，也要有幾種方案可選，以面對成本、風險等其餘因素的考慮。例以下圖是多年前在公司整理的去O方案總結，其中場景部分正是基於上面的考慮。架構
2. 難點：性能有差別併發
性能問題，能夠說是數據庫使用中你們最爲關注的，也是在不少評測中常常拿來講事的，但這點是須要理性來看待的。性能指標，是受到工做負載（workload）、軟硬件環境、測試方法、驗收指標等不少種因素有關。不少數據庫在評測中談到性能碾壓Oracle，此時要辯證來看待。例如前一階段國內數據庫廠商OceanBase，在TPCC的評測中再次刷新了此前成績，能夠說性能指標遙遙領先，這點也確實看到國內廠商取得了長足的進步，值得誇獎；但同時也要理性看待，性能打榜成績不能徹底表明性能好。客戶更爲關注的是在通用場景下的性能表現及性能上持續穩定輸出。基於這兩點，Oracle產品無疑作的很是出色。這裏面重點談到兩點，一是Oracle的優化器能力，二是其軟硬一體機方案。若是說數據庫是基礎軟件的皇冠的話，那麼優化器就是皇冠上的明珠。優化器的好壞，直接反應數據庫的性能表現。筆者以前曾有過這樣的體驗，某項目去O遷移（包括應用改造等）總共花費三天時間，但上線後的優化足足花了一個月，甚至不少代碼不得不重寫。形成這一問題的緣由，正是優化器的差別形成一樣語句，在不一樣數據庫的表現差別巨大。通俗來講，就是寫的很爛的SQL，在Oracle中也能夠執行的很好。第二點是軟硬一體化方案，這方面Oracle是走在各廠商的前列，其最先提出一體機的理念，通過十餘年的迭代發展，其綜合性能表現使人印象深入。其將最新的硬件技術，與數據庫軟件相結合，爆發出強大能量。能夠說在極致性能表現場景下，一體機仍然是很是好的一種選擇。
編輯器
應對策略高併發
如何面對性能的差別呢？企業要作到如下幾點：一是理性看待性能指標，提出適合本身的性能要求。太高的指標要求，只會帶來後面技術選型的誤差。比單一指標更爲重要的是，性能指標的多維度。要結合場景提出本身的指標規範，是知足低延遲，仍是知足大吞吐；是知足高併發，仍是知足穩態輸出。針對這些，要提出一個綜合性的測試標準。二是構建適合企業自身的測試集，TPCC等測試標準能夠用來參考，但不要徹底依賴而是從更貼近企業業務入手，構建自有的測試集。三是關注長期發展，作有預測性的性能評估。產品的性能表現是存在所謂拐點現象，很難作到徹底線性擴展，要在評估初期就關注到這點，並根據業務發展作好預測評估及可能的備選方案。四是注意新技術的tradeoff。不少新技術確實給人眼前一亮的感受，例如性能表現很是好，但此時要理性注意到其背後的取捨問題，進而評估是否選擇及可能的解決方案。例如以Redis爲表明的KV產品，在某些場景有很好的性能表現，但它的背後是捨棄了什麼？什麼場景適合它？後端架構如何適配這一技術，在解決了性能問題的同時，避免其餘可能帶來的問題？
3. 難點：生態完整性
Oracle的生態，無疑是其成功的主要因素之一。其發展的4、五十年來，在不少領域是其引領了整個行業的發展，其產品實現方式，很大程度上也成爲了事實標準。後續的不少企業在產品設計上，也參考了Oracle的作法，某種程度將Oracle成了數據庫的代名詞。伴隨着其成熟穩定的生態，也有不少相關企業，從底層基礎設施廠商、到數據庫周邊的備份、監控，到上層的數據建模、治理，再到應用軟件開發，這些企業伴隨着Oracle共同發展，共存共榮。例如：Oracle在傳統金融領域佈局多年，服務了大量銀行客戶。而這些銀行的業務系統，則是有不少ISV來開發支持，他們已經很是習慣使用Oracle做爲底層數據的存儲、計算基礎，此時更換數據庫已不是簡單的一替了之，而是須要大量的應用系統改造適配的過程。這其中還須要考慮新老系統的共存、數據遷移帶來的應用適配等種種問題。能夠說這方面帶來的工做量，是整個去O工做中的主體部分，也是關乎到其最終替換效果可否達到預期的關鍵。此前看到的陸金所的分享，正是在業務梳理、服務化改造到後面遷移、切流等作了大量工做後，才逐步將數據庫從Oracle遷移到MySQL上。
應對策略
面對Oracle成熟的生態，做爲企業要作好充分的準備，認識到去O工做不是簡單的底層替換而已，要從方方面面着手準備。後者所佔的工做比例，甚至超過前者，而這些「細節」會決定最終的實際效果。那麼做爲技術提供方來講，不要試圖僅僅經過全新創建生態來替代Oracle，而是可作兩手準備，作好必定的適配Oracle的工做。一方面，要儘可能兼容Oracle的生態標準，方便其周邊生態企業能夠很是低成本的切換過來。這也是我目前認爲國內產品作的相對薄弱的部分，不少產品都號稱可完美地兼容Oracle，是實際效果每每大打折扣。第二方面是作好差別化聲明。一個產品要完美地兼容另外一款產品是不可能的，雙方的差別勢必存在。重要的是，將這個差別明確地傳達給客戶，不要等上線後才發現二者的行爲不一樣。第三方面是作好遷移輔助工做，可經過文檔、工具、專家服務等形式，提供給客戶遷移輔助能力。好比阿里的ADAM平臺，就是一款遷移評估產品，能夠很方便地評估二者的差別並給出建議、甚至是部分遷移邏輯的實現。這樣可大大減小客戶遷移的憂慮。
4. 難點：成本不便宜
成本，是你們常常來談到去O可能帶來收益的一個說辭，但這裏是有一個誤區的。僅僅從字面成本表明的經濟投入來講，去O每每就是不划算的；再從外延所涉及的人力成本、時間成本、風險成本、機會成原本說，更是如此。先從經濟成原本看，Oracle採起的綁定資源的許可證+後期服務費的方式，是比較昂貴的；並且每每在議價方面也是比較強勢。不少企業也是看到這一點，於是才考慮去O的。
選擇了去O，僅從經濟投入角度也會帶來很大一筆投入。這裏面可能包括選擇其餘商業產品（或商業服務）可能的投入，需構建新的服務體系帶來的人力投入，上下游適配帶來的更換類、改造類的投入等等。
再從人力成原本看，引入一款或多款新的數據庫/大數據類產品來替代O，須要人力投入；如引入例如分庫分表等中間件產品，在應用架構上、應用開發上也是須要人力投入的。如採用的是開源產品，還須要企業有很好的掌控開源產品能力，在必要內核上及構建周邊生態工具平臺上一樣須要人力投入。
三從時間成原本看，去O每每有個週期較長的過程，是須要花費較長的時間成本。企業是否有足夠的時間來完成這一過程？是否在快速業務發展中，有足夠的空間來作？是採起大刀闊斧仍是小步快跑的方式，這些都是與企業總體發展節奏相關，須要統籌來考慮。
四方面的風險成本，也是不可迴避的一個問題。作任何技術決策均可能帶來風險，針對這樣的風險企業是否有足夠的認知？爲規避這一風險，是否採起了必要的措施？而這些措施，是否又帶來了額外的經濟、人力、時間成本，甚至新的風險點…（好吧，有點燒腦）
應對策略
面對上述種種成本，企業該如何來解決呢？這裏能採起的應對策略就是充分評估，將上述可能的成本因素都羅列出來。針對不一樣的解決方案，在不一樣成本投入上有所差別，這也是後面作選型時的重要考量因素之一。此外，還須要從長遠及戰略層面考慮這一問題，不要僅依靠成本說話。該須要長期投入的，要捨得投入；該歸入企業技術戰略決策的，要勇於投入。不要被短時的成本收益所左右。
5. 難點：服務健全性
不少企業選擇Oracle，是看中其良好的服務能力。所謂的「交鑰匙」項目，讓企業能夠更安心在自身業務上，而不是技術自己。可以達成這點，一方面是Oracle產品自己發展多年，其功能完備度已經很高，並已造成了很好的交付能力；第二方面，完備的生態帶來的交付閉環，大量的服務類企業保證了很好的交付質量。相比較而言，不管是國產數據庫或者開源產品，都須要企業在產品服務上面有更多的關注。
應對策略
針對這點，做爲甲方的企業要更多作好選擇把關工做，選擇那些真正有實力交付的企業及產品。特別是某些基於開源產品衍生而言的商業產品，企業是否對內核有足夠的把控力，尤其關鍵。此外，在其服務體系（流程、標準等）、客戶案例等，都須要加以考慮。若是是企業選擇自研或開源方案解決，則須要構建其成熟的運維體系，這點可參照商業解決方案。對涉及數據安全、可用性等關鍵指標，作好必要的預案並按期演練。而做爲乙方來講，提高交付服務能力是須要一個過程，要認可與傳統商業數據庫廠商服務積累多年的差距。有意識地去模仿構建成熟的服務體系，同時加大對生態合做夥伴的支持，讓你們共同參與到服務中來。
6. 難點：風險可控度
風險問題，是你們作去O選擇時不得不面對的問題。做爲基礎軟件，出現bug是難以免的，但以Oracle爲表明的大型商業數據庫，通過多年的打磨積累已經能夠作到風險可控。Oracle從最先物理邏輯的備份恢復、到高可用集羣（RAC）、到數據衛士（DataGuard），再到獨立的備份一體機。經歷了數十年的發展，在多方面作到數據保障。這也是以前用戶，勇於將核心、關鍵業務放在上面的緣由之一。某種程度上講，用戶能夠接受必定的服務降級，但在關鍵的數據安全、可用性上面，是須要嚴格獲得保障的。與之相對比，去O以後的方案一樣須要規避上述可能的風險。
應對策略
爲解決上述問題，甲方企業須要本着嚴謹的原則，將可能的風險因素都歸入到評測以後，以此來考察候選方案。同時，在推動過程當中能夠按照「先邊緣、後核心；先局部、後總體」的原則，來推動去O工做。在這一過程當中，不斷完善打磨整個方案。做爲乙方產品，如何可以打消客戶的顧慮，讓客戶能夠無憂選擇也是很是值得探討的。好比支持產品混部，將自有產品放在後端，經過所有隻讀->讀寫混合->所有可寫的步驟，逐步替代的方式減小出現風險的可能。在好比支持前端路由選擇，嘗試使用小部分業務流量來驗證，並逐步擴大等等。經過這些手段的使用，逐步提高用戶使用的信心。同時，針對產品自身質量，一樣須要嚴格把關，作好交付輸出。
7. 寫在最後
如何理性看點去O的價值？或者說，企業爲什麼作出這樣的選擇？一方面，隨着國內外形勢變化，對國產化、自主可控有着實際要求。針對某些關鍵行業、關鍵領域，在政策上是有明確要求的。除此以外，企業更多選擇去O是從成本、擴展性及自身技術戰略出發的一種選擇。此時，是須要企業冷靜思考，作出最合適企業自身的選擇。從近年來的發展趨勢來看，愈來愈多的企業開始將去O做爲企業將來技術發展戰略，同時也有不少的國產數據庫或雲數據庫廠商加入到這一浪潮之中。這爲國內的數據庫發展帶來新的發展機遇。去O自己並非目的，如何在將來基礎軟件使用發展上有着自主能力纔是關鍵。大勢所趨，乘風而上；但願更多企業在去O中磨練自身能力，同時助力開源、國產數據庫技術長遠發展。
韓鋒頻道：
關注技術、管理、隨想。
長按掃碼可關注
本文分享自微信公衆號 - 韓鋒頻道（hanfeng_channel）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。