Amazon Redshift tidak akan lagi mendukung pembuatan Python UDFs baru mulai Patch 198. Python yang ada UDFs akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat [posting blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Tabel penyedot debu
Amazon Redshift dapat secara otomatis mengurutkan dan melakukan operasi VACUUM DELETE pada tabel di latar belakang. Untuk membersihkan tabel setelah pemuatan atau serangkaian pembaruan tambahan, Anda juga dapat menjalankan [VAKUM](r_VACUUM_command.md) perintah, baik terhadap seluruh database atau terhadap tabel individual.
**catatan**
Hanya pengguna dengan izin tabel yang diperlukan yang dapat secara efektif menyedot tabel. Jika VACUUM dijalankan tanpa izin tabel yang diperlukan, operasi selesai dengan sukses tetapi tidak berpengaruh. Untuk daftar izin tabel yang valid untuk menjalankan VACUUM secara efektif, lihat[VAKUM](r_VACUUM_command.md).
Untuk alasan ini, kami merekomendasikan menyedot debu tabel individual sesuai kebutuhan. Kami juga merekomendasikan pendekatan ini karena menyedot debu seluruh database berpotensi menjadi operasi yang mahal.
## Penyortiran tabel otomatis
Amazon Redshift secara otomatis mengurutkan data di latar belakang untuk mempertahankan data tabel dalam urutan kunci sortir. Amazon Redshift melacak kueri pemindaian Anda untuk menentukan bagian tabel mana yang akan mendapat manfaat dari penyortiran. Amazon Redshift juga melacak kueri pemindaian dari cluster penskalaan konkurensi. Untuk arsitektur multi cluster yang menggunakan Amazon Redshift Data Sharing, Amazon Redshift juga melacak kueri pemindaian yang berasal dari clusters/workgroups konsumen di mesh data Anda, termasuk di berbagai wilayah. clusters/workgroups Statistik pemindaian dari cluster utama, cluster penskalaan konkurensi, dan cluster konsumen dikumpulkan untuk menentukan bagian tabel mana yang akan mendapat manfaat dari penyortiran.
Bergantung pada beban pada sistem, Amazon Redshift secara otomatis memulai pengurutan. Penyortiran otomatis ini mengurangi kebutuhan untuk menjalankan perintah VACUUM untuk menyimpan data dalam urutan kunci sortir. Jika Anda membutuhkan data yang sepenuhnya diurutkan dalam urutan kunci sortir, misalnya setelah pemuatan data yang besar, maka Anda masih dapat menjalankan perintah VACUUM secara manual. Untuk menentukan apakah tabel Anda akan mendapat manfaat dengan menjalankan VACUUM SORT, pantau `vacuum_sort_benefit` kolom di[SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md).
Amazon Redshift melacak kueri pemindaian yang menggunakan tombol sortir pada setiap tabel. Amazon Redshift memperkirakan persentase maksimum peningkatan dalam pemindaian dan pemfilteran data untuk setiap tabel (jika tabel diurutkan sepenuhnya). Perkiraan ini terlihat di `vacuum_sort_benefit` kolom di[SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Anda dapat menggunakan kolom ini, bersama dengan `unsorted` kolom, untuk menentukan kapan kueri dapat memperoleh manfaat dari menjalankan VACUUM SORT secara manual di atas meja. `unsorted`Kolom mencerminkan urutan fisik dari sebuah tabel. `vacuum_sort_benefit`Kolom menentukan dampak penyortiran tabel dengan menjalankan VACUUM SORT secara manual.
Misalnya, pertimbangkan kueri berikut:
```
select "table", unsorted,vacuum_sort_benefit from svv_table_info order by 1;
```
```
table | unsorted | vacuum_sort_benefit
-------+----------+---------------------
sales | 85.71 | 5.00
event | 45.24 | 67.00
```
Untuk tabel “penjualan”, meskipun tabel \$1 86% tidak disortir secara fisik, dampak kinerja kueri dari tabel yang 86% tidak disortir hanya 5%. Ini mungkin karena hanya sebagian kecil dari tabel yang diakses oleh kueri, atau sangat sedikit kueri yang mengakses tabel. Untuk tabel “acara”, tabel \$1 45% tidak disortir secara fisik. Tetapi dampak kinerja kueri sebesar 67% menunjukkan bahwa sebagian besar tabel diakses oleh kueri, atau jumlah kueri yang mengakses tabel besar. Tabel “acara” berpotensi mendapat manfaat dari menjalankan VACUUM SORT.
## Hapus vakum otomatis
Saat Anda melakukan penghapusan, baris ditandai untuk dihapus, tetapi tidak dihapus. Amazon Redshift secara otomatis menjalankan operasi VACUUM DELETE di latar belakang berdasarkan jumlah baris yang dihapus dalam tabel database. Amazon Redshift menjadwalkan VACUUM DELETE untuk berjalan selama periode pengurangan beban dan menghentikan operasi selama periode beban tinggi.
**Topics**
+ [Penyortiran tabel otomatis](#automatic-table-sort)
+ [Hapus vakum otomatis](#automatic-table-delete)
+ [Frekuensi VAKUM](#vacuum-frequency)
+ [Urutkan tahap dan gabungkan tahap](#vacuum-stages)
+ [Ambang vakum](#vacuum-sort-threshold)
+ [Jenis vakum](#vacuum-types)
+ [Meminimalkan waktu vakum](vacuum-managing-vacuum-times.md)
## Frekuensi VAKUM
Anda harus menyedot debu sesering yang diperlukan untuk mempertahankan kinerja kueri yang konsisten. Pertimbangkan faktor-faktor ini saat menentukan seberapa sering menjalankan perintah VACUUM Anda:
+ Jalankan VACUUM selama periode waktu ketika Anda mengharapkan aktivitas minimal di cluster, seperti malam hari atau selama jendela administrasi database yang ditentukan.
+ Jalankan perintah VACUUM di luar jendela pemeliharaan. Untuk informasi selengkapnya, lihat [Menjadwalkan di sekitar jendela pemeliharaan](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html).
+ Wilayah besar yang tidak disortir menghasilkan waktu vakum yang lebih lama. Jika Anda menunda penyedot debu, vakum akan memakan waktu lebih lama karena lebih banyak data harus ditata ulang.
+ VACUUM adalah operasi I/O intensif, jadi semakin lama waktu yang dibutuhkan untuk menyelesaikan vakum Anda, semakin besar dampaknya pada kueri bersamaan dan operasi database lainnya yang berjalan di cluster Anda.
+ VACUUM membutuhkan waktu lebih lama untuk tabel yang menggunakan penyortiran interleaved. Untuk mengevaluasi apakah tabel yang disisipkan harus diurutkan ulang, kueri tampilan. [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md)
## Urutkan tahap dan gabungkan tahap
Amazon Redshift melakukan operasi vakum dalam dua tahap: pertama, ia mengurutkan baris di wilayah yang tidak disortir, kemudian, jika perlu, ia menggabungkan baris yang baru diurutkan di akhir tabel dengan baris yang ada. Saat menyedot debu meja besar, operasi vakum berlangsung dalam serangkaian langkah yang terdiri dari jenis tambahan diikuti dengan penggabungan. Jika operasi gagal atau jika Amazon Redshift offline selama vakum, tabel atau database yang disedot sebagian akan berada dalam keadaan konsisten, tetapi Anda harus memulai ulang operasi vakum secara manual. Jenis tambahan hilang, tetapi baris gabungan yang dilakukan sebelum kegagalan tidak perlu disedot lagi. Jika wilayah yang tidak disortir besar, waktu yang hilang mungkin signifikan. Untuk informasi selengkapnya tentang tahapan pengurutan dan penggabungan, lihat[Kurangi volume baris gabungan](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows).
Pengguna dapat mengakses tabel saat sedang disedot. Anda dapat melakukan kueri dan menulis operasi saat tabel sedang disedot, tetapi ketika DHTML dan vakum berjalan secara bersamaan, keduanya mungkin membutuhkan waktu lebih lama. Jika Anda menjalankan pernyataan UPDATE dan DELETE selama vakum, kinerja sistem mungkin berkurang. Penggabungan tambahan untuk sementara memblokir operasi UPDATE dan DELETE bersamaan, dan operasi UPDATE dan DELETE pada gilirannya memblokir sementara langkah penggabungan tambahan pada tabel yang terpengaruh. Operasi DDL, seperti ALTER TABLE, diblokir sampai operasi vakum selesai dengan tabel.
**catatan**
Berbagai pengubah untuk VACUUM mengontrol cara kerjanya. Anda dapat menggunakannya untuk menyesuaikan operasi vakum untuk kebutuhan saat ini. Misalnya, menggunakan VACUUM RECLUSTER memperpendek operasi vakum dengan tidak melakukan operasi penggabungan penuh. Untuk informasi selengkapnya, lihat [VAKUM](r_VACUUM_command.md).
## Ambang vakum
Secara default, VACUUM melewatkan fase pengurutan untuk tabel mana pun di mana lebih dari 95 persen baris tabel sudah diurutkan. Melewatkan fase pengurutan dapat secara signifikan meningkatkan kinerja VACUUM. Untuk mengubah ambang batas pengurutan default untuk satu tabel, sertakan nama tabel dan parameter TO *threshold* PERCENT saat Anda menjalankan perintah VACUUM.
## Jenis vakum
Untuk informasi tentang berbagai jenis vakum, lihat[VAKUM](r_VACUUM_command.md).
# Meminimalkan waktu vakum
Amazon Redshift secara otomatis mengurutkan data dan menjalankan VACUUM DELETE di latar belakang. Ini mengurangi kebutuhan untuk menjalankan perintah VACUUM. Menyedot debu berpotensi memakan waktu. Bergantung pada sifat data Anda, kami merekomendasikan praktik berikut untuk meminimalkan waktu vakum.
**Topics**
+ [Putuskan apakah akan mengindeks ulang](#r_vacuum-decide-whether-to-reindex)
+ [Kurangi ukuran wilayah yang tidak disortir](#r_vacuum_diskspacereqs)
+ [Kurangi volume baris gabungan](#vacuum-managing-volume-of-unmerged-rows)
+ [Muat data Anda dalam urutan kunci sortir](#vacuum-load-in-sort-key-order)
+ [Gunakan tabel deret waktu untuk mengurangi data yang tersimpan](#vacuum-time-series-tables)
## Putuskan apakah akan mengindeks ulang
Anda sering dapat meningkatkan kinerja kueri secara signifikan dengan menggunakan gaya pengurutan interleaved, tetapi seiring waktu kinerja mungkin menurun jika distribusi nilai dalam kolom kunci sortir berubah.
Saat Anda pertama kali memuat tabel interleaved kosong menggunakan COPY atau CREATE TABLE AS, Amazon Redshift secara otomatis membuat indeks interleaved. Jika Anda awalnya memuat tabel interleaved menggunakan INSERT, Anda perlu menjalankan VACUUM REINDEX setelahnya untuk menginisialisasi indeks interleaved.
Seiring waktu, saat Anda menambahkan baris dengan nilai kunci sortir baru, kinerja mungkin menurun jika distribusi nilai dalam kolom kunci sortir berubah. Jika baris baru Anda terutama berada dalam kisaran nilai kunci pengurutan yang ada, Anda tidak perlu mengindeks ulang. Jalankan VACUUM SORT ONLY atau VACUUM FULL untuk mengembalikan urutan pengurutan.
Mesin kueri dapat menggunakan urutan pengurutan untuk secara efisien memilih blok data mana yang perlu dipindai untuk memproses kueri. Untuk pengurutan interleaved, Amazon Redshift menganalisis nilai kolom kunci sortir untuk menentukan urutan pengurutan yang optimal. Jika distribusi nilai kunci berubah, atau miring, saat baris ditambahkan, strategi pengurutan tidak akan lagi optimal, dan manfaat kinerja penyortiran akan menurun. Untuk menganalisis ulang distribusi kunci sortir, Anda dapat menjalankan VACUUM REINDEX. Operasi reindex memakan waktu, jadi untuk memutuskan apakah sebuah tabel akan mendapat manfaat dari reindex, kueri tampilan. [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md)
Misalnya, kueri berikut menunjukkan detail untuk tabel yang menggunakan kunci pengurutan interleaved.
```
select tbl as tbl_id, stv_tbl_perm.name as table_name,
col, interleaved_skew, last_reindex
from svv_interleaved_columns, stv_tbl_perm
where svv_interleaved_columns.tbl = stv_tbl_perm.id
and interleaved_skew is not null;
tbl_id | table_name | col | interleaved_skew | last_reindex
--------+------------+-----+------------------+--------------------
100048 | customer | 0 | 3.65 | 2015-04-22 22:05:45
100068 | lineorder | 1 | 2.65 | 2015-04-22 22:05:45
100072 | part | 0 | 1.65 | 2015-04-22 22:05:45
100077 | supplier | 1 | 1.00 | 2015-04-22 22:05:45
(4 rows)
```
Nilai untuk `interleaved_skew` adalah rasio yang menunjukkan jumlah kemiringan. Nilai 1 berarti tidak ada kemiringan. Jika kemiringan lebih besar dari 1,4, VACUUM REINDEX biasanya akan meningkatkan kinerja kecuali kemiringan melekat pada set yang mendasarinya.
Anda dapat menggunakan nilai tanggal `last_reindex` untuk menentukan berapa lama sejak reindex terakhir.
## Kurangi ukuran wilayah yang tidak disortir
Wilayah yang tidak disortir tumbuh ketika Anda memuat sejumlah besar data baru ke dalam tabel yang sudah berisi data atau ketika Anda tidak mengosongkan tabel sebagai bagian dari operasi pemeliharaan rutin Anda. Untuk menghindari operasi vakum yang berjalan lama, gunakan praktik berikut:
+ Jalankan operasi vakum pada jadwal reguler.
Jika Anda memuat tabel Anda secara bertahap (seperti pembaruan harian yang mewakili persentase kecil dari jumlah total baris dalam tabel), menjalankan VACUUM secara teratur akan membantu memastikan bahwa operasi vakum individu berjalan dengan cepat.
+ Jalankan beban terbesar terlebih dahulu.
Jika Anda perlu memuat tabel baru dengan beberapa operasi COPY, jalankan beban terbesar terlebih dahulu. Saat Anda menjalankan pemuatan awal ke tabel baru atau terpotong, semua data dimuat langsung ke wilayah yang diurutkan, jadi tidak diperlukan vakum.
+ Memotong tabel alih-alih menghapus semua baris.
Menghapus baris dari tabel tidak merebut kembali ruang yang ditempati baris sampai Anda melakukan operasi vakum; Namun, memotong tabel mengosongkan tabel dan merebut kembali ruang disk, sehingga tidak diperlukan ruang hampa. Atau, jatuhkan tabel dan buat kembali.
+ Memotong atau menjatuhkan tabel uji.
Jika Anda memuat sejumlah kecil baris ke dalam tabel untuk tujuan pengujian, jangan hapus baris setelah selesai. Sebagai gantinya, potong tabel dan muat ulang baris tersebut sebagai bagian dari operasi beban produksi berikutnya.
+ Lakukan salinan yang dalam.
Jika tabel yang menggunakan tabel kunci sortir majemuk memiliki wilayah besar yang tidak disortir, salinan dalam jauh lebih cepat daripada ruang hampa. Salinan mendalam membuat ulang dan mengisi ulang tabel dengan menggunakan sisipan massal, yang secara otomatis mengurutkan ulang tabel. Jika sebuah tabel memiliki wilayah besar yang tidak disortir, salinan dalam jauh lebih cepat daripada ruang hampa. Trade off adalah Anda tidak dapat membuat pembaruan bersamaan selama operasi penyalinan mendalam, yang dapat Anda lakukan selama ruang hampa. Untuk informasi selengkapnya, lihat [Praktik terbaik Amazon Redshift untuk mendesain kueri](c_designing-queries-best-practices.md).
## Kurangi volume baris gabungan
Jika operasi vakum perlu menggabungkan baris baru ke dalam wilayah yang diurutkan tabel, waktu yang diperlukan untuk ruang hampa akan meningkat seiring dengan bertambahnya tabel. Anda dapat meningkatkan kinerja vakum dengan mengurangi jumlah baris yang harus digabungkan.
Sebelum ruang hampa, tabel terdiri dari wilayah yang diurutkan di kepala tabel, diikuti oleh wilayah yang tidak disortir, yang tumbuh setiap kali baris ditambahkan atau diperbarui. Ketika satu set baris ditambahkan oleh operasi COPY, kumpulan baris baru diurutkan pada kunci sortir karena ditambahkan ke wilayah yang tidak disortir di akhir tabel. Baris baru diurutkan dalam set mereka sendiri, tetapi tidak dalam wilayah yang tidak disortir.
Diagram berikut menggambarkan wilayah yang tidak disortir setelah dua operasi COPY berturut-turut, di mana kunci sortir adalah CUSTID. Untuk mempermudah, contoh ini menunjukkan kunci sortir majemuk, tetapi prinsip yang sama berlaku untuk kunci sortir yang disisipkan, kecuali bahwa dampak wilayah yang tidak disortir lebih besar untuk tabel yang disisipkan.
![\[Tabel yang tidak disortir menyimpan catatan dari dua operasi COPY.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/vacuum-unsorted-region.png)
Vakum mengembalikan urutan tabel dalam dua tahap:
1. Urutkan wilayah yang tidak disortir menjadi wilayah yang baru diurutkan.
Tahap pertama relatif murah, karena hanya wilayah yang tidak disortir yang ditulis ulang. Jika rentang nilai kunci sortir dari wilayah yang baru diurutkan lebih tinggi dari rentang yang ada, hanya baris baru yang perlu ditulis ulang, dan ruang hampa selesai. Misalnya, jika wilayah yang diurutkan berisi nilai ID 1 hingga 500 dan operasi penyalinan berikutnya menambahkan nilai kunci yang lebih besar dari 500, maka hanya wilayah yang tidak disortir yang perlu ditulis ulang.
1. Gabungkan wilayah yang baru diurutkan dengan wilayah yang telah diurutkan sebelumnya.
Jika kunci di wilayah yang baru diurutkan tumpang tindih dengan kunci di wilayah yang diurutkan, maka VACUUM perlu menggabungkan baris. Mulai dari awal wilayah yang baru diurutkan (pada kunci pengurutan terendah), ruang hampa menulis baris gabungan dari wilayah yang diurutkan sebelumnya dan wilayah yang baru diurutkan ke dalam kumpulan blok baru.
Sejauh mana rentang kunci sortir baru tumpang tindih dengan kunci pengurutan yang ada menentukan sejauh mana wilayah yang diurutkan sebelumnya perlu ditulis ulang. Jika kunci yang tidak disortir tersebar di seluruh rentang pengurutan yang ada, ruang hampa mungkin perlu menulis ulang bagian tabel yang ada.
Diagram berikut menunjukkan bagaimana vakum akan mengurutkan dan menggabungkan baris yang ditambahkan ke tabel di mana CUSTID adalah kunci sortir. Karena setiap operasi penyalinan menambahkan satu set baris baru dengan nilai kunci yang tumpang tindih dengan kunci yang ada, hampir seluruh tabel perlu ditulis ulang. Diagram menunjukkan pengurutan tunggal dan penggabungan, tetapi dalam praktiknya, ruang hampa besar terdiri dari serangkaian langkah pengurutan dan penggabungan tambahan.
![\[Operasi VACUUM pada tabel contoh dalam dua langkah. Pertama baris baru diurutkan, lalu digabungkan dengan baris yang ada.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png)
Jika rentang kunci sortir dalam satu set baris baru tumpang tindih dengan kisaran kunci yang ada, biaya tahap penggabungan terus tumbuh sebanding dengan ukuran tabel saat tabel tumbuh sementara biaya tahap pengurutan tetap sebanding dengan ukuran wilayah yang tidak disortir. Dalam kasus seperti itu, biaya tahap penggabungan membayangi biaya tahap pengurutan, seperti yang ditunjukkan diagram berikut.
![\[Diagram yang menunjukkan bagaimana tahap penggabungan menjadi lebih mahal ketika baris baru memiliki kunci pengurutan yang tumpang tindih dengan baris yang ada.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/vacuum-example-merge-region-grows.png)
Untuk menentukan proporsi tabel yang digabungkan ulang, kueri SVV\$1VACUUM\$1SUMMARY setelah operasi vakum selesai. Kueri berikut menunjukkan efek dari enam vakum berturut-turut karena CUSTSALES tumbuh lebih besar dari waktu ke waktu.
```
select * from svv_vacuum_summary
where table_name = 'custsales';
table_name | xid | sort_ | merge_ | elapsed_ | row_ | sortedrow_ | block_ | max_merge_
| | partitions | increments | time | delta | delta | delta | partitions
-----------+------+------------+------------+------------+-------+------------+---------+---------------
custsales | 7072 | 3 | 2 | 143918314 | 0 | 88297472 | 1524 | 47
custsales | 7122 | 3 | 3 | 164157882 | 0 | 88297472 | 772 | 47
custsales | 7212 | 3 | 4 | 187433171 | 0 | 88297472 | 767 | 47
custsales | 7289 | 3 | 4 | 255482945 | 0 | 88297472 | 770 | 47
custsales | 7420 | 3 | 5 | 316583833 | 0 | 88297472 | 769 | 47
custsales | 9007 | 3 | 6 | 306685472 | 0 | 88297472 | 772 | 47
(6 rows)
```
Kolom merge\$1increments memberikan indikasi jumlah data yang digabungkan untuk setiap operasi vakum. Jika jumlah kenaikan penggabungan selama vakum berturut-turut meningkat sebanding dengan pertumbuhan ukuran tabel, ini menunjukkan bahwa setiap operasi vakum menggabungkan kembali peningkatan jumlah baris dalam tabel karena daerah yang ada dan yang baru diurutkan tumpang tindih.
## Muat data Anda dalam urutan kunci sortir
Jika Anda memuat data Anda dalam urutan kunci sortir menggunakan perintah COPY, Anda dapat mengurangi atau bahkan menghapus kebutuhan untuk menyedot debu.
COPY secara otomatis menambahkan baris baru ke wilayah tabel yang diurutkan ketika semua hal berikut benar:
+ Tabel menggunakan kunci sortir majemuk dengan hanya satu kolom sortir.
+ Kolom sortir BUKAN NULL.
+ Tabel 100 persen diurutkan atau kosong.
+ Semua baris baru lebih tinggi dalam urutan pengurutan daripada baris yang ada, termasuk baris yang ditandai untuk dihapus. Dalam hal ini, Amazon Redshift menggunakan delapan byte pertama dari kunci sortir untuk menentukan urutan pengurutan.
+ Perintah COPY tidak memicu optimasi beban tertentu. Saat memuat volume data yang besar, Amazon Redshift mungkin mengoptimalkan kinerja dengan membuat partisi baru yang diurutkan daripada menambahkan baris ke wilayah tabel yang diurutkan.
Misalnya, Anda memiliki tabel yang mencatat peristiwa pelanggan menggunakan ID pelanggan dan waktu. Jika Anda mengurutkan ID pelanggan, kemungkinan rentang kunci pengurutan baris baru yang ditambahkan oleh beban tambahan akan tumpang tindih dengan rentang yang ada, seperti yang ditunjukkan pada contoh sebelumnya, yang mengarah ke operasi vakum yang mahal.
Jika Anda mengatur kunci pengurutan ke kolom stempel waktu, baris baru Anda akan ditambahkan dalam urutan pengurutan di akhir tabel, seperti yang ditunjukkan diagram berikut, mengurangi atau bahkan menghilangkan kebutuhan untuk menyedot debu.
![\[Tabel yang menggunakan kolom timestamp sebagai kunci pengurutan, mendapatkan catatan baru yang tidak perlu diurutkan.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png)
## Gunakan tabel deret waktu untuk mengurangi data yang tersimpan
Jika Anda memelihara data untuk periode waktu bergulir, gunakan serangkaian tabel, seperti yang diilustrasikan diagram berikut.
![\[Lima tabel dengan data dari lima kuartal. Tabel tertua dihapus untuk mempertahankan satu tahun waktu bergulir.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png)
Buat tabel baru setiap kali Anda menambahkan satu set data, lalu hapus tabel tertua dalam seri. Anda mendapatkan manfaat ganda:
+ Anda menghindari biaya tambahan untuk menghapus baris, karena operasi DROP TABLE jauh lebih efisien daripada DELETE massal.
+ Jika tabel diurutkan berdasarkan stempel waktu, tidak diperlukan vakum. Jika setiap tabel berisi data selama satu bulan, ruang hampa paling banyak harus menulis ulang data selama satu bulan, bahkan jika tabel tidak diurutkan berdasarkan stempel waktu.
Anda dapat membuat tampilan UNION ALL untuk digunakan dengan melaporkan kueri yang menyembunyikan fakta bahwa data disimpan dalam beberapa tabel. Jika kueri memfilter pada kunci pengurutan, perencana kueri dapat secara efisien melewati semua tabel yang tidak digunakan. UNION ALL bisa kurang efisien untuk jenis kueri lainnya, jadi Anda harus mengevaluasi kinerja kueri dalam konteks semua kueri yang menggunakan tabel.