從託管到原生，MPP架構資料倉庫的雲原生實踐

2025-04-22 14:16 阿里技術

一  前言

Garner預測，到2022年，所有資料庫中有75%將部署或遷移至雲平臺。另外一家權威機構IDC也預測，在2025年，超過50%的資料庫將部署在公有云上，而中國則會達到驚人的70%以上。雲資料庫經過多年發展，經歷從Cloud-Hosted （雲託管）到 Cloud Native（雲原生）模式的轉變。
Cloud-Hosted：基於市場和業界的雲需求，大部分廠商選擇了雲託管作為演進的第一步。這種模式將不再需要使用者線下自建IDC，而是依託於雲提供商的標準化資源將資料倉庫進行移植並提供高度託管，從而解放了使用者對底層硬體的管理成本和靈計劃資源的約束。 
Cloud-Native：然而隨著更多的業務向雲上遷移，底層計算和儲存一體的資源繫結，導致使用者在使用的過程中依然需要考量不必要的資源浪費，如計算資源增加會要求儲存關聯增加，導致無效成本。使用者開始期望雲資源能夠將資料倉庫進行更為細粒度的資源拆解，即對計算，儲存的能力進行解耦並拆分成可售賣單元，以滿足業務的資源編排。到這裡，雲原生的最大化價值才被真正凸顯，我們不在著重於打造存算平衡的資料倉庫，而是面向使用者業務，允許存在大規模的計算或儲存傾斜，將業務所需要的資源進行獨立部署，並按照最小單位進行售賣。這一刻我們真正的進入了資料倉庫雲原生時代。
阿里雲在2021雲棲大會上，預告了全新雲原生架構的資料倉庫【1】。本文介紹了雲原生資料倉庫產品AnalyticDB PostgreSQL（以下簡稱ADB PG）從Cloud-Hosted到Cloud-Native的演進探索，探討為了實現真正的資源池化和靈活售賣的底層設計和思考，涵蓋內容包括產品的架構設計，關鍵技術，效能結果，效果實現和後續計劃幾方面。（全文閱讀時長約為10分鐘）

二  ADB PG雲原生架構

為了讓使用者可以快速的適配到雲資料倉庫，目前我們採用的是雲上MPP架構的設計理念，將協調節點和計算節點進行獨立部署，但承載於單個ECS上，實現了計算節點儲存計算一體的部署設計，該設計由於設計架構和客戶側自建高度適配，可快速並無損的將數倉業務遷移至雲上，對於早期的雲適配非常友好且滿足了資源可平行擴充套件的主要訴求。
隨著雲原生的進一步演進，我們提供了全新的存算分離架構，將產品進一步拆分為服務層、計算層和共享儲存層，架構圖如下：
Master協調節點：儲存全域性的schema資訊，並實現了全域性事務管理；
行存引擎：用來儲存元資料資訊，這裡的元資料資訊主要指共享儲存檔案的可見性資訊，包括兩個部分：
  • 一個是檔案與表的關係
  • 另外一個是被刪除的資料的delete bitmap
