分布式數據庫技術及發展趨勢研究_第1頁
分布式數據庫技術及發展趨勢研究_第2頁
分布式數據庫技術及發展趨勢研究_第3頁
已閱讀5頁,還剩6頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

分布式數據庫技術及發展趨勢研究引言數據庫是高效組織、存儲、管理數據的軟件,是構建信息世界的基礎工具。從第一款商業化關系數據庫誕生開始,數據庫管理系統已經走過 40多年的歷史,在發展過程中分化為向事務處理和面向分析決策的數據庫,在商業產品之外,誕生了開源的數據庫,并逐漸成為一個主流方向。數據庫管理系統起初都是單機形式,主要服務于銀行、航空公司、宇航局等大型企業,2000 年后隨著在線業務的蓬勃發展,很多系統都面臨處理高并發、大數據量、超高峰值等挑戰,數據庫開始了分布式之旅來應對這些挑戰,這條路先從分析場景開始,然后擴展到事務處理領域。這兩者面臨的難度截然不同,分布式分析數據庫主要解決海量數據的存儲、查詢分析的需求,主要是應對擴展性、高可用等挑戰;而分布式事務數據庫主要解決分布式事務的問題。分布式數據庫發展歷程20世紀80年代,伴隨著關系數據庫理論的誕生, BMOracle 兩家公司開始提供商業化的數據庫產品,服務于各類大型企業。初期的數據庫都是單機軟件, 跑在專有的硬件之上比如IBM的大機、小型機,如果業務量或者數據量增加,只能進行垂直擴展,即采用增加 CPU、存儲的方式。這套體系的優點是非常穩定,缺點是開放性不夠,與通用 x86服務器體系之上的開發環境兼容性差,另外當業務量增長過快時,其擴展能力有限,而且這套系統的造價非常昂貴。2000 年以后,隨著互聯網在線業務的發展,業務系統訪問的并發度呈指數級上升, 海量數據計算和分析需求越來越遍,傳統單機系統在業務支撐、成本、開放性等方面均面臨巨大挑戰,數據庫垂直擴展的模式也無法維系。 以支付業務為例隨著在線購物、在線繳費方式的普及,支付業務系統的并發量迅速增長,尤其是在“雙十一”“ 618”“春節搶紅包”等場景下,每秒有上百萬筆支付交易。 互聯網企業開始探索新的水平擴展的方案,最常見的就是應用系統通 過分庫分表進行解決。但是,這種解決方案的應用系統需要做大量改造, 需要感知數據存位置,增加了運維的復雜性,并因此出現了中間件的方式,如Mycat等。這種方式雖實現了數據對應用的透明,但未解決數據庫運維的痛點。隨著大數據技術的發展,以 Hadoop、Greenplum 為代表的非結構化大規模數據處理技術崛起,這些技術主要采用Shared-nothing 架構在分析領域率先實現了分布式的擴展,分析的主要任務是數據的查詢, 其應對的挑戰主要是海量數據的存儲、計算,對于事務的要求較低。2010年后,谷歌Spanner、Tidb采用Paxos或Raft等一致性協議來解決中間件方案的單點瓶頸問題,這為事務數據庫的分布式化提供了新的理論依據。分布式數據庫核心技術分布式數據庫是指數據在物理上分布而在邏輯上集中管理的數據庫系統。分布式數據庫的主要特點有3個:一是透明性。對于用戶來說,分布式數據庫相當于一個單機數據庫,屏蔽了底層多節點、數據物理分散、副本一致性等細節問題;二可用性,當某一節點中的數據不可用時,其他數據副本可以繼續保證業務的連續性,還可以對數據就近計算, 減少網絡消耗提升性能;三是易擴展性。分布式數據庫能夠通過水平擴展來提升整體的處理能力, 數據可以被動態地分布到新增節點之上消除數據傾斜。分布式數據庫的核心技術包括數據復制,即不一致性、隔離性、持久性挑戰。數據復制數據復制是一種實現數據備份的技術, 可以保證存儲在同節點上的同一份數據是一致的。這樣當一個節點發生故障后,可以從其他存儲該數據的節點獲取數據,避免數據丟失,進而提高了系統的可靠性。在一個分布式系統中,一致性、可用性、分區容錯性三者不可兼得。其中,一致性指在分布式系統中所有數據備份在同一時刻的值是否一致; 可用性指分布式系統中一部分節點發故障,集群能否繼續響應客戶端的讀寫請求;分區容錯性是指在分布式系統遇到網絡分區的情況下, 仍然可以響應用戶的求。在實際情況中,網絡通信是不可靠的,分布式系統必須具備分區容錯性,那么分布式系統必須選擇在發生分區后,是中止服務等待數據同步來保證一致性,還是繼續提供服務,忽略各個節點可能的數據不一致性。對于分布式數據庫的數據復制技術來講,需要在一致性和可用性之間做出權衡,一般來說一共有同步復制、異步復制、半同步復制3種數據復制技術。同步復制要求主備節點都完成便立即返回,不需要等待備節點更新完成;而半同步復制則要求主節點更新完成,并且有一個或半數以上的備節點更新完畢才返回更新成功。這 3類技術都有其合適的使用場景,均廣泛應用于分布式數據庫中。數據分區單臺機器很難應對海量的數據或者很高的并發查詢, 需把數據拆分到多個節點上,在多個節點上進行存儲和處理,這種技術叫做數據分區也稱為數據分片。 數據分區的主要目的提高可擴展性,使數據分散到多個分區,如果對單個分區進行查詢,每個節點都只對自己所在的分區進行獨立查詢。數據分區有水平分區、垂直分區兩種類型,水平分區是將表的內容按照某種規則分散到多個節點上, 每個節點包含表的于分區的方式主要有基于關鍵字區間分區、 基于關鍵字哈希分區兩種,其中基于關鍵字區間分區首先對關鍵字進行排序,每個分區只負責一段范圍內的關鍵字, 這種方式能夠提供良的區間查詢特性,缺點是會導致熱點;基于關鍵字哈希值分區能夠將關鍵字均勻地分配到多個分區中, 每個分區負責一定圍的哈希值,可解決數據傾斜和熱點問題,但其區間查詢效率較低。隨著時間的推移,數據庫的分區面臨著負載傾斜、熱點等問題需要進行分區的再度平衡, 目前主要有固定數量的分區動態分區、按節點比例分區等策略可供選擇。分布式事務事務主要是 ACID,分別代表原子性、一致性、隔離性持久性。分布式事務是對跨兩個或多個數據存儲庫(尤其是數據庫)執行的一組操作。它通常在由網絡連接的獨立節點之間進行協調,但也可能跨越單個服務器上的多個數據庫。經過多年的發展,業界已衍生出多種分布式事務解決方案,比如兩階段提交、TCC方案、基于消息的方案等。兩階段提交是一種在多節點之間實現事務原子提交的算法, 用來確保所有節點要全部提交,要么全部中止 。兩階段提交引入協調者這個新角色,將執行過程分為準備[2]和執行兩個階段。當應用程序準備提交事務時,協調者開啟階段并向所有節點發送一個準備請求,詢問他們是否可以提交,并等待參與者的回復。如果所有參與者答復“是”,表明都已經[2]準備好,協調者開啟階段2即執行提交。如果有任何參與者回復“否”,則表示有節點沒有準備好,那么協調者在階段 2中所有節點發送放棄提交的消息。 兩階段提交的一次成功執行如圖1所示。圖1 兩階段提交的一次成功執行TCC方案由GuyPardon提出,是TryConfirmCancel的簡稱,采用補償機制,分為3個階段:Try階段主要是對業務系統做一致性檢查,預留執行所需要的資源;Confirm階段直接開始執行,并使用Try階段預留的資源;如果業務執行失敗,則進入Cancel階段,釋放所有占用的資源,并回滾Confirm階段執行的操作[3]。典型分布式數據庫產品2000年以后,分布式數據庫發展迎來了熱潮,各類分布式數據庫百花齊放,從數據模型角度可以將分布式數據庫分為關系型和非關系型兩類,分布式關系型數據庫按照使用場景又可以被分為面向事務和面向分析兩類。下面著重介紹3款典型的分布式數據庫產品。GreenplumGreenplum 是Pivotal 公司的產品,在開源單機數據庫PostgreSQL 的基礎上進行了分布式的改造, 采用無共享架構每個節點的 CPU、內存等資源都是獨立的。一個 Greenplum集群通常由一個主節點、一個備主節點和多個從節點構成,節點之間通過高速網絡連接。作為分布式分析數據庫的典型代Greenplum首先具備高線性擴展能力,采用無共享架構到新增加節點上;其次具備高可用性,通過主備的模式和數據冗余來保障整個系統的高可用性;而且還能提供很好的通用性和兼容能力,除了可支持PostgresSQL語法外,還可支持多種SQL標準,包括SQL92、SQL99、SQL2003等,并且對JDBC、ODBC、PythonAPI也有良好的支持。除此之外,Greenplum還擁有支持數據模型的多態擴展、對事務有較好支持、開放性好等優點。SpannerSpanner是谷歌開發的分布式數據庫, 底層采用的是鍵值數據模型,經過 10年的演進,增加了強類型模式系統、 SQL查詢引擎和其他特性,并逐漸向關系型系統靠近 [5]。作為一個全球分布的數據庫,Spanner提供了幾個獨特的創新點。 首先應用程序可以對數據的復制配置進行細粒度的動態控制, 應用程序可以指定數據分布在哪些數據中心、 數據與用戶之間的距離、副本之間的距離以及需要維護多少副本 [6]。為平衡不同數據中心的資源,系統還可以在不同數據中心之間動態地移動數據;其次,通過實現全球時鐘同步, Spanner提供外部一致讀取和寫入,以及在時間戳上跨數據庫的全局一致性讀取;最后,在事務方面,Spanner采用了復制的預寫 Redo日志,本間通過 Paxos 一致性協議來對每個日志條目的內容達成共識,并且使用悲觀鎖定和時間戳的組合來控制并發。JanusGraph圖數據庫是一種以圖結構(點和邊)進行存儲和查詢的數據庫,是近期熱度最高的數據庫方向。 JanusGraph 是一個布式的圖數據庫,可以自由地擴展節點,能夠將數千億個頂點和邊的圖存儲在集群上,通過支持圖計算框架 ApacheTinkerPop 來提供圖數據庫( OLTP)和圖分析系統( OLAP的能力,不僅支持實時、數千用戶并發遍歷圖,還能提供圖分析查詢的功能[7]。JanusGraph 使用Gremlin作為查詢語言,其存儲依賴于第三方的分布式存儲系統(如Cassandra HbaseJanusGraph開放性較好,與大數據生態結合緊密,采用分布式的架構,并圖數據庫開源項目,未來有很大的發展空間。分布式數據庫技術發展趨勢隨著云計算、人工智能、新型硬件的發展,數據庫的架構隨之發生變化。為適配云的發展,計算和存儲分離成為一個必然趨勢,誕生了諸多云原生數據庫。而人工智能技術的演進為數據庫集群的運維、調優提供了新的思路。新的網絡、存儲、芯片的迭代更新進一步推動了數據庫架構的變化,眾多數據庫廠商都在積極嘗試利用新的硬件能力來提升性能。計算存儲分離以“就地計算”,減少了網絡開銷。其缺點也非常明顯,由于計進行,從而勢必產生資源浪費。在存算分離架構下,存儲層和帶來的資源浪費問題,也可以更好地與云平臺融合,適應云計算的發展趨勢;二是無損容災將數據庫容災問題轉化為更加成熟的分布式存儲系統的容災問題,而類Paxos協議在分布式存儲中被廣泛使用[8]。例如,Snowflake數據倉庫最早提出了獨特的存儲、計算以及管理服務分離的架構,使得計算層與緩存層并不強耦合[9]。在數據庫端,國內外云廠商近兩三年來都研發了存算分離的產品,包括AWS 的Aurora、阿里巴巴的PolarDB、騰訊的 CynosDB 等,為存儲和計算帶來了更好的擴展自由度和更佳的性能。智能化運維分布式數據庫通常部署在幾十臺到上千臺的機器上, 集故障的概率非常高,給運維人員帶來了很大的挑戰,而利用機器學習和統計學的手段來管理數據庫集群成為當前研究的熱點。Oracle自治數據庫能自動進行修補、升級和調優,因此無需人工干預或停機[10]PolarDB利用智能化的技術來調優數據庫,比如進行慢SQL優化、對緩存大小進行調優、進行熱點消除和故障檢測[11]。新型硬件新型硬件的發展為分布式數據庫的架構帶來了新的變化。分布式系統初始避免數據的搬移,減少網絡的 IO的開銷,隨著RDMA等高速網絡的發展,網絡 IO逐漸不再是瓶頸,從存儲向計算端搬移數據的效率變快了, 數據湖等統一的數據存儲層出現了。此外,大內存和高速硬盤漸漸普及, NVM等非失內存的發展,很可能顛覆計算機系統的結構,內存計算的潛力會慢慢爆發,分布式數據庫也在跟進內存計算的方向。在芯片層,數據庫之前以 CPU為調度核心,隨著 GPU、FPGAASIC等芯片的

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論