我們的集羣是一個4節點集羣。我們有一個由72列組成的表格。當我們查詢svv_diskusage表來檢查每個片段中列的分配時,我們發現每列都被分配到2個塊(0和1)中。但是對於少數列,我們有varchar(1)的數據類型,它不應該佔用兩個空間塊。Amazon Redshift表塊分配
是否有可能的是,如果列之一佔據比一個塊以上(在VARCHAR(1500)的情況下),那麼相同的被分配用於該表的所有其他列。如果是,這將如何影響集羣的整體數據庫大小。
我們的集羣是一個4節點集羣。我們有一個由72列組成的表格。當我們查詢svv_diskusage表來檢查每個片段中列的分配時,我們發現每列都被分配到2個塊(0和1)中。但是對於少數列,我們有varchar(1)的數據類型,它不應該佔用兩個空間塊。Amazon Redshift表塊分配
是否有可能的是,如果列之一佔據比一個塊以上(在VARCHAR(1500)的情況下),那麼相同的被分配用於該表的所有其他列。如果是,這將如何影響集羣的整體數據庫大小。
每個亞馬遜紅移存儲塊是1MB的大小。每個塊包含一個表內只有一列的數據。
的SVV_DISKUSAGE
system view包含這些塊的列表,例如:
select db_id, trim(name) as tablename, col, tbl, max(blocknum)
from svv_diskusage
where name='salesnew'
group by db_id, name, col, tbl
order by db_id, name, col, tbl;
db_id | tablename | col | tbl | max
--------+------------+-----+--------+-----
175857 | salesnew | 0 | 187605 | 154
175857 | salesnew | 1 | 187605 | 154
175857 | salesnew | 2 | 187605 | 154
175857 | salesnew | 3 | 187605 | 154
175857 | salesnew | 4 | 187605 | 154
175857 | salesnew | 5 | 187605 | 79
175857 | salesnew | 6 | 187605 | 79
175857 | salesnew | 7 | 187605 | 302
175857 | salesnew | 8 | 187605 | 302
175857 | salesnew | 9 | 187605 | 302
175857 | salesnew | 10 | 187605 | 3
175857 | salesnew | 11 | 187605 | 2
175857 | salesnew | 12 | 187605 | 296
(13 rows)
存儲每一列所需的塊的數量取決於數據的數量,並用於該表的compression encoding。
Amazon Redshift還存儲存儲在每個塊中的數據的minvalue
和maxvalue
。這在SVV_DISKUSAGE
表中可見。這些值通常稱爲區域圖,它們用於識別掃描數據時可以跳過的塊。例如,如果一個WHERE
子句查找行與該列中的值5
,然後用6
的minvalue
塊可以完全跳過。數據壓縮時這特別有用。
要調查爲什麼你的數據是消費兩大塊,檢查:
minvalue
和存儲在每個塊那些每塊
num_values
)的數量maxvalue
值會讓你知道每塊中存儲了多少數據,以及是否符合你的期望。 此外,請看錶中使用的分發密鑰(DISTKEY
)。如果DISTKEY
設置爲ALL
,則在多個節點之間複製表數據。這也可以解釋你的塊數。
最後,如果數據已從表中刪除,則舊值可能佔用磁盤空間。在表上運行VACUUM
命令以刪除已刪除的數據。
一個很好的參考是:Why does a table in my Amazon Redshift cluster consume more disk storage space than expected?