基於行存我們可以繼承PG的本地事務能力，在增刪改查的同時，與PG的事務能力完全相容；
本地快取：透過引入儲存團隊的DADI來實現高效能的本地快取，DADI全稱是Alibaba Cloud Data Accelerator for Disaggregated Infrastructure，相比開源產品，效能有數量級的提升；
共享儲存：我們借鑑了ClickHouse的一些關鍵設計，在儲存層實現了一個基於MergeTree的行列混存，此外我們對共享儲存基於檔案介面做了一層統一訪問介面，同時高度適配了OSS和HDFS 兩種形態的分散式檔案系統；
當我們在架構設計的時候，和同樣源自Greenplum的HAWQ對比，HAWQ把元資料都儲存在master，在每次寫的時候，把修改的元資料帶到master來更新，讀的時候，先從master讀取需要的元資料，然後在執行計劃裡面把元資料都帶上，這樣segment就能拿到對應的元資料， 同時segment可以完全無狀態。
但是這個設計會帶來2個核心問題：
1. 元資料膨脹導致master成為瓶頸。
2. 受限於元資料的效能，無法支援高併發的即時寫入。
而我們不這樣設計做的原因是我們希望在未來能夠支援高併發的任務，ADB PG大概花了2年多的時間，將Greenplum的單點master架構拓展為multi-master，核心是為了解決高併發即時寫入的問題，如果把元資料都儲存在master上會帶來如問題：
1. master上面的元資料儲存和訪問容易形成單點瓶頸
2.  需要對ADB PG的執行層做大量的重構，實現在執行計劃裡面把元資料都帶上，這會急劇的增加查詢計劃本身的頻寬，這個對於高併發的小查詢非常不友好。
所以我們改進了架構，將元資料分散到segment，規避並實現了：
1. master的儲存和讀寫都不會成為瓶頸
2.  無需對執行層做重構，將元資料分散減少單次查詢的頻寬壓力。
3.  將segment上的元資料放到分散式kv上，解決擴縮容的元資料搬遷問題。
共享儲存使用OSS的原因在於，隨著單個使用者業務資料不斷增長，需要一個可持續發展的儲存方案，而OSS的低儲存成本，高可用性和資料永續性是最好的選擇。
維度
OSS
ESSD雲盤（PL1）
成本
0.56元/GB/月
2元/GB/月
高可用
99.995%
99.975%
資料永續性
99.9999999999%(12個9)
99.9999999%（9個9）
使用OSS的另外一個好處在於按需付費，使用者不需要預製儲存空間大小，存了多少資料，付多少錢，資料刪除後即不再收費；ESSD雲盤通常需要根據資料計算儲存水位，無法做到將儲存資源真正的按需供應，而且無法自動縮容，這些都違背了我們雲原生的設計理念。但同時OSS的劣勢在於RT:
維度
OSS
ESSD雲盤（PL1）
RT
50 ms
200us
為了解決OSS的RT問題，我們為計算節點配置了一定比例的本地盤，用來做訪問加速。此外，我們設計了一個高效能的行列混存，借鑑了ClickHouse mergetree儲存的核心思想，以有序為核心，檔案內絕對有序，檔案與檔案大致相對有序，透過merge的非同步操作，實現檔案和並和排序，基於有序，我們在檔案內設計了3層的統計資訊，並做了大量的IO裁剪最佳化。
下面我們對每個技術點做進一步介紹。

三  關鍵技術

1  彈性伸縮

為了實現快速的彈性伸縮，我們的方式是資料在共享儲存上hash bucket來組織，擴縮容後透過一致性hash把計算節點和bucket做重新對映，為了解決bucket與segment分配的均勻性，並降低擴縮容後cache失效的影響，我們對傳統的一致性hash演算法做了改進，支援擴縮容時的動態對映。
把資料根據hash bucket分成多個分片，按分片粒度在擴縮容的重新對映物件儲存上的資料。如果擴容計算節點超過分片個數的時候，只能重分佈資料。為了解決這個問題，我們支援hash bucket可以後臺分裂和合並，避免重新分佈資料。
上述是擴縮容時“資料”的重現對映，而描述資料檔案可見性的元資料，由於儲存在行表中，我們還是使用了Greenplum的資料重分佈策略，不同的是，為了加速元資料的重分佈，我們做了並行化分佈等最佳化。
我們以擴容為例進一步細化擴容的流程：
結合ECS資源池化，網絡卡並行載入和docker映象預熱等技術，16節點內端到端的耗時接近1分鐘。

2  分層儲存

分層儲存的實現如下：
如上圖所示，我們把儲存的資源分成3層，包括記憶體、本地盤和共享儲存。
記憶體：主要負責行存訪問加速，並負責檔案統計資訊的快取；
本地盤：作為行存的持久化儲存，並作為遠端共享儲存的本地加速器；
遠端的共享儲存：作為資料的持久化儲存。

