AnalyticDB：高效能版執行個體

架構介紹

AnalyticDB PostgreSQL版高效能版執行個體的Master和Segment節點均採用了單節點部署，架構圖如下。

相比較下圖中的高可用版，高效能版取消了Master Node的副本Standby Node，以及Compute Node中Primary的副本Mirror。

取消上述副本後高效能版具有如下優勢：

• 取消了Master Node的副本Standby Node，節省了Standby Node佔用的儲存空間。

• 取消了Compute Node中的副本Mirror，節省了一半的儲存空間。

• 取消了Compute Node中Primary與Mirror的資料同步過程，提升了寫入情境下的I/O效能。

費用說明

價格資訊詳情，請參見雲原生資料倉儲PostgreSQL版詳細價格資訊。

高效能版優勢

成本優勢

高效能版成本優勢主要體現在如下兩個方面：

• 相同規格下，節省了一個副本的儲存空間，降低了50%的儲存成本。

• 計算節點在擁有相同計算能力的情況下價格下降。

  配置	儲存價格（美元/月）			計算節點價格（美元/月）			總價格（美元/月）
  	高效能版	高可用版	價格下降	高效能版	高可用版	價格下降	高效能版	高可用版	價格下降
  入門配置	22.4	100	77.6%	175.55	352.05	50.13%	197.95	452.05	56.21%
  常用配置	89.6	200	55.2%	668.65	700.28	4.52%	758.25	900.28	15.78%

  • 入門配置：入門配置即最低配置。高效能版為2核、50 GB儲存容量、2個計算節點，高可用版為2核、50 GB儲存容量、4個計算節點。相比高可用版，高效能版的入門價格降低了59%。

  • 常用配置：高效能版和高可用版均為4核、100 GB儲存容量、4個計算節點。相比高可用版，相同配置下，價格降低了22%。

效能優勢

高效能版相比較高可用版，I/O效能有比較明顯的提升。2核規格的執行個體，I/O效能最高可達高可用版相同規格執行個體的2.5倍。在大量資料寫入的情境中，高效能版省略了向副本同步資料和流複製的過程，使得該情境中有額外近1倍的I/O提升。

對計算節點規格為2核、儲存容量為400 GB、4個計算節點的高效能版和高可用版執行個體進行本地複製測試和TPC-H測試：

• 本地複製測試

  對約90 GB的行存表進行本地複製測試，樣本SQL如下：

  CREATE TABLE lineitem2 AS (SELECT * FROM lineitem);

  高效能版和高可用版執行耗時如下：

  • 高效能版：249秒（s）

  • 高可用版：1307秒（s）

  通過如上測試可以看出，I/O密集型情境（例如本地表CTAS、INSERT INTO SELECT）效能提升明顯，上述樣本中有接近5倍效能提升。

• TPC-H測試

  說明

  本文的TPC-H的實現基於TPC-H的基準測試，並不能與發行的TPC-H基準測試結果相比較，本文中的測試並不符合TPC-H基準測試的所有要求。

  對資料集總大小為100 GB的TPC-H資料集進行基準測試，TPC-H的22個SQL結果如下圖所示。

  

  由於I/O效能的提升，相比較高可用版，高效能版的TPC-H叢集測試用時降低了40%左右。

可用性

資料可靠性

AnalyticDB PostgreSQL版使用阿里雲ESSD雲端硬碟作為儲存介質，可保證在單副本模式下，依然可以提供超高的資料可靠性。即使計算節點發生故障，也可以保證執行個體無資料丟失。

高可用

AnalyticDB PostgreSQL版高效能版由於減少了一個副本，在高可用方面出現了一些下降，在物理機故障等極端情況下，叢集恢複的時間會變長（8小時以內）。高效能版通過ESSD多副本技術，保留了完整的資料可靠性，並且阿里雲團隊通過更改高效能版CheckPoint機制的方式，減少了恢複的時間。

以下內容為AnalyticDB PostgreSQL版執行個體常見故障情境中高效能版和高可用版的對比：

• 恢複（Recovery）模式

  根據以往AnalyticDB PostgreSQL版運行情況，故障最大的情境為復原模式，故障機率遠大於另外兩種情境（計算節點故障和計算節點宿主機故障）。復原模式中高效能版恢複速度遠高於高可用版。

  SQL崩潰時，主要會出現Coredump或Out of Memory等情況，使AnalyticDB PostgreSQL版進入復原模式。復原模式中，系統會對殘留的鎖和記憶體執行一些清理操作，並通過回放WAL檔案來保證資料的完整性。恢複期間，執行個體會暫時無法服務，完成恢複後，執行個體會恢複正常。高可用版執行個體恢複一般耗時5~10分鐘（min），而高效能版執行個體通過更改CheckPoint機制等方式，恢複的時間可縮短至10秒（s）左右。

  WAL和CheckPoint介紹如下：

  • WAL（Write Ahead Log）

    AnalyticDB PostgreSQL版中，事務每次修改資料的操作都需要先記錄到WAL檔案中，即每次事務提交時，會保證WAL日誌已落盤。當資料庫需要恢複資料時，可以通過回放WAL日誌的方法來恢複已經提交但尚未寫入磁碟的資料更改。

  • CheckPoint

    CheckPoint相當於在WAL日誌中寫入的一個復原點標記，並將該標記之前的修改全部落盤。資料庫恢複資料時，只需要回放到最近一次復原點即可。AnalyticDB PostgreSQL版會定期執行CheckPoint操作，當WAL日誌過長時，也會自動執行CheckPoint進行落盤。

• 計算節點故障

  高效能版執行個體減少了一個副本，必然帶來可用性的下降。高可用版執行個體的某個計算節點故障後，會立刻無縫切換至對應副本，執行個體可以正常運行，故障的計算節點會切換為副本，在後台自動重啟；而高效能版執行個體單個節點故障會導致整個執行個體不可用，必須重啟整個執行個體恢複。

• 計算節點宿主機故障

  計算節點宿主機故障屬於比較少見的極端情況，會觸發宿主機的自動遷移。對於高可用版執行個體，仍然可以觸發副本自動切換，執行個體可以正常運行，同時後台自動完成宿主機的遷移；高效能版執行個體則需要等待宿主機遷移成功後，再重啟恢複執行個體，耗時一般在15分鐘（min）左右。

相關文檔

• 【通知】AnalyticDB PostgreSQL版發布高效能版執行個體

• 建立執行個體

常見問題

Q：如何將AnalyticDB for PostgreSQL基礎版執行個體升級為高可用版？

A：基礎版不能直接升級到高可用版，如果需要升級到高可用版，建議先備份好資料，然後購買高可用版執行個體並進行資料移轉。關於如何進行資料移轉，請參見AnalyticDB PostgreSQL版間的資料移轉。