分散式資料庫替代傳統商業資料庫是近年最熱門和最具爭議的話題。理論上沒有什麼資料庫不能被替代，現實卻往往是代價大到難以承受。怎樣才能更好的降低替代帶來的代價呢？開源資料庫TiDB創始人黃東旭在《近十年資料庫流行趨勢縱覽！儲存計算分離、ACID 全面迴歸……》將“儲存和計算分離”作為近年資料庫改造流行趨勢之首，其作用就是降低資料庫替代的代價。本文將透過分析當前主流廠商的資料庫計算和儲存分離（簡稱存算分離）對資料庫替代中一些棘手問題進行解析，供分散式雲原生資料庫開發和使用者參考。

計算和儲存分離是行業巨頭共同的選擇

回顧存算分離的發展歷程，今天倡導分離的，恰巧就是當年提出計算和儲存一體架構的網際網路和雲計算巨頭們。到底存算分離有什麼獨特的魅力，我們看看業界的巨頭大V怎麼說？

作為公有云的開創者，AWS在十多年前就推出了Hadoop託管服務EMR。EMR採用了S3儲存替代HDFS作為儲存層：“與本地叢集要求嚴格的基礎設施不同，EMR可以將計算和儲存分離，使您能夠獨立擴充套件每層並利用 Amazon S3 的分層儲存。利用EMR，您可以預置一個、數百個甚至上千個計算例項或容器來處理任何規模的資料，只需要按實際使用量付費。” 這反映出AWS對存算分離帶來價值的認知：靈活擴充套件和節省成本（按量付費）。這顛覆了長期以來大家對使用外接儲存擴充套件性差，成本高的認知。在歷經市場考驗後，也被業界紛紛效仿。

阿里副總裁，資料庫產品事業部總裁李飛飛在《雲原生分散式資料庫與資料倉庫系統點亮資料上雲之路》中說：“傳統的馮諾依曼架構下計算和儲存是緊密耦合的，可將多個伺服器透過分散式協議和處理的方式連成一個系統，但是伺服器和伺服器之間、節點和節點之間，分散式事務的協調、分散式查詢的最佳化，尤其要保證強一致性、強ACID的特性保證的時候，具有非常多的挑戰……雲原生的架構，本質上底下是分散式共享儲存，上面是分散式共享計算池，中間來做計算儲存解耦，這樣可以非常好地提供彈性高可用的能力，做到分散式技術集中式部署，對應用透明。”

阿里的雲原生資料庫重新回到提升資料庫Scale Up擴充套件能力的路上，來解決分散式事務，彈性擴充套件的問題。在必要時可以結合分散式分庫分表模式進行Scale Out擴充套件。

華為雲資料庫專家也表示“高可用、易用易維、高擴充套件、高效能、與大資料相輔相成的雲資料庫，尤其是基於雲場景架構設計的雲原生分散式資料庫，計算與儲存分離、能充分發揮最新硬體效能、利用 AI 和 ML（深度學習） 等功能成發展趨勢。”

上面幾家是上（資料庫）下（儲存）內（自有業務）外（公有云）通吃的，而Facebook這種自己玩的網際網路廠商完全從自己的業務需要出發，研發了一套溫資料儲存，以存算分離的架構來支撐億的使用者量產生的大資料。而Snowflake走了一條採用通用物件儲存構建公有云資料倉庫服務的道路，並實現了資料倉庫的計算無狀態化。

雲原生中無處不在的存算分離

雲原生一直在努力實現無狀態化，而實現的手段就是把資料層剝離出去！只不過在應用層，資料可以剝離給快取、資料庫、檔案儲存和訊息佇列，而資料庫、訊息佇列等要雲原生時就只能自己做存算分離了。像最近大火的訊息佇列Apache Pulsar 給自己的定義是這樣的：“Apache 軟體基金會頂級專案，下一代雲原生分散式訊息流平臺，集訊息、儲存、輕量化函式式計算為一體，採用計算與儲存分離架構設計，支援多租戶、持久化儲存、多機房跨區域資料複製，具有強一致性、高吞吐、低延時及高可擴充套件性等流資料儲存特性。”

而對於Pulsar的雲原生特性則是這麼描述的：“Pulsar使用計算與儲存分離的雲原生架構，資料從Broker搬離，存在共享儲存內部。上層是無狀態Broker，複製訊息分發和服務；下層是持久化的儲存層Bookie叢集。Pulsar儲存是分片的，這種架構可以避免擴容時受限制，實現資料的獨立擴充套件和快速恢復”。

可見實現雲原生存算分離已是無處不在，只不過不會直接感知到它罷了。

何為計算、儲存、分離

計算：提供計算能力的不可變基礎設施

存算分離中計算的變化比較小，也更容易理解，不管是一開始的虛擬機器，還是現在最常用的容器，計算部分都是為資料庫提供算力，其最基本的資源是CPU和記憶體。一些“計算”還會用伺服器本地盤作為快取，但並不包括持久化資料。這也使“計算”不斷接近雲原生中對不可變基礎設施的要求。

