Amazon Redshift Advisor 建議 - Amazon Redshift
壓縮以 COPY 載入的 Amazon S3 檔案物件隔離多個作用中資料庫重新配置工作負載管理 (WLM) 記憶體在 COPY 期間跳過壓縮分析分割由 COPY 載入的 Amazon S3 物件更新資料表統計資訊啟用短期查詢加速更改資料表上的分佈索引鍵變更資料表上的排序索引鍵修改資料欄上的壓縮編碼資料類型建議

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon Redshift Advisor 建議

Amazon Redshift Advisor 提供有關如何最佳化 Amazon Redshift 叢集以提高效能並節省營運成本的建議。如前所述，您可以在主控台找到各項建議的解釋。您可以在以下章節中找到這些建議的進一步詳細資訊。

壓縮以 COPY 載入的 Amazon S3 檔案物件

COPY 命令利用 Amazon Redshift 中的大規模平行處理 (MPP) 架構，以同時讀取與載入資料。它可從 Amazon S3、DynamoDB 資料表讀取檔案，以及從一或多個遠端主機讀取文字輸出。

載入大量資料時，強烈建議您使用 COPY 命令從 S3 載入已壓縮的資料檔案。壓縮大型資料集可節省上傳檔案至 Amazon S3 的時間。COPY 亦可在讀取檔案時解壓縮檔案，以加速載入程序。

分析

載入大型未壓縮資料集的長時間執行 COPY 命令，通常有機會大幅提升效能。Advisor 分析可識別載入大型未壓縮資料集的 COPY 命令。在此情況下，Advisor 會產生在 Amazon S3 中的來源檔案實作壓縮的建議。

建議

確定載入大量資料或長時間執行的每個 COPY 皆從 Amazon S3 擷取已壓縮的資料物件。您可以用超級使用者的身分執行以下 SQL 命令，識別從 Amazon S3 載入大型未壓縮資料集的 COPY。


SELECT
    wq.userid, query, exec_start_time AS starttime, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY 1, 2, 3, 7
HAVING SUM(transfer_size) = SUM(data_size) 
AND SUM(transfer_size)/(1024*1024) >= 5
ORDER BY 6 DESC, 5 DESC;

如果在您載入資料之後，暫存資料仍留存在 Amazon S3 (資料湖經常出現此情況)，以壓縮形式儲存此資料可降低您的儲存空間成本。

實作提示

  • 壓縮之後的理想物件大小介於 1–128 MB 之間。

  • 您可以用 gzip、lzop 或 bzip2 格式壓縮檔案。

隔離多個作用中資料庫

根據最佳實務，建議您隔離 Amazon Redshift 中的各個資料庫。查詢執行於特定資料庫，而且無法存取叢集上其他資料庫的資料。但是，您在叢集上所有資料庫執行的查詢，將共用相同的底層叢集儲存空間與運算資源。當單一叢集包含多個使用中資料庫時，其工作負載通常是不相關的。

分析

Advisor 分析會檢閱叢集上的所有資料庫，以找出同時執行的使用中工作負載。如果有同時執行的使用中工作負載，Advisor 分析會產生建議，建議您考慮將資料庫遷移至個別的 Amazon Redshift 叢集。

建議

考慮將經常被查詢的資料庫移至個別的專屬叢集。使用個別的叢集可減少資源爭奪並提升查詢效能。這是因為它能讓您設定各個叢集的儲存空間大小、成本，以及各個工作負載所需的效能。同時，不相關的工作負載通常會受益於不同的工作負載管理組態。

若要找出最常用的資料庫，請以超級使用者身分執行此 SQL 命令。


SELECT database,
  COUNT(*) as num_queries,
  AVG(DATEDIFF(sec,starttime,endtime)) avg_duration,
  MIN(starttime) as oldest_ts,
  MAX(endtime) as latest_ts
FROM stl_query
WHERE userid > 1
GROUP BY database;

