雲端運算下如何平衡擴充性和穩定性SLA
雲端運算環境下，企業和個人通過開啟雲端服務，即可以得到所需的軟體功能、計算資源、儲存空間，並按實際使用量付費。在業務量逐步上漲的過程中，使用者需要不斷提升計算和儲存資源來滿足業務需要。因此，擴充性是雲原生服務非常重要的服務指標。
PolarDB的共用儲存架構帶來了最優的擴充性。當使用者計算資源不足時，可以在不影響業務的情況下，動態擴充計算節點規格和數量。新增加的節點，直接存取共用的資料副本，不需要做任何資料拷貝，所以擴充節點的耗時可以達到1分鐘內，而與資料量無關。PolarDB同時內建Proxy能力，可以將負載平衡到各個節點，使得加減節點操作對業務透明。在儲存層，所有使用者共用一個規模巨大的儲存叢集。儲存叢集可以動態添加新的儲存資源，因此PolarDB理論上可以做到無限的儲存容量擴充。
除了擴充性，穩定性也是雲原生服務的核心指標。穩定性由RPO、RTO等指標定義。為了保障穩定性，在靠近使用者業務的計算層，PolarDB盡量讓使用者獨享資源，使用者間進行強隔離；在網路和儲存層，採用多租戶形式。為了達到更好的穩定性和效能，PolarDB採用了全使用者態的儲存鏈路。在儲存層，將每個使用者的資料充分打散到多個儲存節點，充分利用節點的空餘資源，並保障IO訪問的延遲和頻寬。在部分儲存節點出現熱點資料、資源緊張時，PolarDB會自動遷移部分資料到其他節點。採用專屬的Parallel-Raft技術，每份資料會有三個副本，每次IO都保證至少有兩個副本落盤，保障了RPO。由於是共用儲存架構，節點間狀態接近於完全同步，當一個計算節點故障時，可以快速切換到其他節點，保障了RTO。在Proxy的協同下，甚至可以做到節點切換對應用無感知
傳統分布式架構與儲存計算分離架構對比
分散式資料庫其實已經有了不短的歷史，早期的分散式資料庫，在整體架構上可以分為share nothing和share disk兩大類。
share disk通過擴充底層的SAN來提升IOPS以及儲存容量， 但是SAN的擴充性較差，成本也非常高， 因此此類架構往往被用於解決多活的高可用問題。
share nothing的資料庫是過去分散式資料庫架構的首選，被諸多互連網公司所採用。
share nothing架構的分散式資料庫， 每一個節點擁有獨立的計算和儲存資源，每一個節點都有各自的計算引擎和儲存引擎，計算儲存綁定。 這種類型的架構好處顯而易見， 資料Sharding的方式讓資料存取以及處理可以並行化，計算儲存本地化最大化提升了資料讀寫的頻寬以及延時。在過去網路IO還是一大瓶頸的年代， 分布式系統設計以及最佳化的一大原則就是盡量使得計算儲存本地化， 避免昂貴的網路開銷。 然而share nothing架構對於跨分區的資料訪問不是很友好， 比如事務，比如全域索引，實現起來十分複雜， 效率也要打上折扣，並且因為計算資源和儲存資源是綁定的，因此資料幾乎是在所有節點上是均勻分布，在叢集擴充時，計算和儲存要一起擴充，會存在資源浪費的情況，並且share nothing架構的資料庫在儲存擴充的過程中要做資料重分配，這種記錄層級的遷移需要耗費大量的計算資源，會導致遷移過程中服務效能的顯著下降。並且因為資料無法共用，因此這樣的資料庫系統往往會形成資料的孤島，很難做一些跨庫跨應用的計算。
儲存計算分離是近年來分布式系統設計架構的潮流， 從2001年開始Google的GFS開創先河地開始使用了普通X86伺服器和硬碟搭建了大規模的儲存， 雖然受限於當時網路的傳輸速度，和機器間的頻寬，還是需要耦合計算和儲存節點的分布。 但是隨著底層硬體和網路的不斷髮展，儲存計算分離的趨勢越來越明顯，計算節點通過網路來訪問儲存的系統瓶頸也逐漸從IO變成了CPU。 當前的資料中心已經有了25G，50G和100G的網路， 系統瓶頸也逐漸層成了資源使用率。隨著雲的概念不斷髮展，公用雲端廠商使用基於網路的Block Storage逐步代替了單機的本機存放區，在這樣的基礎架構下計算和儲存耦合的架構已經變得不透明不合理，此時儲存計算分離的架構的優勢體現了出來，儲存計算分離，分布式儲存系統使用高密度，低功耗的伺服器來解決儲存容量的水平擴充問題， 計算叢集使用高主頻，多CPU，大記憶體的機型解決計算能力擴充的問題，模組之間互相解耦，獨立按需擴充，提供了更好的彈性以及整體資源使用率。同時儲存計算分離架構在擴充儲存時因為不再是記錄層級的遷移，不需要過多考慮資料庫系統諸如事務完整性、一致性等問題，過程中耗費的計算資源相比share nothing架構的資料庫系統大幅下降。 可以說儲存計算分離是雲時代資料庫產品的事實主流架構， 無論是OLAP還是OLTP的系統， 越來越多的系統地已經採用了此架構或者是正在向著此方向演化發展。
分散式交易與集中式事務的優劣
交易處理是資料庫保證ACID語義的核心功能，因為資料庫系統需要處理大量的並發事務，為了保證並發事務能夠儘可能高效的並發執行而又互不干擾，發展出若干種技術，比如多版本並發處理(MVCC)，開放式並行存取處理(OCC)，這些技術的關鍵在於多個事務同時讀寫相同的資料記錄時，如何調度事務的執行順序（等待或是復原）保證結果符合預期。
在事務集中在單個節點處理時，事務提交的順序是單個時鐘的順序，是很好確定的，這也是集中交易處理的好處，容易保證嚴格的外部一致性。在分散式資料庫中，同樣也可以採用這種模式，將事務集中在一個節點處理，而這限制了交易處理的擴充能力，系統能處理的事務操作的資料範圍受限於單個節點所能訪問的資料範圍，交易處理能力也受限於單個節點的處理能力。