Menguji pengkodean kompresi - Amazon Redshift
Contoh

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menguji pengkodean kompresi

Jika Anda memutuskan untuk menentukan pengkodean kolom secara manual, Anda mungkin ingin menguji pengkodean yang berbeda dengan data Anda.

catatan

Kami menyarankan Anda menggunakan COPY perintah untuk memuat data bila memungkinkan, dan memungkinkan COPY perintah untuk memilih pengkodean optimal berdasarkan data Anda. Atau Anda dapat menggunakan ANALYZE COMPRESSION perintah untuk melihat pengkodean yang disarankan untuk data yang ada. Untuk detail tentang menerapkan kompresi otomatis, lihatMemuat tabel dengan kompresi otomatis.

Untuk melakukan tes kompresi data yang berarti, Anda harus memiliki sejumlah besar baris. Untuk contoh ini, kita membuat tabel dan menyisipkan baris dengan menggunakan pernyataan yang memilih dari dua tabel; VENUE danLISTING. Kami meninggalkan WHERE klausa yang biasanya akan bergabung dengan dua tabel. Hasilnya adalah bahwa setiap baris dalam VENUE tabel bergabung dengan semua baris dalam LISTING tabel, dengan total lebih dari 32 juta baris. Ini dikenal sebagai bergabung Cartesian dan biasanya tidak disarankan. Namun, untuk tujuan ini, ini adalah metode yang nyaman untuk membuat banyak baris. Jika Anda memiliki tabel yang ada dengan data yang ingin Anda uji, Anda dapat melewati langkah ini.

Setelah kami memiliki tabel dengan data sampel, kami membuat tabel dengan tujuh kolom. Masing-masing memiliki pengkodean kompresi yang berbeda: raw, bytedict, lzo, run length, text255, text32k, dan zstd. Kami mengisi setiap kolom dengan data yang persis sama dengan menjalankan INSERT perintah yang memilih data dari tabel pertama.

Untuk menguji pengkodean kompresi, lakukan hal berikut:

  1. (Opsional) Pertama, gunakan gabungan Cartesian untuk membuat tabel dengan sejumlah besar baris. Lewati langkah ini jika Anda ingin menguji tabel yang ada. 

    create table cartesian_venue(
venueid smallint not null distkey sortkey,
venuename varchar(100),
venuecity varchar(30),
venuestate char(2),
venueseats integer);

insert into cartesian_venue
select venueid, venuename, venuecity, venuestate, venueseats
from venue, listing;

  2. Selanjutnya, buat tabel dengan pengkodean yang ingin Anda bandingkan. 

    create table encodingvenue (
venueraw varchar(100) encode raw,
venuebytedict varchar(100) encode bytedict,
venuelzo varchar(100) encode lzo,
venuerunlength varchar(100) encode runlength,
venuetext255 varchar(100) encode text255,
venuetext32k varchar(100) encode text32k,
venuezstd varchar(100) encode zstd);

  3. Masukkan data yang sama ke semua kolom menggunakan INSERT pernyataan dengan SELECT klausa. 

    insert into encodingvenue
select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as  venuetext32k, venuename as  venuetext255, venuename as venuezstd
from cartesian_venue;

  4. Verifikasi jumlah baris di tabel baru. 

    select count(*) from encodingvenue

  count
----------
 38884394
(1 row)

  5. Kueri tabel STV_BLOCKLIST sistem untuk membandingkan jumlah blok disk 1 MB yang digunakan oleh setiap kolom.

    Fungsi MAX agregat mengembalikan nomor blok tertinggi untuk setiap kolom. BLOCKLISTTabel STV _ mencakup rincian untuk tiga kolom yang dihasilkan sistem. Contoh ini digunakan col < 6 dalam WHERE klausa untuk mengecualikan kolom yang dihasilkan sistem. 

    select col, max(blocknum)
from stv_blocklist b, stv_tbl_perm p
where (b.tbl=p.id) and name ='encodingvenue'
and col < 7
group by name, col
order by col;

    Query mengembalikan hasil sebagai berikut. Kolom diberi nomor dimulai dengan nol. Bergantung pada bagaimana cluster Anda dikonfigurasi, hasil Anda mungkin memiliki angka yang berbeda, tetapi ukuran relatifnya harus serupa. Anda dapat melihat bahwa BYTEDICT pengkodean pada kolom kedua menghasilkan hasil terbaik untuk kumpulan data ini. Pendekatan ini memiliki rasio kompresi lebih baik dari 20:1. LZOdan ZSTD pengkodean juga menghasilkan hasil yang sangat baik. Kumpulan data yang berbeda menghasilkan hasil yang berbeda, tentu saja. Ketika kolom berisi string teks yang lebih panjang, LZO sering menghasilkan hasil kompresi terbaik.

     col | max