實作提示

  • 因為使用者必須特別連接至各個資料庫，而查詢只能存取單一資料庫，因此將資料庫移至個別叢集對使用者的影響很小。

  • 移動資料庫的選項之一是執行以下步驟：

    1. 暫時將目前叢集的快照還原至相同大小的叢集。

    2. 從新的叢集刪除所有資料庫，要移動的目標資料庫除外。

    3. 調整叢集大小以符合適當的節點類型，並計算資料庫的工作負載。

重新配置工作負載管理 (WLM) 記憶體

Amazon Redshift 將使用者查詢路由到 實作手動 WLM 以進行處理。工作負載管理 (WLM) 定義如何將這些查詢路由到佇列。Amazon Redshift 會為每個佇列都配置叢集的一部分可用記憶體。佇列的記憶體再分配給佇列的查詢槽。

當佇列設定的插槽多於工作負載的需要時，配置到這些未使用插槽的記憶體將無法充分利用。減少設定的插槽以符合尖峰工作負載需求，可將未使用的記憶體重新分配給使用中的插槽，並藉此提升查詢效能。

分析

Advisor 分析將檢閱工作負載並行需求，以識別具有未使用插槽的查詢佇列。Advisor 發現以下情形時將會產生建議，建議您降低佇列中的插槽數量：

  • 在整個分析過程中有完全未使用之插槽的佇列。

  • 擁有四個以上插槽，而且在整個分析過程中至少有兩個未使用插槽的佇列。

建議

減少設定的插槽以符合尖峰工作負載需求，可將未使用的記憶體重新分配給使用中的插槽。針對其插槽不曾完全充分利用的佇列，考慮減少其設定的插槽數量。若要找出這些佇列，您可以用超級使用者的身分執行以下 SQL 命令，比較各個佇列的每小時尖峰插槽需求。


WITH
 generate_dt_series AS (select sysdate - (n * interval '5 second') as dt from (select row_number() over () as n from stl_scan limit 17280)),
 apex AS (
     SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots
     FROM
         (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count
         FROM stl_wlm_query wq
         JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 5)
         JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt)
         WHERE wq.userid > 1 AND wq.service_class > 5) iq
     GROUP BY iq.dt, iq.service_class, iq.num_query_tasks),
     maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots
                     from apex group by apex.service_class, apex.dt, date_part(h,apex.dt))
SELECT apex.service_class - 5 AS queue, apex.service_class, apex.num_query_tasks AS max_wlm_concurrency, maxes.d AS day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots
FROM apex
JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots)
GROUP BY  apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h
ORDER BY apex.service_class, maxes.d, maxes.dt_h;

max_service_class_slots 欄位表示該小時查詢佇列中 WLM 查詢插槽的最大數量。如有未利用的佇列，可修改參數群組以實作插槽減量最佳化，如 Amazon Redshift 管理指南所述。

實作提示

  • 如果您的工作負載量變化很大，請確定分析有擷取到尖峰使用期間。如果變化不大，請重複執行先前的 SQL 以監控尖峰並行需求。

  • 如需有關解譯上述 SQL 程式碼之查詢結果的詳細資訊，請參閱中的 wlm_apex_hourly.sql 指令碼。 GitHub

在 COPY 期間跳過壓縮分析

當您以 COPY 命令宣告的壓縮編碼，將資料載入空的資料表時，Amazon Redshift 將會套用儲存空間壓縮。此最佳化可確保叢集中的資料有效地儲存，即使是由最終使用者載入。需要套用壓縮的分析可能需要很長的時間。

分析

Advisor 分析會檢查因自動壓縮分析而延遲的 COPY 操作。此分析會在資料載入時取樣資料以判斷壓縮編碼。此取樣類似 ANALYZE COMPRESSION 命令所執行的取樣。

當您在結構化程序中載入資料時，例如隔夜擷取、轉換、載入 (ETL) 批次，您可以預先定義壓縮。您也可以最佳化您的資料表定義，以永久跳過此階段，而不產生任何負面影響。

建議

為藉由跳過壓縮分析階段以提升 COPY 反應速度，請實作以下兩個選項之一：

  • 當您建立使用 COPY 命令載入的資料表時，請使用欄位 ENCODE 參數。

  • 在 COPY 命令中套用 COMPUPDATE OFF 參數，以一併關閉壓縮。