3  讀寫流程

寫入流程如下：
  • 使用者寫入資料透過資料攢批直接寫入OSS，同時會在本地磁碟上記錄一條元資料。這條元資料記錄了，檔案和資料表的對應關係。元資料使用PG的行存表實現，我們透過file metadata表來儲存這個資訊。
  • 更新或者刪除的時候，我們不需要直接修改OSS上面的資料，我們透過標記刪除來實現，標記刪除的資訊也是儲存在本地行存表中，我們透過visibility bitmap來存這個資訊。標記刪除會導致讀的效能下降，我們通過後臺merge來應用刪除資訊到檔案，減少刪除帶來的讀效能影響。
我們在寫入的時候，是按照bucket對segment上的資料做了進一步劃分，這裡會帶來小檔案的問題。為了解決小檔案問題，我們做了下面幾點最佳化：
1. Group flush：一批寫入的資料，可以透過group flush寫到同一個OSS檔案，我們的OSS檔案採用了ORC格式，不同bucket寫入到對應strip；
2. 流水線非同步並行：編碼攢批，排序是典型的cpu密集型任務，上傳到oss是典型的網路IO密集型任務，我們會把這2種任務型別並行起來，在上傳oss的任務作為非同步任務執行，同時對下一批資料編碼排序，加快寫入效能。
因為遠端持久化儲存提供了12個9的永續性，所以只有儲存元資料的行存才有WAL日誌和雙副本來保證可靠性，資料本身寫穿到共享儲存，無需WAL日誌和多副本,由於減少了WAL日誌和WAL日誌的主備同步，又透過非同步並行和攢批，在批次寫入場景，我們寫入效能做到了基本與ECS彈性儲存版本效能持平。
讀取流程如下：
  • 我們透過讀取file metadata表，得到需要掃描的OSS檔案。 
  • 根據OSS檔案去讀取對應檔案。
  • 讀到的檔案透過元資料表visibility bitmap過濾掉已經被刪除的資料。
為了解決讀OSS帶來的延遲，我們也引入了DADI幫忙我們實現快取管理和封裝了共享檔案的訪問，讀檔案的時候，首先會判斷是否本地有快取，如果有則直接從本地磁碟讀，沒有才會去 OSS讀，讀到後會快取在本地。寫的時候會直寫OSS，並回寫本地磁碟，回寫是一個非同步操作。對於本地快取資料的淘汰我們也透過DADI來管理，他會根據LRU/LFU策略來自動淘汰冷資料。
由於事務是使用PG的行存實現，所以與ADB PG的事務完全相容，帶來的問題是，我們在擴縮容的時候需要重新分佈這部分資料，我們重新設計了這塊資料的重分佈機制，透過預分割槽，並行複製，點對點複製等技術，極大縮短了擴縮容時間。
總結一下效能最佳化點：
•  透過本地行存表實現事務ACID，支援資料塊級別的併發；
•  透過Batch和流水線並行化提高寫入吞吐；
•  基於DADI實現記憶體、本地SSD多級快取加速訪問。

4  可見性表