-----+-----
   0 | 203
   1 |  10
   2 |  22
   3 | 204
   4 |  56
   5 |  72
   6 |  20
(7 rows)

Jika Anda memiliki data dalam tabel yang ada, Anda dapat menggunakan ANALYZE COMPRESSION perintah untuk melihat pengkodean yang disarankan untuk tabel. Misalnya, contoh berikut menunjukkan pengkodean yang disarankan untuk salinan VENUE tabel, CARTESIAN _VENUE, yang berisi 38 juta baris. Perhatikan bahwa ANALYZE COMPRESSION merekomendasikan LZO pengkodean untuk VENUENAME kolom. ANALYZECOMPRESSIONmemilih kompresi optimal berdasarkan beberapa faktor, yang meliputi persen pengurangan. Dalam kasus khusus ini, BYTEDICT memberikan kompresi yang lebih baik, tetapi LZO juga menghasilkan kompresi lebih dari 90 persen. 

analyze compression cartesian_venue;

Table          | Column     | Encoding | Est_reduction_pct
---------------+------------+----------+------------------
reallybigvenue | venueid    | lzo      | 97.54            
reallybigvenue | venuename  | lzo      | 91.71            
reallybigvenue | venuecity  | lzo      | 96.01            
reallybigvenue | venuestate | lzo      | 97.68            
reallybigvenue | venueseats | lzo      | 98.21

Contoh

Contoh berikut membuat CUSTOMER tabel yang memiliki kolom dengan berbagai tipe data. CREATETABLEPernyataan ini menunjukkan salah satu dari banyak kemungkinan kombinasi pengkodean kompresi untuk kolom ini. 

create table customer(
custkey int encode delta,
custname varchar(30) encode raw,
gender varchar(7) encode text255,
address varchar(200) encode text255,
city varchar(30) encode text255,
state char(2) encode raw,
zipcode char(5) encode bytedict,
start_date date encode delta32k);

Tabel berikut menunjukkan pengkodean kolom yang dipilih untuk CUSTOMER tabel dan memberikan penjelasan untuk pilihan:

Kolom Tipe data Encoding Penjelasan
CUSTKEY int delta CUSTKEYterdiri dari nilai integer yang unik dan berurutan. Karena perbedaannya satu byte, DELTA adalah pilihan yang baik.
CUSTNAME varchar (30) mentah CUSTNAMEmemiliki domain besar dengan beberapa nilai berulang. Pengkodean kompresi apa pun mungkin tidak efektif.
GENDER varchar (7) teks255 GENDERadalah domain yang sangat kecil dengan banyak nilai berulang. Text255 bekerja dengan baik dengan VARCHAR kolom di mana kata-kata yang sama berulang.
ADDRESS varchar (200) teks255 ADDRESSadalah domain besar, tetapi berisi banyak kata berulang, seperti Street, Avenue, North, South, dan sebagainya. Teks 255 dan teks 32k berguna untuk mengompresi VARCHAR kolom di mana kata-kata yang sama berulang. Panjang kolom pendek, jadi text255 adalah pilihan yang baik.
CITY varchar (30) teks255 CITYadalah domain besar, dengan beberapa nilai berulang. Nama-nama kota tertentu digunakan jauh lebih umum daripada yang lain. Text255 adalah pilihan yang baik untuk alasan yang sama seperti. ADDRESS
STATE arang (2) mentah Di Amerika Serikat, STATE adalah domain yang tepat dari 50 nilai dua karakter. Pengkodean Bytedict akan menghasilkan beberapa kompresi, tetapi karena ukuran kolom hanya dua karakter, kompresi mungkin tidak sebanding dengan overhead untuk membuka kompresi data.
ZIPCODE arang (5) bytediktus ZIPCODEadalah domain yang diketahui kurang dari 50.000 nilai unik. Kode pos tertentu terjadi jauh lebih umum daripada yang lain. Pengkodean Bytedict sangat efektif ketika kolom berisi sejumlah nilai unik yang terbatas.
START_DATE date delta32k Pengkodean Delta sangat berguna untuk kolom waktu tanggal, terutama jika baris dimuat dalam urutan tanggal.