最佳解決方案通常是在資料表建立期間使用欄位編碼，因為此方法也同時保有將壓縮資料儲存於磁碟的好處。您可以使用 ANALYZE COMPRESSION 命令以建議壓縮編碼，但您必須重建資料表以套用這些編碼。若要自動執行此程序，您可以使用 AWSColumnEncodingUtility，在上找到 GitHub。

若要識別最近觸發自動壓縮分析的 COPY 操作，請執行以下 SQL 命令。


  WITH xids AS (
    SELECT xid FROM stl_query WHERE userid>1 AND aborted=0 
    AND querytxt = 'analyze compression phase 1' GROUP BY xid
    INTERSECT SELECT xid FROM stl_commit_stats WHERE node=-1)
SELECT a.userid, a.query, a.xid, a.starttime, b.complyze_sec, 
    a.copy_sec, a.copy_sql
FROM (SELECT q.userid, q.query, q.xid, date_trunc('s',q.starttime) 
    starttime, substring(querytxt,1,100) as copy_sql, 
    ROUND(datediff(ms,starttime,endtime)::numeric / 1000.0, 2) copy_sec
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt ilike 'copy %from%' OR querytxt ilike '% copy %from%') 
    AND querytxt not like 'COPY ANALYZE %') a
LEFT JOIN (SELECT xid, 
    ROUND(sum(datediff(ms,starttime,endtime))::numeric / 1000.0,2) complyze_sec 
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt like 'COPY ANALYZE %' 
    OR querytxt like 'analyze compression phase %') 
    GROUP BY xid ) b ON a.xid = b.xid
WHERE b.complyze_sec IS NOT NULL ORDER BY a.copy_sql, a.starttime;

實作提示

  • 請確定在您 ETL 程序中建立的所有大容量資料表 (例如，臨時資料表與暫存資料表) 宣告所有欄位的壓縮編碼 (第一個排序索引鍵除外)。

  • 估算前述 SQL 命令識別之各個 COPY 命令所載入資料表的預期生命週期大小。如果您有信心資料表將維持極小，請以 COMPUPDATE OFF 參數一併關閉壓縮。否則，請在以 COPY 命令載入資料之前，以明確的壓縮建立資料表。

分割由 COPY 載入的 Amazon S3 物件

COPY 命令利用 Amazon Redshift 中的大規模平行處理 (MPP) 架構，從 Amazon S3 的檔案讀取與載入資料。COPY 命令從多個檔案平行載入資料，並將工作負載分散至您叢集中的各個節點。若要達到最佳傳輸量，強烈建議您將資料分割為多個檔案來善加利用平行處理。

分析

Advisor 分析可識別載入包含於暫存在 Amazon S3 少量檔案中的大型資料集的 COPY 命令。從少量檔案載入大型資料集的長時間執行 COPY 命令，通常有機會大幅提升效能。當 Advisor 發現這些 COPY 命令花費大量時間，將會建立建議，藉由將資料分割至 Amazon S3 中的其他檔案以增加平行處理。

建議

在此情況下，建議採取以下依照優先順序排序的動作：

  1. 最佳化載入檔案數量少於叢集節點數量的 COPY 命令。

  2. 最佳化載入檔案數量少於叢集分割數量的 COPY 命令。

  3. 最佳化檔案數量不是叢集分割數量倍數的 COPY 命令。

某些 COPY 命令會載入大量資料或長時間執行。對於這些命令，建議您從 Amazon S3 載入資料物件的數量等於叢集中分割數量的倍數。若要識別每個 COPY 命令已載入多少個 S3 物件，請以超級使用者身分執行以下 SQL 程式碼。


SELECT
    query, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY query, querytxt
HAVING (SUM(transfer_size)/(1024*1024))/COUNT(*) >= 2
ORDER BY CASE
WHEN COUNT(*) < (SELECT max(node)+1 FROM stv_slices) THEN 1
WHEN COUNT(*) < (SELECT COUNT(*) FROM stv_slices WHERE node=0) THEN 2
ELSE 2+((COUNT(*) % (SELECT COUNT(*) FROM stv_slices))/(SELECT COUNT(*)::DECIMAL FROM stv_slices))
END, (SUM(transfer_size)/(1024.0*1024.0))/COUNT(*) DESC;

