資料庫從集中式架構到分布式架構發生了哪些改變?

2020-12-28 中華網科技

企業需要什麼樣的資料庫？在不同的時間和不同的環境下可能都會有不同的答案。

關係型資料庫依然是主流

資料庫的概念最早源自上個世紀60年代。到了70年代，關係模型已經誕生。80年代關係資料庫逐漸成為整個社會的信息基礎設施。2000年伊始，隨著網際網路的發展，並發訪問量驟增，達到百萬至千萬的級別，而傳統商業資料庫越來越難容納和處理這麼大的數據量和訪問量。從2006年開始，大量新的非關係型資料庫如雨後春筍般湧出，在整個資料庫行業掀起了一場空前盛大的NoSQL革命。

雖然非關係型資料庫在一段時間內引起了巨大的反響，但是關係型資料庫經歷了幾十年時間的發展，時至今日它依然是整個社會的信息基礎設施，承載著整個社會重要程度最高、訪問量最大的數據。但基本上關係型資料庫的市場格局沒有太大的變化。最早的幾家霸主直至今天依然佔據著統治地位。 比如我們所熟知的Oracle資料庫、SQL Server、DB2。

在歷史上，關係型資料庫是被判死刑最多的資料庫，現在來看非但沒有死，而且煥發出了新的活力。從資料庫流行度趨勢可以看到，2013年至今排名前三的都是關係型資料庫，而且非常穩定。

根據Gartner報告，全球資料庫市場巨大，其中關係型資料庫2018年達到375億美元，仍然保持10%的高速增長，預計2020年全球市場規模將達459億美元。而中國關係型資料庫市場預計2020年將達20.7億美元。

關係型資料庫能夠經久不衰而愈發強勁是因為其帶來的價值，螞蟻金服研究員韓鴻源認為關係型資料庫主要有兩點價值，一是滿足資料庫的ACID特性，即原子性、一致性、隔離性、持久性，幫助應用開發且簡化應用開發的複雜性。二是SQL語法接近自然語義，開發人員寫的代碼可以讓業務人員很容易看懂，代碼可讀性和可維護性非常強，降低了溝通成本。

近兩年國內資料庫市場格外熱鬧，很多廠商都推出了自研的國產資料庫，而關係型資料庫是各廠商的主攻方向，螞蟻金服的OceanBase就是其中的代表。不過相比於傳統資料庫，為了應對業務複雜性和快速迭代所帶來的挑戰，關係型資料庫也在一直演變，在架構層面從集中式逐步走向分布式。

架構之變：從集中式到分布式

90年代到本世紀初是關係型資料庫的大發展時期，由IOE構建起了封閉的集中式架構體系，以Oracle資料庫、SQL Server、DB2為主的商用關係型資料庫牢牢佔據著企業級資料庫市場。彼時能用得起資料庫的非富即貴，基本都是銀行和電信企業。

傳統的集中式架構在穩定性和可用性方面有天然的優勢，同時缺點也很明顯，擴展性差。原來傳統企業接入的終端有限，銀行、政企的業務系統都是給內部人員使用，其擴展性方面的短板還不足以構成挑戰。但是隨著網際網路尤其是移動網際網路的發展，業務系統除了滿足內部人員使用，還要支撐海量移動終端的訪問請求，數據指數級增長所帶來的高並發使得集中式架構面臨著挑戰，依靠垂直型擴展很難滿足需求。

2009年，阿里巴巴首提"去IOE"，即擺脫業務系統對IBM小型機、Oracle資料庫以及EMC存儲的過度依賴。並對業務系統進行服務化和分布式改造，2010年，阿里巴巴/螞蟻金服啟動了OceanBase分布式關係型資料庫項目。

十年來，國內去"O"之聲不斷，伴隨著去"O"而來的是架構體系從集中式到分布式的演進。集中式架構單一的大伺服器加存儲的方式擴展能力有限，無法支持企業持續向前發展，分布式是未來。火熱發展的雲計算帶來了對更大規模資料庫的需求。上雲已是大勢所趨，雲與分布式架構相得益彰。