我們在File Metadata中儲存了共享儲存檔案相關的資訊，它的結構如下：
欄位
型別
說明
table_oid
Int32
表的oid
hash_bucket_id
Int16
hash_bucket的id
level
Int16
邏輯檔案所處的merge級別，0表示delta檔案
physical_file_id
Int64
邏輯檔案對應的oss物理檔案id
stripe_id
Int64
邏輯檔案對應的oss物理檔案中的stripe id
Total_count
int32
邏輯檔案總共具有的行數，包括被刪除行數
Hash bucket：是為了在擴縮容的時候搬遷資料的時候，能夠按照bucket來掃描，查詢的時候，也是一個bucket跟著一個bucket；
Level：是merge tree的層次，0層代表即時寫入的資料，這部分資料在合併的時候有更高的權重；
Physical file id：是檔案對應的id，64位元組是因為它不再與segment關聯，不再只需要保證segment內table的唯一性，需要全域性唯一；
Stripe id：是因為一個oss檔案可以包含多個bucket 的檔案，以stripe為單位，方便在segment一次寫入的多個bucket合併到一個oss檔案中。避免oss小檔案，導致效能下降，和oss小檔案爆炸；
Total count：是檔案行數，這也是後臺合併的一個權重，越大合併的權重越低 。
Visibility bitmap記錄了被刪除的檔案資訊
欄位
型別
說明
physical_file_id
Int64
邏輯檔案對應的oss物理檔案id
stripe_id
Int32
邏輯檔案對應的oss物理檔案中的stripe id
start_row
Int32
delete_bitmap對應的起始行號，每32k行對應一個delete_bitmap
hash_bucket_id
Int16
hash_bucket的id
delete_count
Int32
該delete_bitmap總共記錄刪除了多少行
bitmap
bytea
delete_bitmap的具體數值，壓縮儲存
Start_row對應32k對應一個delete bitmap。這個32000 4k，行存使用的32k的page可以儲存7條記錄。
Delete count是被刪除的數量。
我們無需訪問oss，可以直接得到需要merge的檔案，避免訪問oss帶來的延遲，另外oss對於訪問的吞吐也有限額，避免頻繁訪問導致觸發oss的限流。

5  行列混存

Mergetree的結構如上圖左側所示，核心是通過後臺merge的方式，把小檔案merge成有序的大檔案，並且在merge的時候，我們可以對資料重排，例如資料的有序特性做更多的最佳化，參考後續的有序感知最佳化。與leveldb的不同在於：
1.  0層即時寫入的會做合併，不同bucket的檔案會合併成大檔案，不同bucket會落到對應的stripe；
2. Merge會跨層把符合merge的檔案做多路歸併，檔案內嚴格有序，但是檔案間大致有序，層數越高，檔案越大，檔案間的overlap越小。
每個檔案我們使用了行列混存的格式，右側為行列混存的具體的儲存格式，我們是在ORC的基礎上做了大量最佳化。
ORC檔案：一個ORC檔案中可以包含多個stripe，每一個stripe包含多個row group，每個row group包含固定條記錄，這些記錄按照列進行獨立儲存。
Postscript：包括檔案的描述資訊PostScript、檔案meta資訊（包括整個檔案的統計資訊，資料字典等）、所有stripe的資訊和檔案schema資訊。
stripe：stripe是對行的切分，組行形成一個stripe，每次讀取檔案是以行組為單位的，儲存了每一列的索引和資料。它由index data，row data和stripe footer組成。
File footer：儲存stripe的位置、每一個列的在該stripe的統計資訊以及所有的stream型別和位置。
Index data：儲存了row group級別的統計資訊。
Data stream：一個stream表示檔案中一段有效的資料，包括索引和資料兩類。
索引stream儲存每一個row group的位置和統計資訊，資料stream包括多種型別的資料，具體需要哪幾種是由該列型別和編碼方式決定，下面以integer和string 2種類型舉例說明：
對於一個Integer欄位，會同時使用一個位元流和整形流。位元流用於標識某個值是否為null，整形流用於儲存該整形欄位非空記錄的整數值。 
String型別欄位，ORC writer在開始時會檢查該欄位值中不同的內容數佔非空記錄總數的百分比不超過0.8的話，就使用字典編碼，欄位值會儲存在一個位元流，一個位元組流及兩個整形流中。位元流也是用於標識null值的，位元組流用於儲存字典值，一個整形流用於儲存字典中每個詞條的長度，另一個整形流用於記錄欄位值。如果不能用字典編碼，ORC writer會知道這個欄位的重複值太少，用字典編碼效率不高，ORC writer會使用一個位元組流儲存String欄位的值，然後用一個整形流來儲存每個欄位的位元組長度。 
在ORC檔案中儲存了三個層級的統計資訊，分別為檔案級別、stripe級別和row group級別。而提升儲存效能的核心是減少IO，我們基於ORC的統計資訊和索引實現各種下推，幫助我們實現IO裁剪。例如Projection下推，我們只會掃描需要物化的列。Agg下推中，我們會直接把需要的min，max，sum，unique從統計資訊或者索引中讀取即可返回，避免了對data stream的解壓。對於predicate，我們還支援把filter下推，透過統計資訊直接做過濾，直接跳過不符合的條件的stripe，我們支援各種運算子，以及in/not in，以及表示式的等價轉換。
此外我們針對儲存格式對效能還做了下面的最佳化：
1. 零複製：為了把ORC的資料型別轉換成PG資料型別，我們對於定長型別的做值複製，變長型別直接轉換成PG的datum做指標引用。
2. Batch Scan：面向column採用batch scan，替代逐行訪問而是先掃完一列，再掃下一列，這樣對CPU cache更加友好。
3. 支援Seek read：方便過濾命中情況下的跳轉。

