全部產品
Search
文件中心

AnalyticDB:高效能版執行個體

更新時間:Jun 19, 2024

AnalyticDB PostgreSQL版高效能版採用單副本儲存模式,大幅降低了資料存放區成本及建倉門檻,並提供了較高的I/O能力。

說明

AnalyticDB PostgreSQL版高效能版執行個體,適用於大部分業務分析情境。對於企業核心業務,依然推薦採用高可用版本。

架構介紹

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

圖 1. 高效能版架構圖基礎版架構圖

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

圖 2. 高可用版架構圖高可用版架構圖

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

  • 取消了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結果如下圖所示。

    基礎版TPC-H測試

    由於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)左右。

相關文檔

常見問題

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

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