選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

壓縮編碼

焦點模式
壓縮編碼 - Amazon Redshift

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

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

壓縮編碼會指定在資料列新增至資料表時,套用至一欄資料值的壓縮類型。

ENCODE AUTO 是資料表的預設值。當資料表設定為 ENCODE AUTO 時,Amazon Redshift 會自動管理資料表中所有資料欄的壓縮編碼。如需詳細資訊,請參閱 CREATE TABLEALTER TABLE

不過,如果您為資料表中的任何資料欄指定壓縮編碼,資料表就不會再設定為 ENCODE AUTO。Amazon Redshift 不再自動管理資料表中所有資料欄的壓縮編碼。

當您使用 CREATE TABLE 時,當您為資料表中的任何資料欄指定壓縮編碼時,會停用 ENCODE AUTO。如果停用 ENCODE AUTO,Amazon Redshift 會自動將壓縮編碼指派給您未指定 ENCODE 類型的資料欄,如下所示:

  • 定義為排序索引鍵的資料欄會有指派的 RAW 壓縮。

  • 定義為 BOOLEAN、REAL 或 DOUBLE PRECISION 資料類型的資料欄會有指派的 RAW 壓縮。

  • 定義為 SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIMESTAMP 或 TIMESTAMPTZ 資料類型的資料欄會有指派的 AZ64 壓縮。

  • 定義為 CHAR 或 VARCHAR 資料類型的資料欄會有指派的 LZO 壓縮。

您可以使用 ALTER TABLE 在建立資料表之後變更資料表的編碼。如果您使用 ALTER 資料表停用 ENCODE AUTO 功能,Amazon Redshift 將不再自動管理資料欄的壓縮編碼。所有資料欄都會保留您停用 ENCODE 時的壓縮編碼類型,直到您將其變更或再次啟用 ENCODE AUTO 為止。

Amazon Redshift 支援下列壓縮編碼:

Raw

Raw 編碼是下列資料欄的預設編碼:指定為排序索引鍵的資料欄,以及定義為 BOOLEAN、REAL 或 DOUBLE PRECISION 資料類型的資料欄。系統使用 Raw 編碼,以原始、未壓縮格式來儲存資料。

AZ64

AZ64 是 Amazon 設計的專屬壓縮編碼,旨在實現高壓縮比並改善查詢處理能力。AZ64 演算法的核心是壓縮更小的一組資料值,並使用單指令、多資料 (SIMD) 指令進行並行處理。使用 AZ64 為數字、日期及時間資料類型節省大量儲存空間並實現高效能。

當搭配下列資料類型使用 CREATE TABLE 及 ALTER TABLE 陳述式,來定義資料欄時,您可以使用 AZ64 做為壓縮編碼:

  • SMALLINT

  • INTEGER

  • BIGINT

  • DECIMAL

  • DATE

  • TIMESTAMP

  • TIMESTAMPTZ

Byte-dictionary

在 byte dictionary 編碼中,唯一值的個別字典是針對磁碟上資料欄值的每個區塊而建立的。(Amazon Redshift 磁碟會佔用 1 MB。) 字典最多可包含 256 個一元位元組值,其會以索引形式儲存至原始資料值。如果在單一區塊中儲存超過 256 個值,則額外的值會以原始、未壓縮格式寫入至區塊。對於每個磁碟區塊都會重複此程序。

這種編碼對低基數字串資料欄非常有效。當資料欄的資料網域少於 256 個唯一值時,這是最佳的編碼。

對於字串資料類型 (CHAR 和 VARCHAR) 使用 BYTEDICT 編碼的資料欄,Amazon Redshift 會執行向量化掃描和述詞評估,直接對壓縮資料進行操作。這些掃描會使用硬體專屬的單一指示和多重資料 (SIMD) 指示進行平行處理。這會顯著加快字串資料欄的掃描速度。如果 CHAR/VARCHAR 資料欄保存長字元字串,則 Byte-dictionary 編碼特別節省空間。

假設資料表具有資料類型為 CHAR(30) 的 COUNTRY 資料欄。載入資料時,Amazon Redshift 會建立字典。並在 COUNTRY 資料欄填入索引值。字典包含已建立索引的唯一值,而且資料表本身只包含對應值的一位元組下標。

注意

會儲存固定長度字元欄的多餘空格。因此,在 CHAR(30) 資料欄中,當您使用 byte-dictionary 編碼時,每個對應值都會節省 29 個位元組的儲存空間。

下表代表 COUNTRY 資料欄的字典。

唯一資料值 字典索引 大小 (固定長度,每個值 30 個位元組)
England 0 30
United States of America 1 30
Venezuela 2 30
Sri Lanka 3 30
Argentina 4 30
Japan 5 30
合計 180

下表代表 COUNTRY 資料欄中的值。

原始資料值 原始大小 (固定長度,每個值 30 個位元組) 壓縮值 (索引) 新大小 (位元組)
England 30 0 1
England 30 0 1
United States of America 30 1 1
United States of America 30 1 1
Venezuela 30 2 1
Sri Lanka 30 3 1
Argentina 30 4 1
Japan 30 5 1
Sri Lanka 30 3 1
Argentina 30 4 1
合計 300 10