實作提示

  • 節點中的分割數目取決於叢集的節點大小。如需各個節點類型有多少分割的相關資訊，請參閱《Amazon Redshift 管理指南》中的＜Amazon Redshift 中的叢集和節點＞。

  • 您可以透過為集合指定通用字首或字首索引鍵，或在資訊清單檔案中明確列出檔案來載入多個檔案。如需載入檔案的相關資訊，請參閱 從已壓縮和未壓縮的檔案載入資料。

  • Amazon Redshift 在分割工作負載時，不會考量檔案大小。分割您的載入資料，使檔案皆有相同的大小，在壓縮之後介於 1 MB 至 1 GB。

更新資料表統計資訊

Amazon Redshift 使用成本型查詢最佳化工具來為查詢選擇最佳執行計畫。成本估算是根據使用 ANALYZE 命令產生的資料表統計資訊。當統計資訊已過時或遺失時，資料庫可能會選擇效率較低的查詢執行計畫，特別是複雜的查詢。維護最新統計資訊有助於複雜的查詢以可能的最短時間執行。

分析

「建議程式」分析會追蹤統計資料為 out-of-date 或遺失的表格。它會檢閱與複雜查詢相關聯的資料表存取中繼資料。如果經常以複雜模式存取的資料表遺失統計資訊，Advisor 會建立重大建議以執行 ANALYZE。如果經常使用複雜模式存取的表格具有 out-of-date 統計資料，「建議程式」會建立建議來執行 ANALYZE。

建議

無論何時，當資料表內容有大幅變更時，請以 ANALYZE 更新統計資訊。當有大量新資料列以 COPY 或 INSERT 命令載入至現有資料表時，我們建議執行 ANALYZE。當有大量資料列以 UPDATE 或 DELETE 命令進行修改時，我們也建議執行 ANALYZE。若要識別遺漏的資料表或 out-of-date 統計資料，請以超級使用者身分執行下列 SQL 命令。其結果將從最大到最小的資料表進行排序。

若要識別遺漏的資料表或 out-of-date 統計資料，請以超級使用者身分執行下列 SQL 命令。其結果將從最大到最小的資料表進行排序。


SELECT
   ti.schema||'.'||ti."table" tablename,
   ti.size table_size_mb,
   ti.stats_off statistics_accuracy
 FROM svv_table_info ti
 WHERE ti.stats_off > 5.00
 ORDER BY ti.size DESC;

實作提示

預設 ANALYZE 閾值為 10%。此預設值表示特定資料表自上一次 ANALYZE 後，如果變更的列數少於 10%，則 ANALYZE 命令會略過此資料表。因此，您可以選擇在每個 ETL 程序結尾時發出 ANALYZE 命令。採取此方法意味著通常會跳過 ANALYZE，但也能確保 ANALYZE 會在需要時執行。

ANALYZE 統計資訊對於聯結中使用的欄位 (例如，JOIN tbl_a ON col_b) 或做為述詞的欄位 (例如，WHERE col_b = 'xyz') 最有影響。根據預設，ANALYZE 會收集指定資料表中所有欄位的統計資訊。如有需要，您可以針對 ANALYZE 最有影響的欄位來執行 ANALYZE，以減少需要執行 ANALYZE 的時間。您可執行下列 SQL 命令來識別做為述詞使用的欄位。您也可以指定 ANALYZE PREDICATE COLUMNS，讓 Amazon Redshift 選擇要分析哪些欄。

WITH predicate_column_info as (
SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num,  a.attname as col_name,
        CASE
            WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') 
            WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||')
            WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||')
            WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||')
            ELSE NULL::varchar
        END AS pred_ts
   FROM pg_statistic s
   JOIN pg_class c ON c.oid = s.starelid
   JOIN pg_namespace ns ON c.relnamespace = ns.oid
   JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum)