6  本地快取

DADI幫助我們實現2個能力，一個是高效的快取管理，另外一個是統一儲存訪問。在瞭解DADI之前，我們可以首先看一下，DADI與開源解決方案從RT與throughput 2個維度做了對比測試：
維度
RT
Throughput
產品
DADI
Alluxio-Fuse
DADI
Alluxio-Fuse
命中記憶體
6~7 us
408 us
單執行緒： 4.0 GB/s
四執行緒： 16.2 GB/s
2.5 GB/s
命中磁碟
127 us
435 us
四執行緒： 541 MB/s
0.63 GB/s
從中看到，DADI相比開源解決方案alluxio在記憶體命中的場景RT上有數量級的提升，在throughput上也有明顯的優勢。在命中磁碟的場景，也有明顯的效能優勢，在部分分析場景下，我們會頻繁但是少量讀取檔案統計資訊，這些統計資訊我們會快取在本地，這個優勢帶來整體效能的較大提升。
DADI在快取命中場景下的效能優勢，可以參考下面的架構：
DADI SDK：透過標準讀寫介面訪問儲存，透過快取是否命中，選擇短路讀（short circuit read），還是IPC程序通訊訪問Local DADI Service，或者訪問遠端的DADI Service，對應分散式快取服務，作為lib庫嵌入ADB PG的讀寫程序；
Cache Instance：管理本地快取，快取檔案抽象成虛擬塊裝置來訪問，資料在memory和本次磁碟的冷熱以block為單位管理。
這裡的核心設計在於：
1.  短路讀，直接讀共享記憶體，避免透過IPC讀；
2.  快取是否命中的資料結構，也是在共享記憶體裡面。透過reference count，結合robust mutex來保證共享記憶體資料的多執行緒安全；
3. 磁碟讀，100us，+ 27us約等於磁碟讀本身rt，IPC走shm通訊，沒有使用本地socket通訊。
4. 極低的資源使用。
記憶體：DADI Service使用的記憶體在100~200M，原因在於基於共享記憶體的IPC實現，hash表等資料結構，避免多程序架構下記憶體膨脹， 精簡的編碼方式，1個記憶體頁16k 對應 4byte的管理結構；
CPU：Local DADI Service在磁碟打滿的時候單核CPU使用20%左右。CPU的使用在SDK這邊，SDK與Local DADI Service通訊很少。
此外為了更好的發揮DADI在命中記憶體的優勢，我們結合行列混存做了以下最佳化：
1. 快取優先順序
支援統計資訊高優先順序，常駐記憶體，索引資訊常駐本地磁碟。支援維度表資料高優先順序快取在本地。
2. 細粒度快取策略
為了避免大表冷資料訪問，導致本地熱資料被全部替換，大表使用專有快取區。
3. 檔案非同步預取
根據查詢情況，把解析的資料檔案，預先讀取到本地，這個過程不影響當前檔案的讀寫，並且是非同步的。

