南京銀行
公司介紹
南京銀行成立于 1996 年 2 月 8 日，是一家具有由國有股份、中資法人股份、外資股份及眾多個人股份共同組成獨立法人資格的股份制商業銀行，實行一級法人體制。先后于 2001 年、2005 年引入國際金融公司和法國巴黎銀行入股，在全國城商行中率先啟動上市輔導程序并于 2007 年成功上市。入選英國《銀行家》雜志公布的全球 1000 家大銀行排行榜和全球銀行品牌 500 強榜單，2017 年分列第 146 位和第 131 位。在互聯網金融飛速發展的當下，南京銀行積極轉型，努力打造自己的互聯網金融平臺。
李勇
南京銀行信息技術部副總經理
“OceanBase 數據庫系統經過螞蟻金服內部大量互聯網金融場景驗證，給了我們嘗試使用的信心。實踐證明，南京銀行選擇 OceanBase 數據庫，給“鑫云 +”互金平臺提供了更加堅實的保證。”
業務挑戰
在線水平擴展能力：能夠在不中斷業務的情況下，快速擴展硬件能力。
高并發處理能力：能夠應對類似雙十一的瞬間高并發流量。
軟硬件和運維成本：能夠在滿足上述需求的同時，大幅降低成本。
優化結果
2017 年 9 月 28 日，南京銀行、阿里云以及螞蟻金服舉行戰略合作協議簽約儀式，共同發布南京銀行“鑫云+”互金開放平臺。南京銀行“鑫云+”互金開放平臺是阿里云、螞蟻金融云合作整體輸出的第一次努力，通過“鑫云”+平臺的建設，南京銀行互金核心系統在如下方面獲得了質的提升：
擴展能力：在平臺建設期間和投產后，OceanBase 做過多次在線水平擴展。
處理能力：從 10 萬筆/日以下，增加到 100 萬筆/日以上。
成本降低：單賬戶的維護成本從 30~50 元/賬戶，降到 4 元/賬戶。
網商銀行
公司介紹
網商銀行定位為網商首選的金融服務商、互聯網銀行的探索者和普惠金融的實踐者，為小微企業、大眾消費者、農村經營者與農戶、中小金融機構提供服務，是中國第一家將核心系統架構在金融云上的銀行。基于金融云計算平臺以及 OceanBase 的海量存儲，網商銀行擁有處理高并發金融交易、海量大數據和彈性擴容的能力，可以利用互聯網和大數據的優勢，給更多小微企業提供金融服務。
唐家才
網商銀行 CTO
“網商銀行選擇 OceanBase 三地五中心部署架構，不僅在數據上從具備抵御同城機房故障提升到具備異地城市容災的能力，同時內置的多租戶隔離的能力，滿足全行多應用系統的管理與使用需求，讓應用系統多活架構設計上變的異常簡單。”
業務挑戰
具備城市級別的容災能力滿足監管要求，同時最大限度地減少容災上部署、運營和維護IT基礎設施的工作量，從而降低系統運行和維護的成本。
提供標準、安全和高效的數據庫多租戶隔離環境及管理工具，滿足全行多應用系統（如存貸匯核心系統）的管理與使用需求。
優化結果
選擇 OceanBase 三地五中心部署架構，實現了業務應用上杭州，上海異地多活的能力，極大的提升了全行的系統吞吐量。同時容災上具備任意時間，任意服務器，任意機房，任意城市出現不可抗拒因素災難時，完全無需人工接入的無損自適應容災，RPO=0，RTO<30 秒，極大的減少了運營和維護 IT 基礎設施的工作量，從而降低了運行和維護的成本。
在平臺建設期間和投產后，OceanBase 做過多次在線水平擴展，具備高擴展能力。
借助 OceanBase 提供的多租戶特性，在集群上按照業務重要程度與流量配比分配資源策略，在資源的共享與隔離上取得了最佳的平衡，極大的減少了 IT 基礎設施的采購成本。同時通過 OceanBase 云平臺運維管控產品，日常運營維護 100% 白屏化，大大的降低了維護運營成本。
支付寶
公司介紹
支付寶是中國內地領先的第三方支付平臺，致力于提供“簡單、安全、快速”的支付解決方案。在 2017 年雙十一購物節，支付峰值最高達 25.6 萬筆/秒。 支付寶的所有核心業務數據包括交易、賬務、花唄、借唄等均存儲在 OceanBase 上，相比傳統的 Oracle 方案，OceanBase 使用更低的成本，實現了更高的擴展性，幫助支付寶平穩應對各種促銷業務高峰。
程立
螞蟻金服 CTO
“OceanBase 穩定支撐了支付寶的核心交易、支付與賬務，經歷了多次“雙十一”的考驗，形成了跨機房、跨區域部署的高可用架構， 并在日常運行、應急演練和容災切換中發揮了重要作用。”
業務挑戰
一致性，一致性是金融業務的生命線，為了應對硬件或者系統故障（IDC/OS/機器故障），傳統的數據庫在這方面為業務提供多種選擇。最大可用模式在主庫故障情況下可能造成數據丟失。最大保護模式會提高全年的不可用時間，并造成性能下降。
擴展性，傳統的基于硬件是 scale up 方案成本是非常高的，在螞蟻內部采用 sharding 的方式，通過自研中間件 ZDAL 屏蔽分表信息，對業務提供單表視圖。
可用性，金融業務對系統的可用性要求非常高，通常在 99.99% 以上。一些金融機構通常采用數據庫本身的特性來提供系統的可用性，以 Oracle 為例，為了保證高可用目前有兩種方案：RAC 方案和 DataGuard 方案。在故障場景下恢復時間會比較長，因此業務上通常會實現一些高可用方案如Failover等等提高故障恢復時間，同時也引入了大量的復雜度。
成本和性能，對于傳統數據庫而言，成本分為機器成本和許可證（license）成本。不同于傳統的金融企業，互聯網金融服務的用戶數非常大，傳統的收費方式會帶來非常高昂的成本。
優化結果
OceanBase 在一致性方面做了以下幾個事情，架構層面引入 Paxos 協議，多重數據校驗機制，完善支付寶業務模型，多重機制保障金融級別的一致性。
OceanBase 的高可用策略與傳統的基于共享存儲的方案有很大不同，OceanBase 采用 Share Nothing 架構，并且每個組件都有各自的持續可用方案。
在部署架構上也引入了不同，支付寶的訂單型業務采用了"同城三中心"的部署方式，具備單機和單 IDC 故障的容災，通過 RFO 的方式提供異地容災能力，在性能和可用性方面做到了極致的權衡。賬務型業務采用"三地五中心"部署方式，除了具備單機，單 IDC 的容災能力，還具備城市級故障自動容災能力。在同城容災和異地容災場景下，RPO=0，RTO<30 秒。
淘寶網
公司介紹
阿里巴巴是全球最大的電子商務網站之一，2017 天貓雙 11 整天成交金額 1682 億元。淘寶（天貓）收藏夾是用戶非常喜愛的功能之一，用戶在瀏覽淘寶網站的時候會把自己喜歡的商品或者店鋪加入收藏夾中，以便于以后能迅速的找到之前收藏過的商品。用戶同時還能跟好友分享自己的收藏商品或者店鋪。目前淘寶收藏夾已經達到幾百 TB 規模，服務 8 億淘寶用戶。
林玉炳
淘寶技術部基礎交易
“收藏夾服務集團內 50+ 業務方，總體收藏關系數將近千億，并發量數十萬，OceanBase 非常好的支持了收藏夾的讀寫場景，經歷了多次大促高并發考驗，運行穩定，吞吐量高，性能優異，成本低廉，非常好的滿足了收藏夾的業務發展需求。”
業務挑戰
收藏夾每天寫入量千萬級的寫入量，同時需要支持數萬每秒的寫入峰值。
收藏夾的查詢是收藏記錄和商品信息的一個連接查詢，平均每個查詢都需要連接上百條記錄，且雙 11 的用戶展示的峰值能達到數十萬每秒左右。對數據庫的性能提出了嚴苛要求。
優化結果
利用 OceanBase 數據庫先進的分布式的特性，把單表數據自動分布到數十臺廉價微型服務器上，這數十臺服務器同時支持每天的高強度寫入，輕松化解寫入壓力。
利用 OceanBase 出色的容災特性，三個機房部署，即使某個機房整體異常，也不會影響用戶訪問。
阿里媽媽
公司介紹
阿里媽媽廣告業務主要是一種 P4P（Pay for Performance）形式的廣告業務系統，而報表中心作為阿里媽媽向廣告主透出廣告效果數據的唯一平臺，在阿里巴巴大平臺豐富多樣的商業場景下，為客戶提供優質，高效，可靠的數據服務，成為廣告投放的風向標。報表平臺將品類繁多的商業廣告信息進行分類匯總，提煉出直通車，鉆展，品效，一站式，原生內容，新單品等業務線的報表服務，為阿里巴巴商務平臺上的賣家提供各種精確的，多維的廣告效果分析服務。
張煒宇
阿里媽媽基礎共享技術開發平臺總監
“OceanBase 很好的滿足了我們廣告業務對于存儲系統擴展性，并行計算，統計計算，高吞吐，低時延，資源隔離等大數據處理的需求，在報表業務的演進中幫助我們建立了一套業務和平臺分離，面向效果指標開發的通用系統。”
業務挑戰
開發效率：報表平臺承載了阿里巴巴商業平臺上品類繁多的廣告數據的匯總和對廣告主的展示，不同業務線有不同的報表訴求，即使在相同的業務線下，基于不同的營銷場景，也會有不同維度的數據抽象和封裝。但在報表開發的演進過程中，報表平臺逐步建立起業務與系統分離，由之前的面向報表的開發模式，轉變為面向指標的通用解決方案，這就把報表開發的問題拆解為細粒度的指標組合，不同的指標依賴的計算存儲模型會根據業務的特性會有極大的不同。而 OceanBase 提供的豐富的分區方式及 OLAP 能力有效地解決了不同場景下，業務指標的構建問題，這對于我們業務開發工作者來說可以更多的關注我需要什么樣的指標，而不用考慮如何從存儲系統中得到這些數據。
大數據處理能力：隨著阿里巴巴集團業務的高速發展，推廣營銷在商業引流上的重要性越發明顯，報表作為營銷產品的閉環，其訴求也越發的多樣化、個性化，報表數據在近幾年的發展中在量級上已經增長到TB甚至數十 TB 的規模。這個時候存儲系統的擴展性就顯得非常重要，如果一開始我們就預估 5-10 年的存儲資源，在前期數據規模不大的情況下，必然存在嚴重的資源浪費，如果前期預估得太少，隨著數據增長，MySQL+ 中間件的集群擴容帶來的數據搬遷問題又費時費力。同時，為了讓用戶獲得良好的數據展示體驗，我們要求每一次數據計算的時間不能太長（通常不超過 10s），而對于一些大數據的讀寫請求，如果不使用并行計算能力，是很難達到這個要求的。然而大數據的并行查詢不能拖垮系統中的高優先級的小請求，并且當 MySQL 單表數據規模超過 2000 萬時，其查詢性能就出現斷崖式的下跌，這也是業務無法容忍的一大缺陷，因此，我們在系統選型上更傾向于 OceanBase 這樣具有高吞吐，數據讀寫隔離，資源隔離能力的存儲方案。
易用性：廣告業務是一種典型的線上分析型業務（OLAP），需要在龐大的買家數據和廣告數據中分析兩者的關聯關系，然后精準的分析出廣告主的廣告投放效果。因此，報表平臺中存在著較多的多維度的數據關聯查詢，以及大數據的分組匯總查詢，同時也存在一些統計學上的專業函數計算。而廣告業務領域目前比較流行的 ROLAP、MOLAP 的分析型數據查詢方案 SQL 能力都不夠友好。因此我們需要基于其提供的 API 做很重的業務抽象，封裝成一套業務通用的 SDK，因此我們不得不投入更多的開發和維護人員在這套笨重的 SDK上，開發效率將大打折扣，所以我們還需要一個對 SQL 語言支持良好的存儲系統。
系統成本：另一種解決方案就是采用大多數商業公司使用的 Oracle 提供的 RAC 解決方案，通過共享存儲的能力提供數據存儲空間的擴容，通過在共享存儲上增加計算節點來提供高速的并行處理能力。這套方案都是基于在昂貴的硬件基礎和 Oracle 數據庫 License 費用上的，這不符合我們打造低成本技術體系的初衷。
優化結果
OceanBase 作為一個通用的分布式關系數據庫系統，其提供了豐富的分區方式（HASH， RANGE， RANGE+HASH 等），并且提供在線的業務無感知的動態分區能力，集群擴容只需要 DBA 簡單的增加存儲節點，以及做一些簡單的 DDL 操作即可，完全對業務透明，解決了我們業務數據爆炸式增長的問題。
OceanBase 兼容 MySQL5.6 版本大部分功能，完全覆蓋報表業務的需求，報表業務可以像使用 MySQL 那樣去使用 OceanBase，不需要業務做過多的邏輯改造，同時作為分布式關系數據庫，還能夠提供復雜的跨多結點的分布式 JOIN 能力，以及并行的匯總排序能力和豐富的數學計算函數能力，友好的滿足了我們大多數場景的計算需求。同時，OceanBase 還為報表平臺量身定制了近似計算的功能，對于一些超大結果集的運算，OceanBase 會篩選出一些精度影響較大的數據，然后基于這些數據進行匯總計算，在超大的數據計算的情況下，能夠快速的得出一個離正確結果相差不大的近似結果。
OceanBase 作為一個可水平擴展的分布式關系數據庫系統，在集群中，每個節點的角色關系都是對等的，每個節點都可以提供讀寫能力，大大提高了系統整體的吞吐能力，這也滿足了我們需要迅速導入數據的訴求（TPS 峰值需要在 10 萬以上）。同時，每個節點都可以部署在廉價的 PC 服務器上，因此，系統成本上的性價比是 RAC 解決方案的數十倍。