此範例中的合計壓縮大小計算如下:6 個不同項目儲存在字典 (6 * 30 = 180),而且資料表包含 10 個 1 位元組壓縮值,合計 190 個位元組。

Delta

Delta 編碼對日期時間欄很有用。

Delta 藉由記錄資料欄中彼此跟隨的值之間的差異來壓縮資料。此差異會記錄在磁碟上資料欄值之每個區塊的個別字典中。(Amazon Redshift 磁碟會佔用 1 MB。) 例如,假設資料欄包含 10 個整數,順序從 1 到 10。第一個會儲存為 4 位元組整數 (加上 1 位元組旗標)。接下來的九個會分別儲存為值為 1 的位元組,表示比前一個值多 1。

Delta 編碼附有兩個變異:

  • DELTA 會將差異記錄為 1 位元組值 (8 位元組整數)

  • DELTA32K 會將差異記錄為 2 位元組值 (16 位元組整數)

如果資料欄中的大多數值可以透過使用單一位元組進行壓縮,則 1 位元組的變化非常有效。但是,如果差異較大,則此編碼 (在最壞的情況下) 會比儲存未壓縮資料的效果差。類似邏輯適用於 16 位元版本。

如果兩個值之間的差異超過 1 位元組範圍 (DELTA) 或 2 位元組範圍 (DELTA32K),則會儲存完整原始值,前面為 1 位元組旗標。1 位元組範圍從 -127 到 127,而 2 位元組範圍從 -32K 到 32K。

下表顯示數值欄的 Delta 編碼如何運作。

原始資料值 原始大小 (位元組) 差異 (delta) 壓縮值 壓縮大小 (位元組)
1 4 1 1+4 (旗標 + 實際值)
5 4 4 4 1
50 4 45 45 1
200 4 150 150 1+4 (旗標 + 實際值)
185 4 -15 -15 1
220 4 35 35 1
221 4 1 1 1
合計 28 15
LZO

LZO 壓縮編碼提供非常高的壓縮率和良好的效能。LZO 編碼特別適用於儲存很長的字元字串的 CHAR 和 VARCHAR 資料欄。它們特別適用於自由格式文字,例如產品說明、使用者註解或 JSON 字串。

Mostly

當資料欄的資料類型大於大部份儲存值所需的資料類型時,Mostly 編碼很有用。您可以對此類型的資料欄指定 mostly 編碼,將資料欄中的大部分值壓縮為更小的標準儲存空間大小。剩下無法壓縮的值會以其原始格式儲存。例如,您可以將 16 位元資料欄 (例如 INT2 資料欄) 壓縮為 8 位元儲存空間。

通常,mostly 編碼會使用下列資料類型:

  • SMALLINT/INT2 (16 位元)

  • INTEGER/INT (32 位元)

  • BIGINT/INT8 (64 位元)

  • DECIMAL/NUMERIC (64 位元)

選擇 mostly 編碼的適當變異來符合資料欄之資料類型的大小。例如,將 MOSTLY8 套用至定義為 16 位元整數資料欄的資料欄。不允許將 MOSTLY16 套用至具有 16 位元資料類型的資料欄,也不允許將 MOSTLY32 套用至具有 32 位元資料類型的資料欄。

當資料欄中有相當多的值無法壓縮時,Mostly 編碼可能比無壓縮更沒效率。在將其中一種編碼套用到資料欄之前,請執行檢查。您現在將載入的大部分值 (也可能在未來載入) 應納入下表中顯示的範圍。

編碼 壓縮儲存空間大小 可以壓縮的值範圍 (範圍外的值會以原始形式儲存)
MOSTLY8 1 位元組 (8 位元) -128 到 127
MOSTLY16 2 位元組 (16 位元) -32768 到 32767
MOSTLY32 4 位元組 (32 位元) -2147483648 到 +2147483647
注意

對於小數,忽略小數點以判斷值是否納入範圍。例如,1,234.56 會視為 123,456,且可在 MOSTLY32 資料欄中壓縮。

例如,VENUE 資料表中的 VENUEID 資料欄會定義為原始整數資料欄,這表示其值佔用 4 位元組的儲存空間。不過,此欄的值目前範圍是 0309。因此,針對 VENUEID 使用 MOSTLY16 編碼來重建和重新載入此資料表,會將該資料欄中每個值的儲存空間減少至 2 個位元組。

如果另一個資料表中參考的 VENUEID 值大部分在範圍 0 到 127,則將該外部索引鍵資料欄編碼為 MOSTLY8 可能就有意義。在做出選擇之前,請針對參考資料表資料執行數個查詢,以了解值是否大部分都落入 8 位元、16 位元或 32 位元範圍。

下表顯示在使用 MOSTLY8、MOSTLY16 和 MOSTLY32 編碼時特定數值的壓縮大小:

原始值 原始 INT 或 BIGINT 大小 (位元組) MOSTLY8 壓縮大小 (位元組) MOSTLY16 壓縮大小 (位元組) MOSTLY32 壓縮大小 (位元組)
1 4 1 2 4
10 4 1 2 4
100 4 1 2 4
1000 4 與原始資料大小相同 2 4
10000 4 2 4
20000 4 2 4
40000 8 與原始資料大小相同 4
100000 8 4
2000000000 8 4
Run length

執行長度編碼會將連續重複的值取代為由值和連續出現次數 (執行長度) 組成的符記。唯一值的個別字典是針對磁碟上資料欄值的每個區塊而建立的。(Amazon Redshift 磁碟會佔用 1 MB。) 此編碼最適合於資料值通常連續重複的資料表,例如,依那些值排序資料表時。

例如,假設大型維度資料表中的資料欄具有可預測的較小領域,例如 COLOR 資料欄的可能值少於 10 個。這些值可能會落在整個資料表中的長序列中,即使資料未排序也是如此。

不建議在指定為排序索引鍵的任何資料欄上套用執行長度編碼。當區塊包含類似的列數時,限制範圍的掃描執行效果會更好。如果排序索引鍵欄位的壓縮比相同查詢中的其他欄位高出許多,限制範圍的掃描執行效果可能較差。

下表使用 COLOR 資料欄範例來顯示執行長度編碼如何運作。

原始資料值 原始大小 (位元組) 壓縮值 (符記) 壓縮大小 (位元組)
Blue 4 {2,藍色} 5
Blue 4 0
Green 5 {3,綠色} 6
Green 5 0
Green 5 0
Blue 4 {1,Blue} 5
Yellow 6 {4,Yellow} 7
Yellow 6 0
Yellow 6 0
Yellow 6 0
合計 51 23
Text255 and Text32k

Text255 和 text32k 編碼有助於相同單字經常重複出現的壓縮 VARCHAR 資料欄。唯一單字的個別字典是針對磁碟上資料欄值的每個區塊而建立的。(Amazon Redshift 磁碟會佔用 1 MB。) 字典包含資料欄中前 245 個唯一單字。那些單字會在磁碟上被代表 245 個值之一的一位元組索引值所取代,而且未在字典中表示的任何單字會以未壓縮形式儲存。對於每個 1 MB 磁碟區塊都會重複此程序。如果建立索引的單字經常出現在資料欄中,則資料欄將產生高壓縮率。

對於 text32k 編碼,原則相同,但每個區塊的字典不會擷取特定數目的單字。反之,字典會為其找到的每個唯一單字建立索引,直到結合的項目達到 32K 長度,減去一些額外負荷。索引值是以兩個位元組儲存。

例如,考慮 VENUE 資料表中的 VENUENAME 資料欄。ArenaCenterTheatre 等單字反覆出現在這個欄中,而且若套用 text255 壓縮,則很可能出現在每個區塊中的前 245 個單字之中。如果是這樣,則此資料欄將受益於壓縮。因為每次那些單字出現,它們將只佔用 1 個位元組的儲存空間 (而不是分別佔用 5、6 或 7 個位元組)。

ZSTD

對於各種資料集,Zstandard (ZSTD) 編碼提供高壓縮率和極佳效能。ZSTD 編碼特別適用於儲存廣泛長短字串的 CHAR 和 VARCHAR 資料欄,特別是自由格式的文字,例如產品描述、使用者意見、日誌和 JSON 字串。在某些演算法,例如 Delta 編碼或大部分編碼,可能使用比沒有壓縮更多的儲存空間時,ZSTD 不太可能增加磁碟使用量。

ZSTD 支援 SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP 和 TIMESTAMPTZ 等資料類型。

Raw 編碼是下列資料欄的預設編碼:指定為排序索引鍵的資料欄,以及定義為 BOOLEAN、REAL 或 DOUBLE PRECISION 資料類型的資料欄。系統使用 Raw 編碼,以原始、未壓縮格式來儲存資料。

下表識別支援的壓縮編碼和支援編碼的資料類型。

編碼類型 CREATE TABLE 和 ALTER TABLE 中的關鍵字 資料類型
Raw (無壓縮) RAW 全部
AZ64 AZ64 SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIMESTAMP、TIMESTAMPTZ
Byte dictionary BYTEDICT SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、CHAR、VARCHAR、DATE、TIMESTAMP、TIMESTAMPTZ
Delta

DELTA

DELTA32K

SMALLINT、INT、BIGINT、DATE、TIMESTAMP、DECIMAL

INT、BIGINT、DATE、TIMESTAMP、DECIMAL

LZO LZO SMALLINT、INTEGER、BIGINT、DECIMAL、CHAR、VARCHAR、DATE、TIMESTAMP、TIMESTAMPTZ、SUPER
Mostlyn

MOSTLY8

MOSTLY16

MOSTLY32

SMALLINT、INT、BIGINT、DECIMAL

INT、BIGINT、DECIMAL

BIGINT、DECIMAL

Run-length RUNLENGTH SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、TIMESTAMPTZ
文字

TEXT255

TEXT32K

僅限 VARCHAR

僅限 VARCHAR

Zstandard ZSTD SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、TIMESTAMPTZ、SUPER
隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。