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