現在國內資料庫去"O"與上雲之路任重道遠，比如傳統金融業尤其是傳統銀行的業務系統依然很多都依賴於IOE構建起來的集中式架構，資料庫由於承載著非常重要的業務系統，是最難遷移的基礎軟體之一，銀行出於穩定性和合規性等各方面的考慮，尤其是對分布式架構的可用性、可靠性存有疑慮，往往在選型時比較謹慎。不過很多銀行出於業務需求，已經著手分布式架構改造與雲端遷移。

去年OceanBase打榜TPC-C摘得冠軍，向世界證明了分布式資料庫也可以在性能、可靠性和可用性上與集中式資料庫並駕齊驅。目前OceanBase除了支持螞蟻金服自有業務、阿里巴巴集團雙十一的流量考驗以外，還支持著數十家商業銀行、金融機構的業務。

OceanBase 2.2 版本便是成功支撐2019年天貓雙11大促的穩定版本，同時也是用於TPC-C測試且榮登TPC-C性能榜首的版本。相較2.0版本，2.2版本新增了不少重磅功能，是兼容MySQL以及Oracle兩種模式的裡程碑版本，OLTP性能相比2.0版本提升50% 以上。

現在一場突如其來的疫情，讓企業經營者們正經歷著最特殊的開年。在這次全民抗"疫"中，科技企業提供了眾多強有力的技術支撐，助力企業停業不停工。

2月19日—2月26日 ，螞蟻金服開展"共戰'疫情'，技術破局"數字課堂線上直播。邀請資深專家從"雲原生"、"研發效能"、"資料庫"三方面分享螞蟻金服的實踐經驗並在線答疑。在線看大會就來阿里云云棲號,進入螞蟻數字直播間。

直播課在2月24日和2月25日特設兩場關於OceanBase 2.2 版本的直播，由螞蟻金服OceanBase團隊解決方案架構師慶濤為大家帶來分享。針對異地容災多活、在線機房搬遷和在線數據遷移等場景解析OceanBase的完整解決方案。將為觀眾介紹OceanBase 2.2版本的部署和安裝指南，手把手帶你搭建一個高可用的OceanBase 2.2資料庫集群。也將針對用戶使用OceanBase 2.2版本過程中可能會遇到運維和開發方面的難點和疑問，為大家詳細解讀從資源管理、集群管理、租戶管理，再到監控告警、備份恢復等運維過程中的全部知識點。

此外，這次直播內容還將帶領大家探索Oracle和MySQL租戶，並體驗數據遷移、數據同步等實踐操作，幫助用戶從開發和運維層面實際體驗OceanBase 2.2版本的核心能力。

據了解，OceanBase 2.2 版本已於近期正式上線官網，登陸OceanBase官網即可免費獲取。OceanBase 2.2版本是成功支撐2019年天貓雙11大促的穩定版本，同時也是用於TPC-C測試且榮登TPC-C性能榜首的版本。此次全新上線的OceanBase 2.2版本也是同時兼容MySQL以及Oracle兩種模式的裡程碑版本。

責任編輯：kj005

文章投訴熱線:156 0057 2229 投訴郵箱:29132 36@qq.com