儲存：能力不斷增強的資料持久化資源池

相對計算，儲存的能力，形態則變化較大。但不管是物件儲存，HDFS儲存，KV儲存，檔案儲存，還是像AWS那樣提供了部分資料庫儲存引擎功能的“計算儲存”，不管是自研的還是購買第三方儲存，是雲服務還是線下儲存，存算分離中的儲存始終承擔著資料持久化的工作。這一點是理解存算分離的關鍵，也是存算分離的主要價值之一。

分離：下刀的位置因時而變

分離容易理解，但怎麼切是有講究的，它反映了需求，能力，甚至商業考量。如果想讓儲存多做點事，可以切得狠一點，像AWS Aurora把日誌引擎都切給儲存了，如果想通用一些，也可以像阿里PolarDB那樣正常地切，以至於底層換個儲存也能用。如果想封閉圈子自己玩，就切給自己家儲存，並且切完了還會連著一點點（封閉介面），公有云基本就是這種做法，如果不想自己研發儲存，就切給通用儲存，如果想賣儲存，就按通用介面來切，華為，浪潮的大資料儲存，騰訊的HDFS儲存都是這個套路，這些都來自商業的考量。

技術發展使存算分離成為可能

存算分離能再次流行是因為之前受限於的技術障礙：傳輸效能與儲存能力問題已得到解決。

技術拐點：分離正當時

每一次網路技術的進步都會對我們系統架構產生重大影響，大量資料相互間同步，既要低延時又要高頻寬，如果沒有網路技術的進步無法實現，然而每個短板被填補以後都會帶來IT架構的變革，FaceBook在其闡述溫儲存大資料研發的原因中提出了“技術拐點論”非常準確的說明了當下為什麼可以實現存算分離的技術原因：傳輸協議和頻寬能力已不再是IO瓶頸。

高速乙太網：吞吐量大幅提升而成本和部署靈活性相比FC和IB有大幅度改善，足以應對從當年的千兆邁入10GE，25GE，甚至100GE時代。

無阻塞轉發網路：比如FaceBook採用了CLOS網路拓撲，實現了分解式的網路，網路不會成為效能瓶頸，同時提供了靈活的組網能力。

RoCE（RDMA over Converged Ethernet ）和NOF（NVMe over Fabric）：帶來網路訪問高效能、低延遲和低協議負擔的優勢。阿里PolarDB和AWS最新的IO2 Express使用了RoCE。

無損網路：保證網路穩定性，使乙太網可以用於高速關鍵業務。

而相對於傳輸能力和協議的發展，近年介質能力和協議的提升並不大，這就使當初使用本地盤方案要解決的問題不再存在了。

全棧方案廠商儲存能力積累 新通用儲存+資料庫形成開放架構

這個“新”指通用儲存具備的新特性，既能提供比本地盤更好的能力，也有別於傳統儲存。對於存算分離，比較關鍵的特性包括：

低成本：這主要針對如類似資料湖這種海量資料應用，而對交易類資料庫，因為規模相對小並且關注點不同，則不一定是關注重點；

高效能：交易類的業務效能要求高，往往要求亞毫秒級時延和極高的效能密度（IOPS/GB），全快閃記憶體儲存是比較合適的選擇；

擴充套件性：現在的企業儲存也開始採用分散式架構，提供Scale-out和Scale-up兼具的、更好的分層擴充套件能力，不再有擴充套件性問題；

量身打造的功能：比如專門用於大資料的HDFS儲存，用於增強MySQL等開源資料庫能力的可計算儲存等。

需求決定是否要做存算分離

技術決定可行性，需求決定必要性。分散式雲原生資料庫採用存算分離架構的需求來自兩方面：利用“雲”的優勢和提升資料庫能力，也就是降低資料庫替換中的代價。瞭解存算分離能解決哪些問題及解決方法，對是否需要以存算分離以及如何規劃構建存算分離方案意義重大。

雲的必然選擇

由於新一代資料庫，尤其是分散式資料庫，普遍採用雲計算部署方式，甚至一些新生代資料庫就是為雲而設計的。即使不考慮雲的因素，分散式資料庫改造造成的叢集規模暴漲也需要考慮資源分配，彈性擴充套件，故障切換自動化等需求。對於分散式資料庫來說採用存算分離可以歸結為資源使用和雲原生的需要。

雲原生：不可變基礎設施帶來可靠性提升和彈性擴充套件能力

上文提到儲存的主要功能是實現資料持久化，從而實現不可變基礎設施。那麼我們來看看存算分離以後，儲存帶來的價值。

首先是計算發生故障時，由於不需要重新在新伺服器上恢復資料，因此例項可以快速恢復。如Aurora採用了共享儲存架構的一寫多讀架構，只需要在計算例項間同步少量快取資訊，因此讀例項可以快速恢復成主例項，理論上可以接近ORACLE RAC的切換速度。

