去O的話題，可謂由來已久。從十年前阿裡提出了這一口号，并率先在公司内部實作了資料庫的整體去O開始，到後面從網際網路公司到傳統企業也紛紛跟進，可以說去O的理念已逐漸深入人心。但到直到現在，我們可以看到Oracle在國内的市場依然占有相當大的比例。即使在對外的很多去O宣傳中，也大多是以非重度O記案例或非關鍵業務系統居多，大量核心、關鍵業務系統仍然采用O的方案。那造成這一現象的原因是什麼呢？本文嘗試對去O可能存在的難點及應對政策加以分析。下面文字代表個人觀點，僅供參考。
1. 難點：功能完備度
人生基本上就是兩件事，選題和解題。最好的人生是在每個關鍵點上，既選對題，又解好題。人生最大的痛苦在于解對了題，但選錯了題，而且還不知道自己選錯了題。正如人生最大的遺憾就是，不是你不行，而是你本可以。
Oracle從上世紀七十年來發展而來，經過四、五十年的發展，其功能的完備程度達到相當高的水準。可以說，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的生态，無疑是其成功的主要因素之一。其發展的四、五十年來，在很多領域是其引領了整個行業的發展，其産品實作方式，很大程度上也成為了事實标準。後續的很多企業在産品設計上，也參考了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中磨練自身能力，同時助力開源、國産資料庫技術長遠發展。