相關焦點

  • 集中式架構和分布式架構哪種更好？
    集中式與分布式之爭事實上，關於集中式架構和分布式架構哪種更好的討論已經在業界延續了很長時間，每次出現類似的話題，似乎都要選出一個對錯，那麼我們可以從集中式和分布式架構出現的背景談起，看看這兩種不同的架構究竟有什麼異同。
  • 分布式資料庫比集中式資料庫的優勢在哪裡?
    大數據時代，面對日益增長的海量數據，傳統的集中式資料庫的弊端日益顯現，分布式資料庫相copy對傳統的集中式資料庫有如下優點。更高的數據訪問速度：分布式資料庫為了保證數百據的高可靠性，往往採用備份的策略實現容錯，所以，在讀取數據的時候，客戶端可以度並發地從多個備份伺服器同時讀取，從而提高了數據知訪問速度。
  • 分布式架構在銀行的應用
    過去我國大型銀行的核心銀行系統大多基於主機技術，採用集中式架構建設。主機強大的計算能力與高穩定性，支撐了本世紀初各家大型銀行信息系統由省域集中到全國集中的升級，促進了銀行業務的創新和發展。近年來隨著 IT 技術爆發式的發展，尤其是移動網際網路、大數據、人工智慧、區塊鏈和雲計算等技術的逐步成熟，銀行業務在渠道、產品、營銷、運營和風控等方面都在發生著深刻的變革，產品迭代的速度越來越快。
  • ...模塊化、集中式、分布式、服務化、面向服務的架構、微服務架構
    集中式與分布式 　　要談微服務，那麼必須建立在分布式的基礎上，對於一個集中式系統也無需談微服務。在我的另外一篇文章初識分布式系統中介紹過集中式系統和分布式系統的區別，這裡再簡單回顧一下：　　集中式 　　集中式系統用一句話概括就是：一個主機帶多個終端。終端沒有數據處理能力，僅負責數據的錄入和輸出。而運算、存儲等全部在主機上進行。
  • 雲計算時代,資料庫架構設計有哪些改變?
    【IT168 評論】雲計算時代，各大廠資料庫架構設計經歷了哪些改變?在SACC大會第二天下午的資料庫架構設計的前世今生(上)專場，來自京東雲、阿里巴巴、58速運、去哪兒網、京東的技術一線專家分享了各自在雲計算時代下的資料庫架構設計實踐，遇到過哪些問題?如何解決?如何保證資料庫的高可用和高可靠等等一攬子技術乾貨!
  • 阿里P8架構師深度概述分布式架構
    而集中式的計算機系統架構也成為了主流。隨著計算機的發展，這種架構越來越難以適應人們的需求，比如說由於大型主機的複雜性，導致培養一個能夠熟練運維大型主機的人的成本很高大型主機很貴，一般只有土豪(政府、金融、電信)才能用得起單點問題，一臺大型主機出現故障，那麼整個系統將處於不可用狀態。
  • 【乾貨】集中式和分布式的對比
    （2）在銀行業中的運用 （3）從主從架構到集群架構 二、分布式架構的演進 （1）分布式出現的背景 （2）從集中式到分布式架構 （3）不同模式下的優缺點分析 一、集中式架構
  • 分布式架構之美
    三、分布式架構發展的裡程碑​　　大型主機憑藉著大型機超強的計算和 I/O 處理能力、安全性、 穩定性等，在很長一段時間內，大型機引領著計算機行業及商業計算領域的發展。而集中式的計算機系統架構也漸漸成為了主流。
  • 工行「去O」資料庫選型與分布式架構設計
    但是隨著分布式技術的成熟，傳統的IT架構面臨著4大挑戰：1）從處理能力層面來看，傳統應用（也叫巨石型應用）系統規模龐大，採用集中式架構設計，使用單一系統垂直擴展模式，擴展能力相對來說是有限的；另一方面，大數據時代引發海量數據分析處理和存儲處理的問題，對擴展性
  • 從架構特點到功能缺陷,重新認識分析型分布式資料庫
    寫在前面本文是分布式資料庫的總綱文章的第一部分，主要探討分析性分布式資料庫的發展和技術差異；第二部分則是交易性資料庫的一些關鍵特性分析。Ivan開始計劃的分布式資料庫是不含分析場景的，所以嚴格來說本篇算是番外篇，後續待條件具備將以獨立主題的方式展開。正文隨著大規模網際網路應用的廣泛出現，分布式資料庫成為近兩年的一個熱門話題。
  • 集中式OR分布式，難道是零和博弈？
    在一場針對企業IT架構如何選擇的辯論賽中，雙方就此進行了激烈而精彩的辯論。其實，集中式架構和分布式架構最近還有另一種描述——核心式和創新式，已經將兩種架構的應用選擇進行了清晰的映射。01 集中式經久不衰集中式IT架構是企業架構最初的選擇。
  • 光大銀行分布式實戰:國內最大繳費平臺的資料庫架構轉型
    所以我們總結了一下，在傳統的架構下，會面臨這樣的一些挑戰： 處理能力受存儲性能、熱點資源制約：高業務壓力下，集中式存儲資源性能受限，熱點資源、空間分配等衝突嚴重。因為這種高並發的業務，在壓力下，集中式存儲，可以說是一個單點吧，它的資源性能是受到一定限制的。
  • 高並發場景下，光大銀行分布式資料庫的架構轉型實戰
    所以我們總結了一下，在傳統的架構下，會面臨這樣的一些挑戰：處理能力受存儲性能、熱點資源制約：高業務壓力下，集中式存儲資源性能受限，熱點資源、空間分配等衝突嚴重。因為這種高並發的業務，在壓力下，集中式存儲，可以說是一個單點吧，它的資源性能是受到一定限制的。
  • 一文理解分布式架構
    本文轉載自【微信公眾號：手機電腦雙黑客，ID:heikestudio】經微信公眾號授權轉載，如需轉載與原文作者聯繫一、什麼是分布式架構分布式系統（distributed system） 是建立在網絡之上的軟體系統。內聚性：是指每一個資料庫分布節點高度自治，有本地的資料庫管理系統。
  • 三分鐘快速了解 分布式架構的演進過程
    大型主機的出現,憑藉著計算能力和處理能力,高的穩定性和安全性,在很長的一段時間內引領到計算領域的發展。但是集中式的計算機系統來帶來了一些問題,來越來越不能滿足用戶的需求比如說:　　1.大型的主機非常貴,一般的小企業用不起。　　2.大型主機比較複雜，培養人才的成本比較高。
  • 什麼是分布式系統！以及分布式系統架構的優缺點
    現在的架構很多，各種各樣的，如高並發架構、異地多活架構、容器化架構、微服務架構、高可用架構、彈性化架構等，還有和這些架構相關的管理型的技術方法，如 DevOps、應用監控、自動化運維、SOA 服務治理、去 IOE 等等，還有很多。　　那什麼是分布式系統?海威恆泰分布式系統是支持分布式處理的軟體系統，是由通信網絡互聯的多處理機體系結構上執行任務的系統。
  • 分布式架構知識梳理
    1.問題1、何為分布式何為微服務？2、為什麼需要分布式？3、分布式核心理論基礎，節點、網絡、時間、順序，一致性？4、分布式是系統有哪些設計模式？5、分布式有哪些類型？6、如何實現分布式？計算機以集群的方式存在，按照分布式理論的指導構建出龐大複雜的應用服務，也已經深入人心。本文力求從分布式基礎理論，架構設計模式，工程應用，部署運維，業界方案這幾大方面，介紹基於MSA(微服務架構)的分布式的知識體系大綱。從而對SOA到MSA進化有個立體的認識，從概念上和工具應用上更近一步了解微服務分布式的本質，身臨其境的感受如何搭建全套微服務架構的過程。
  • 工商銀行MySQL資料庫架構解密
    一、資料庫轉型背景1.1 傳統IT架構的挑戰大型國有銀行，整體核心的系統都是大機+DB2這樣的傳統架構；針對現在的網際網路金融業務快速擴張的需求，傳統的架構面臨著比較大的挑戰，主要集中在四個方面：l   處理能力；因為工行這麼大的體量，導致整體系統的規模比較龐大，這種垂直的單一的擴展模式，不具備橫向處理能力
  • 分布式系統架構與雲原生—阿里雲《雲原生架構白皮書》導讀
    通常來說，對於信息系統的架構方式的進化和改變即是伴隨著接入數據和所提供的業務由少變多的過程，目前為止信息系統的架構經歷了單機架構、集群架構、分布式架構、分布式多活數據中心架構幾個階段，同時伴隨著業務系統架構一同演變的還有各種外圍系統和存儲系統，比如關係資料庫的分庫分表改造、從本地緩存過渡到分布式緩存等。
  • 支付寶金融級IT架構及分布式架構的應用實踐
    行業常見分布式架構行業常見的分布式架構主要包含，單活架構、雙活架構和冷備架構。從容災能力角度來看，雙活架構和冷備架構均能做到應用級跨機房容災，但是資料庫因為使用了異步複製的技術，無法做到機房級RPO=0的容災。再看灰度發布的能力，冷備架構和雙活架構都只能做到機房級灰度發布，無法做到更細粒度的灰度發布。