SELECT schema_name, table_name, col_num, col_name,
       pred_ts NOT LIKE '2000-01-01%' AS is_predicate,
       CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use,
       CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze
FROM predicate_column_info;

如需詳細資訊，請參閱 分析資料表。

啟用短期查詢加速

短期查詢加速 (SQA) 可排定讓短期執行的查詢優先於長期執行的查詢。SQA 會在專用空間中執行短期查詢，所以 SQA 查詢不會被迫在佇列中排在長期查詢後面等待。SQA 只優先處理短期執行且位於使用者定義佇列中的查詢。SQA 可讓短期執行的查詢更快開始執行，使用者會更快看到結果。

如果開啟 SQA，您可以減少或去除短期查詢執行專用的工作負載管理 (WLM) 佇列。此外，長期執行的查詢不需要與短期查詢爭奪佇列中的槽，因此，您可以將 WLM 佇列設定為使用較少的查詢槽。使用較低的並行性時，就大部分工作負載而言，查詢傳輸量會增加，且整體系統效能會改善。如需詳細資訊，請參閱 使用短期查詢加速。

分析

Advisor 會檢查工作負載模式，並報告 SQA 可減少延遲的最近查詢數目，以及符合 SQA 資格的查詢的每日佇列時間。

建議

修改 WLM 組態以開啟 SQA。Amazon Redshift 採用機器學習演算法來分析每一個合格查詢。隨著 SQA 從查詢模式中學習，預測會越準確。如需詳細資訊，請參閱設定工作負載管理。

開啟 SQA 時，根據預設，WLM 會將短期查詢的最長執行期設為動態。建議維持 SQA 最長執行時間的動態設定。

實作提示

若要檢查是否已開啟 SQA，請執行下列查詢。如果查詢傳回一列，表示 SQA 已開啟。

select * from stv_wlm_service_class_config 
where service_class = 14;

如需詳細資訊，請參閱 監控 SQA。

更改資料表上的分佈索引鍵

Amazon Redshift 會根據資料表分佈樣式將資料表列分佈至整個叢集。含有 KEY 分佈的資料表需要將一個資料欄做為分佈索引鍵 (DISTKEY)，而系統會根據 DISTKEY 資料欄值來指派資料表列給叢集的節點分割。

適當的 DISTKEY 會在每個節點分割上放置差不多數量的資料列，且聯結條件經常會參考該資料欄。當系統在 DISTKEY 資料欄上聯結資料表時，就會產生經過最佳化的聯結，以加速查詢效能。

分析

Advisor 會分析叢集的工作負載以找出最適合資料表的分佈索引鍵，其可從 KEY 分佈樣式獲得諸多優勢。

建議

Advisor 所提供的 ALTER TABLE 陳述式可根據分析結果來更改資料表的 DISTSTYLE 和 DISTKEY。請確保在建議群組內實作所有 SQL 陳述式，以發揮顯著的效能優勢。

使用 ALTER TABLE 重新分佈大型資料表會耗用叢集資源，且會不定時鎖定暫時資料表。因此，請在其他叢集工作負載較輕時實作每個建議群組。如需最佳化表格分佈屬性的詳細資訊，請參閱 Amazon Redshift 工程的進階資料表設計操作手冊：分佈樣式與分佈索引鍵。

如需 ALTER DISTSYLE 和 DISTKEY 的相關資訊，請參閱 ALTER TABLE。

注意

如果沒有看到建議，並不一定表示目前的發佈樣式是最合適的。如果沒有足夠的資料或重新分配的預期益處很小，Advisor 不會提供建議。

Advisor 建議適用於特定資料表，且不一定適用於含相同資料欄名稱的資料表。欄位名稱相同的資料表，其各欄特性仍可能不同，除非資料表中的資料也相同。

如果您看到由 ETL 任務建立或刪除的暫存資料表建議，則需修改 ETL 程序以使用 Advisor 建議的分佈索引鍵。

變更資料表上的排序索引鍵

Amazon Redshift 會根據資料表的排序索引鍵對表格列進行排序。表格列會根據排序鍵欄值進行排序。

