歷史上，數據庫“存算一體”和“存算分離”的變更
第一代的“存算一體”數據庫是80年代的IBM大機，提供計算、數據庫、存儲、中間件，解決了核心交易場景對性能和可靠性的訴求，但他的缺點同樣明顯，貴！高昂的采購費用、封閉的硬件生態(tài)和高昂的售后維保價格，大機的壟斷，即使是銀行這類不差錢的企業(yè)也感到肉疼。大機有限的存儲擴展能力，也限制了數據庫的容量。
隨著商用數據庫和高端存儲的發(fā)展，IOE架構出現了。IOE指以IBM小型機、Oracle數據庫和EMC存儲設備為代表的IT基礎體系。這一架構極為“先進”和“開放”，打破了大機的壟斷，在性能和可靠性上也完全滿足企業(yè)業(yè)務的訴求。這一架構的出現，讓數據庫從“存算一體”，走向了“存算分離”。諷刺的是，隨著這一架構的發(fā)展，形成了新的壟斷。
隨著云和互聯網技術的飛速發(fā)展，數據量和用戶量激增，雙11購物節(jié)、12306春運搶票等突發(fā)業(yè)務對數據庫業(yè)務造成了巨大的沖擊。IOE架構欠缺橫向擴展能力，讓數據庫無法滿足激增的性能訴求和靈活擴容訴求。
芯片技術持續(xù)發(fā)展，Intel的Tick-Tock策略，讓芯片制程和架構以每兩年一次的周期進行更新，CPU的性能隨之水漲船高。X86通用服務器享受到了這一紅利，其性能越來越高，成本越來越低。ARM生態(tài)的持續(xù)發(fā)展，讓ARM架構的處理器在服務器領域也開始嶄露頭角，讓企業(yè)擁有了更多的選擇。分布式數據庫無最大節(jié)點數的限制，巨大的性能沖擊可分散到海量的服務器集群并發(fā)處理。用戶需求的催化和服務器硬件的發(fā)展，使得分布式數據庫‘火’了起來。
分布式數據庫部署靈活，極為契合云原生應用使用場景，再加上企業(yè)擺脫IOE依賴的商業(yè)考量，企業(yè)紛紛嘗試使用通用服務器打造靈活易擴展的分布式數據庫，數據庫由“存算分離”再次轉向“存算一體”。
“存算一體”架構
數據庫“存算一體”不是終極解決方案
從歷史上的“存算一體”和“存算分離”變更來看，客戶需求和業(yè)務需求的變化才是推動架構變更的根源。
那么，當前“存算一體”的架構是否完全滿足客戶和業(yè)務的訴求呢？答案是否定的。
企業(yè)試水分布式數據庫的初期，數據量不大，整個集群的規(guī)模有限，運行的往往不是最核心的業(yè)務，對性能和可靠性的要求相對不高。隨著業(yè)務的發(fā)展，數據量持續(xù)增加，分布式數據庫單庫性能較差，需要拆分成500G左右的分片。為了滿足性能和可靠性要求，企業(yè)往往通過堆疊服務器來解決，導致數據庫集群的規(guī)模越來越大，TCO持續(xù)增加。
為了實現高可靠，分布式數據庫通常采用1主多從的架構，多個從節(jié)點大部分時間都處于閑置狀態(tài)，導致CPU資源利用率極低。每一臺服務器就是一個數據孤島，存儲無法按需分配，數據在服務器間流動困難，導致存儲利用率低且存在單點性能瓶頸。服務器故障后，無法自動切換，需投入大量人力和時間手工恢復數據，可用性變差。某運營商的核心分布式數據庫，CPU平均利用率7%，存儲利用率低于40%，節(jié)點故障平均4TB數據需要投入5人3小時恢復，分布式數據庫“存算一體”架構資源浪費和可用性差已經成為了企業(yè)的核心之痛。
分布式數據庫“存算分離”如何解決企業(yè)核心之痛
“存算分離”架構
提升資源利用率“存算一體”架構需要考慮CPU、內存、存儲容量/IOPS/帶寬，網絡IO/帶寬，多達7個維度，任意一個維度的資源不滿足就會導致無法滿足應用訴求。而“存算分離”，按照計算和存儲兩個維度，將這7個維度拆分為兩個領域，降低選型復雜度。分別構建計算資源池和存儲資源池，提升資源利用率。擴容可實現計算和存儲的按需擴容，節(jié)約投資。
高可用外置存儲陣列本身有非常好的可靠性設計，如RAID冗余、靜默數據校驗、兩地三中心等可靠性保障，其可靠性等級高于服務器至少兩個數量級，因此存儲應該是一個“長期”的共享存儲。服務器的可靠性偏弱，“存算分離”后，即使服務器故障，由于全局共享一份數據，可實現免數據復制快速恢復業(yè)務，實現分布式數據庫整體的高可用。
高性能采用“存算分離”架構后，由于全局共享一份數據，一些不必要的消耗可以被避免，可提升數據庫整體的性能表現。例如半同步，每增加一個從節(jié)點都會導致10%的性能下降。采用“存算分離”后，不再需要半同步技術。
外置存儲陣列對性能的優(yōu)化更加深入，全閃存存儲，尤其是全NVME的存儲，可提供極致的性能體驗。存儲共享資源池不僅可提升資源利用率，還能利用不同應用不同時間對存儲性能峰谷要求不同的特點，將所有的IO分散到所有的磁盤，實現削峰填谷，達到最佳性能。
“存算分離”將走向何方
著名開源數據庫TiDB創(chuàng)始人黃東旭在《近十年數據庫流行趨勢縱覽！存儲計算分離、ACID 全面回歸......》一文中將“存儲和計算進一步分離”作為近年數據庫流行趨勢之首。那么‘進一步分離’到底如何做呢？且看業(yè)界大牛的做法。
數據庫存儲引擎能力下推阿里副總裁，數據庫產品事業(yè)部總裁李飛飛在《云原生分布式數據庫與數據倉庫系統點亮數據上云之路》一文中，提出了下一代分布式數據庫系統架構，在“存算分離”的基礎上繼續(xù)將原本在服務器間進行同步的Redo Log下推到共享存儲資源池，不再需要同步日志，減少了服務器主從同步的消耗。
亞馬遜的首席技術官兼副總裁在Werner Vogels在《Amazon Aurora 是如何設計原生云關系型數據庫的？》一文中介紹Aurora的“存算分離”架構。這一架構將在“存算分離”的基礎上，將原來在計算節(jié)點處理的緩存層和日志層功能下推到共享存儲，可提升5倍的寫IOPS。
多主架構與多寫多讀2022年1月20日，阿里對多主架構進行了灰度發(fā)布，面向多租戶、游戲、電商等高并發(fā)讀寫的應用場景，實現從一寫多讀架構到多寫多讀架構的升級。多主架構是為了解決寫性能瓶頸問題。
同阿里一樣，亞馬遜從Aurora MySQL 版本1開始，提供了多主集群和多寫能力，在多主集群中，所有數據庫實例都可以執(zhí)行寫操作，以提供故障時的“持續(xù)可用性”。
在2021年第四屆中國金融科技產業(yè)峰會上，華為攜手愛可生、海量數據發(fā)布的分布式數據庫存儲解決方案，提出通過數據多寫使能引擎、數據共享加速引擎、數據持久保護引擎，三大引擎技術重新定義分布式數據庫‘存算分離’架構。
這一架構采用華為的OceanStor Dorado全閃存作為共享存儲資源池，支持分布式數據庫多主架構，支持多寫多讀，免分庫分表，提升計算密度。將page管理和日志管理下推到OceanStor Dorado全閃存，讓企業(yè)存儲來取代服務器做數據同步，降低服務器開銷，提升數據庫整體性能。
今天，各個廠商，不論是國外國內，不論是互聯網企業(yè)還是傳統ICT企業(yè)，關于分布式數據庫“存算分離”的看法和做法，都是一致的。即在“存算分離”的基礎上，進一步將原服務器運行的數據庫存儲引擎功能進一步下推至共享存儲，釋放計算節(jié)點的算力，提升單節(jié)點數據處理能力；推出多主架構，拋棄從節(jié)點，節(jié)省大量服務器投資；支持多寫多讀，充分發(fā)揮共享存儲資源池共享一份數據的優(yōu)勢，免數據拷貝，降低故障切換時間。
未來，共享存儲必將取代傳統的分布式數據庫存儲引擎功能，結合容器技術，分布式數據庫將完成無狀態(tài)化改造。
免責聲明：此文內容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權歸作者所有，且僅代表作者個人觀點，與極客網無關。文章僅供讀者參考，并請自行核實相關內容。投訴郵箱：editor@fromgeek.com。
免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。