其次即使例項間沒有使用同一份共享儲存，在存算分離後，也不需要全量恢復資料了，這樣資料庫恢復到工作狀態的時間就大幅度縮短了。京東就採用了這種方式，避免了資料恢復中日誌恢復慢和高負載下可能追不上日誌的問題。

另外存算分離後計算例項可以擺脫物理伺服器的束縛，任意遷移且不需要進行資料同步，這使得彈性擴充套件變得極為容易。

把規劃變簡單，提升資源使用效率

對於資料庫這類複雜的應用如果使用伺服器本地盤，在資源規劃時要考慮CPU、記憶體、儲存容量/IOPS/ 頻寬，網路IO/頻寬，差不多7個維度。這會有多複雜呢？

我們平常接觸的世界是三維的相對論把世界變成了4維，但也只解釋了引力，另外三個要靠量子力學。而要統一相對論和量子力學，目前最有希望的理論弦理論認為世界是11維的！雲計算解決這個問題的思路與物理學一樣，一靠近似，就是忽略到一些維度，比如不管需求有多少，把伺服器的配置統一成兩三種。但這樣一來，資源利用率不可能高。二是像拆分出相對論和量子力學兩個看似矛盾的理論一樣，把計算和儲存解耦，這便是李飛飛“雲原生的架構，本質上底下是分散式共享儲存，上面是分散式共享計算池，中間來做計算儲存解耦”的目的。

以較小代價提升資料庫整體能力的需要

李飛飛在《雲原生分散式資料庫與資料倉庫系統點亮資料上雲之路》提到：“一旦做了分散式架構，資料只能按照一個邏輯進行Sharding和Partition，業務邏輯和分庫邏輯不是完美一致，一定會產生跨庫事務和跨Sharding處理，每當ACID要求較高的時候，分散式架構會帶來較高的系統性能挑戰，例如在高隔離級別下當distributed commit佔比超過整個事務的5%或者更高以上的話，TPS會有明顯的損耗。”

其實這只是架構導致的問題之一。如果對比一下企業資料庫，Hadoop，和MySQL的主從同步方案就會發現：前兩個都有專門的本地可靠性方案（一般是同機房），而MySQL的主從同步方案是在CAP中優先保證效能，犧牲一致性。加上MySQL的增強半同步很容易在大事務等情況下退化成非同步複製，因此即使是同機房內，仍然有很大丟失資料風險。前面分析過，Hadoop因為有獨立的HDFS儲存層，它的可靠性是構建在HDFS儲存層之上，而不是像MySQL構建在主從同步或MGR之上。相對來說，前者的效率要更高，可靠性更好。業界大佬們採用存算分離，就是因為架構變化能帶來事半功倍甚至從0到1的改變，從而“讓資料庫替換的代價變小”。

縱觀業界的資料庫存算分離方案，除了之前提到的雲原生之外，一般會從這幾方面入手。

可靠性

儲存本身就有非常好的本地和災備可靠效能力，反倒是伺服器的可靠性偏弱。儲存可以實現本地盤很多無法實現或難以實現的可靠性功能：

本地可靠性冗餘：基於本地盤實現冗餘有丟資料風險，有些則很困難，如對 NVMe盤的RAID，或者效率上不如在儲存上實現。不過必須指出同樣由於像MySQL這樣的資料庫缺少專業的本地可靠性方案，本地可靠性切換接管需要專門的適配改造才能發揮出更大價值。

資料校驗：這個功能在儲存上是標配，但在伺服器系統層則很少考慮， 如果資料庫想做，那得自己開發這部分功能。

高可用：以MySQL為例，大事務或批處理業務都可能導致半同步退化。相對來說儲存層實現容災對資料庫壓力的敏感性要低。

備份：資料庫備份恢復要依靠全量副本+增量日誌，恢復時間會相當長。而儲存一般都有快照複製能力，AWS和阿里更是把雲備份的功能就建立在儲存上了，在資料庫實現存算分離後，直接將這部分功能用起來就可以了。

效能

解決可靠性問題時，一些效能消耗可以避免或降低，如增強半同步對效能的影響。

儲存對效能的最佳化，如對SSD介質的最佳化催生了全快閃記憶體儲存，採用端到端NVMe over Fabric降低IO路徑和時延，專用的快取演算法等提升效能。

新技術的應用，如對SCM，FPGA的應用。

QoS實現對儲存 IO的隔離在作業系統層面很困難

總結

雲原生分散式資料庫的高速發展，必然帶來計算、儲存的分離，“存算分離”是當前網路技術發展和社會經濟進步的時代產物，是最適合當前時代發展需求的一種架構。資料庫的存算分離是儲存、雲計算、資料庫的技術的綜合，對於資料庫使用者和IT規劃師，可以關注這一技術方向和其中的技術實現，來解決面臨的問題。