透過適當的排序索引鍵排序表格可以加速查詢效能，特別是有範圍限制述詞的查詢，因為需要從磁碟讀取的表格區塊較少。

分析

Advisor 會分析您叢集在數天的工作負載，為您的表格找出能提供助益的排序索引鍵。

建議

Advisor 會提供兩組 ALTER TABLE 陳述式，此陳述式會根據分析來變更排序索引鍵：

  • 修改目前沒有排序索引鍵的資料表以新增 COMPECT 排序索引鍵的陳述式。

  • 將排序索引鍵從 INTERLEAVED 變更為 COMPOUND 或無排序索引鍵的陳述式。

    使用複合排序索引鍵可大幅降低維護額外負荷。使用複合排序索引鍵的資料表不需要交錯排序所需的高成本 VACUUM REINDEX 操作。實際上，就大多數 Amazon Redshift 工作負載而言，複合排序索引鍵比交錯排序索引鍵更有效果。但是，如果資料表很小，則不使用排序索引鍵以避免排序索引鍵儲存空間負荷會更有效率。

使用 ALTER TABLE 排序大型表格時會消耗叢集資源，您需要在各種不同時間鎖定表格。當叢集的工作負載不高時，請實作每個建議。如需最佳化表格排序索引鍵組態的詳細資訊，請參閱 Amazon Redshift 工程的進階資料表設計操作手冊：複合和交錯排序索引鍵。

如需 ALTER SORTKEY 的相關資訊，請參閱ALTER TABLE。

注意

如果您沒有看到表格的建議，這並不一定表示當前配置是最好的。當沒有足夠的資料或排序的預期益處不大時，Advisor 不會提供建議。

Advisor 建議適用於特定表格，且不一定適用於含有相同名稱和資料類型的表格。根據表格中的資料和工作負載，共用欄名稱的表格可能會有不同的建議。

修改資料欄上的壓縮編碼

壓縮是欄層級操作，可降低資料儲存時的大小。Amazon Redshift 中會使用壓縮來節省儲存空間並透過減少磁碟 I/O 量來改善查詢效能。我們建議您根據資料類型和查詢模式為每個資料欄採用最佳壓縮編碼。透過最佳壓縮，查詢可以更有效率地執行，而且資料庫會佔用最少的儲存空間。

分析

Advisor 會持續執行叢集工作負載和資料庫結構描述的分析，以識別每個資料表資料欄的最佳壓縮編碼。

建議

Advisor 會提供 ALTER TABLE 陳述式，以根據其分析來變更特定資料欄的壓縮編碼。

以 ALTER TABLE 變更資料欄壓縮編碼會耗用叢集資源，且需要在不同時間鎖定資料表。建議您在叢集工作負載很輕時實作建議內容。

作為參考，ALTER TABLE 範例 會顯示數個變更資料欄編碼的陳述式。

注意

當沒有足夠的資料或變更編碼的預期益處不大時，Advisor 不會提供建議。

資料類型建議

Amazon Redshift 具有適用於各種使用案例的 SQL 資料類型程式庫。這些包括整數類型 (例如 INT) 和儲存字元的類型 (例如 VARCHAR)。Redshift 會以最佳化的方式儲存類型，以提供快速存取和良好的查詢效能。此外，Redshift 還提供用於特定類型的函數，您可以使用這些函數對查詢結果進行格式化或執行計算。

分析

Advisor 會持續執行叢集工作負載和資料庫結構描述的分析，以識別可從資料類型變更中顯著受益的資料欄。

建議

Advisor 提供的 ALTER TABLE 陳述式會新增包含建議資料類型的新資料欄。隨附的 UPDATE 陳述式會將資料從現有資料欄複製到新資料欄。建立新資料欄並載入資料後，請變更查詢和擷取指令碼以存取新資料欄。然後利用專門用於新資料類型的功能和函數 (可在 SQL 函數參考 中找到)。

將現有資料複製到新資料欄可能需要一些時間。建議您在叢集的工作負載較輕時，實作每個建議程式建議。在 資料類型 中參考可用資料類型的清單。

請注意，當沒有足夠的資料或變更資料類型的預期益處不大時，Advisor 不會提供建議。