7  向量化執行

ADB PG雲原生版本也同樣支援向量化執行引擎，核心還是透過攢批的方式提高資料在CPU cache的命中率，透過codegen減少函式呼叫次數，減少複雜計算指令跳轉，透過SIMD指令加速計算，透過記憶體池管理，降低運算元間的記憶體複製，更多資訊可以參考【3】。

8  有序感知

資料的有序主要用在2個方面，基於有序的IO裁剪，另外一個是儘量減少計算過程中的排序，IO裁剪在行列混存以及有較多的討論，這裡主要討論第二點，這裡我們做的主要工作有：
1.  消除多餘sorting操作。如果data本身有序，且滿足排序要求，則不需要加sort操作。
2.  最小化需要排序的列。例如希望對{c1,c2,..cn}排序，如果有謂詞c1=5，則order簡化成{c2,..cn}，避免排序多一個欄位。
3.  order下推。在初始化階段，降意向排序操作儘量下推。
我們透過下列方法來生成sort scan的運算元，查詢SQL解析生成AST後，會根據一系列啟發式規則做變換生成物理執行計劃：
1.  首先針對不同運算元的有序性需求，例如（join/group by/distinct/order by）,建立運算元的interesting order（即這個運算元期望的有序輸入）。
2. 其次在sort scan的過程中所生成的interesting order，會盡可能下推到下層運算元中(sort-ahead)，以儘早滿足order屬性要求。
3. 如果一個運算元具有多個interesting order，會嘗試將他們合併，這樣一個排序就可以滿足多個order屬性的需求。
此外就是sort scan運算元的實現，儲存層面只能保證檔案內嚴格有序，檔案的大致有序，我們透過多路歸併的演算法來實現。
這裡的問題在於sort scan的多路歸併需要一條條讀取資料，與向量化的batch scan與檔案的批次讀衝突，我們透過CBO來選主最優的執行計劃。

9  細粒度並行

ADB PG是MPP架構，能夠充分發揮節點間平行計算能力，雲原生版本由於對資料按bucket做了切分，能幫助我們在節點內實現更細粒度的並行，我們以join為例說明：
左邊是沒有節點內並行的join的執行計劃，會起2個程序，一個做hash join的build，另外一個做probe，右邊是節點內做了並行，我們會根據segment所分配的bucket來做並行，例如上圖每個bucket的資料都可以並行的去做計算，由於資料是按照bucket做的劃分，join key是分佈健的時候，節點內並行也能完美命中local join的最佳化。

四  效能結果

1  擴縮容效能

計算資源擴容（節點數）
2->4
4->8
8->16
16->128
用時
<1min
<1min
<1min
<7min

2  讀寫效能

為了測試效能，我們使用了4*4C規格的例項，ADB PG的新版雲原生與儲存彈性版本做了效能對比測試。

寫效能測試

測試表選用scale factor = 500的TPC-H lineitem表。透過同時執行不同併發數的copy命令，測得命令執行時間，用總資料量除以命令執行時間，得到吞吐量。
ADB PG 彈性儲存
ADB PG新版雲原生
併發數
1
4
8
1
4
8
COPY
48MB/s
77MB/s
99MB/s
45MB/s
156MB/s
141MB/s
  1. 在單併發下新版本與儲存彈性版本的效能差不多，主要在於資源都沒有滿；
  2. 在4併發下新版本的吞吐是儲存彈性的2倍，原因在於使用lineitem表都定義了sort key，新版本在寫入資料無需寫WAL日誌，另外攢批加上流水線並行相比彈性儲存版本先寫入，再merge，merge的時候也需要寫額外的WAL有一定優勢；
  3. 在8併發下新版本與4併發差不多，主要由於4C 4併發已經把CPU用滿，所以再提升併發也沒有提升。

讀效能測試

為了全面的測試讀效能，我們針對3種場景做了測試：
全記憶體：使用的是TPCH sf為10的資料集，會生成10G的測試資料集。
全本地磁碟快取：使用的是TPCH sf為500的資料集，會生成500GB的測試資料集。
一半快取，一半OSS：使用的是TPCH sf為2000的資料集，會生成2000GB的測試資料集。（本地磁碟快取960GB）
測試結果如下（縱軸為RT單位ms）
全記憶體
全本地磁碟快取
一半本地快取，一半OSS
從上述測試結果來看：
  1. 雲原生版本對比老的彈性儲存版本均有1倍多的效能提升，原因在於細粒度並行帶來的加速效果；
  2. 對於TPCH這種計算密集型的作業，即使資料一半快取，一半OSS效能也不錯，sf 2000資料量是sf 500的4倍，rt增加到原來的2.8倍，主要原因在於4*4C規格的例項沒有到OSS的頻寬瓶頸，另外由於本身讀取的預取等最佳化。

五  總結

AnalyticDB PostgreSQL新版雲原生是充分的將物理資源進行了池化，將儲存和計算能力單元化進行分配，實現靈活的部署。這個特性為使用者提供極致的價效比，做到了算力的最優分配，同時降低使用者使用的門檻，讓使用者專注於業務而無需將大量精力放在算力和儲存的規劃上，實現體驗升級。 
  1. 透過儲存計算分離，使用者可以根據業務負載模型，輕鬆適配計算密集型或儲存密集型，儲存並按使用計費，避免儲存計算一體僵化而造成的資源浪費；
  2. 動態的適配業務負載波峰和波谷，雲原生MPP架構計算側使用了shared-nothing架構，支援秒級的彈性伸縮能力，而共享儲存使得底層儲存獨立不受計算的影響。這降低了使用者早期的規格選型的門檻，預留了後期根據業務的動態調整靈活性；
  3. 在儲存計算分離基礎上，提供了資料共享能力，這真正打破了物理機的邊界，讓雲上的資料真正的流動了起來。例如資料的跨例項即時共享，可支援一存多讀的使用模式，打破了傳統數倉例項之間資料訪問需要先匯入，再訪問的孤島，簡化操作，提高效率，降低成本。

六  後續計劃

在上述儲存分離的架構上，我們後續主要有3個大的方向：
1. 能力補齊，這塊主要是補齊當前版本的一些限制，例如Primary key，索引，物化檢視，補齊寫入的能力；
2. 效能持續最佳化，主要最佳化快取沒有命中場景；
3. 雲原生架構持續升級，這塊主要是在當前儲存計算分離架構下，進一步提升使用者體驗；
在雲原生升級我們主要有2個重點方向：
1. 存算分離往Serverless再進一步，擴縮容無感。會進一步把元資料和狀態也從計算節點剝離到服務層，把segment做成無狀態的，這樣的好處在於擴縮容能做到使用者無感，另外一個好處在於segment無狀態有利於提高系統高可用能力，當前我們還是透過主備模式提供高可用，當有節點故障的時候，主備切換快取失效效能會急劇下降，segment無狀態後我們會直接將它提出叢集，透過“縮容”的方式繼續提高服務。
2.  應用跨例項的資料共享。此外對於分析型業務，資料規模大，以TB起步，傳統數倉採用煙囪式架構，資料冗餘，資料同步代價高的問題，我們希望提供跨例項的資料共享能力，重構數倉架構。

雲原生版本將於2022年2月正式商業化發布，想要更多資訊可以訪問產品網站https://www.aliyun.com/product/gpdb

七  引用資料

【1】  http://click.aliyun.com/m/1000307639/
【2】  https://developer.aliyun.com/article/838806?groupCode=analyticdb4postgresql&share_source=wechat_qr
【3】 https://developer.aliyun.com/article/783182

關係型資料庫課程

點選閱讀原文檢視詳情！
關鍵詞
效能
使用者
時候
資訊
業務


相關文章