Mengevaluasi rencana kueri - Amazon Redshift

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

Mengevaluasi rencana kueri

Anda dapat menggunakan rencana kueri untuk mengidentifikasi kandidat untuk mengoptimalkan gaya distribusi.

Setelah membuat keputusan desain awal Anda, buat tabel Anda, muat dengan data, dan uji. Gunakan kumpulan data pengujian yang sedekat mungkin dengan data nyata. Ukur waktu muat untuk digunakan sebagai dasar untuk perbandingan.

Evaluasi kueri yang mewakili kueri paling mahal yang Anda harapkan untuk dijalankan, khususnya kueri yang menggunakan gabungan dan agregasi. Bandingkan runtime untuk berbagai opsi desain. Saat Anda membandingkan runtime, jangan hitung saat pertama kali kueri dijalankan, karena runtime pertama menyertakan waktu kompilasi.

DS_DIST_TIDAK ADA

Tidak diperlukan redistribusi, karena irisan yang sesuai ditempatkan pada node komputasi. Anda biasanya hanya memiliki satu langkah DS_DIST_NONE, gabungan antara tabel fakta dan satu tabel dimensi.

DS_DIST_ALL_NONE

Tidak diperlukan redistribusi, karena tabel gabungan bagian dalam menggunakan DISTSTYLE ALL. Seluruh tabel terletak di setiap node.

DS_DIST_INNER

Meja bagian dalam didistribusikan kembali.

DS_DIST_OUTER

Tabel luar didistribusikan kembali.

DS_BCAST_INNER

Salinan seluruh tabel bagian dalam disiarkan ke semua node komputasi.

DS_DIST_ALL_INNER

Seluruh tabel bagian dalam didistribusikan kembali ke satu irisan karena tabel luar menggunakan DISTSTYLE ALL.

DS_DIST_KEDUANYA

Kedua tabel didistribusikan kembali.

DS_DIST_NONE dan DS_DIST_ALL_NONE bagus. Mereka menunjukkan bahwa tidak ada distribusi yang diperlukan untuk langkah itu karena semua gabungan ditempatkan.

DS_DIST_INNER berarti bahwa langkah tersebut mungkin memiliki biaya yang relatif tinggi karena tabel bagian dalam didistribusikan kembali ke node. DS_DIST_INNER menunjukkan bahwa tabel luar sudah didistribusikan dengan benar pada kunci gabungan. Atur kunci distribusi tabel bagian dalam ke kunci gabungan untuk mengonversinya menjadi DS_DIST_NONE. Dalam beberapa kasus, mendistribusikan tabel bagian dalam pada kunci gabungan tidak dimungkinkan karena tabel luar tidak didistribusikan pada kunci gabungan. Jika ini masalahnya, evaluasi apakah akan menggunakan distribusi ALL untuk tabel bagian dalam. Jika tabel tidak sering diperbarui atau ekstensif, dan cukup besar untuk membawa biaya redistribusi yang tinggi, ubah gaya distribusi menjadi ALL dan uji lagi. Semua distribusi menyebabkan peningkatan waktu muat, jadi ketika Anda menguji ulang, sertakan waktu muat dalam faktor evaluasi Anda.

DS_DIST_ALL_INNER tidak bagus. Ini berarti bahwa seluruh tabel bagian dalam didistribusikan kembali ke satu irisan karena tabel luar menggunakan DISTYLE ALL, sehingga salinan dari seluruh tabel luar terletak di setiap node. Ini menghasilkan runtime serial yang tidak efisien dari gabungan pada satu node, alih-alih memanfaatkan runtime paralel menggunakan semua node. DISTSTYLE ALL dimaksudkan untuk digunakan hanya untuk tabel gabungan bagian dalam. Sebagai gantinya, tentukan kunci distribusi atau gunakan distribusi genap untuk tabel luar.

DS_BCAST_INNER dan DS_DIST_BOTH tidak bagus. Biasanya redistribusi ini terjadi karena tabel tidak bergabung pada kunci distribusinya. Jika tabel fakta belum memiliki kunci distribusi, tentukan kolom penggabungan sebagai kunci distribusi untuk kedua tabel. Jika tabel fakta sudah memiliki kunci distribusi di kolom lain, evaluasi apakah mengubah kunci distribusi untuk mengkolokasi gabungan ini meningkatkan kinerja keseluruhan. Jika mengubah kunci distribusi tabel luar bukanlah pilihan yang optimal, Anda dapat mencapai kolokasi dengan menentukan DISTYLE ALL untuk tabel bagian dalam.

Contoh berikut menunjukkan sebagian dari rencana query dengan label DS_BCAST_INNER dan DS_DIST_NONE.

-> XN Hash Join DS_BCAST_INNER (cost=112.50..3272334142.59 rows=170771 width=84) Hash Cond: ("outer".venueid = "inner".venueid) -> XN Hash Join DS_BCAST_INNER (cost=109.98..3167290276.71 rows=172456 width=47) Hash Cond: ("outer".eventid = "inner".eventid) -> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30) Merge Cond: ("outer".listid = "inner".listid) -> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)

Setelah mengubah tabel dimensi untuk menggunakan DISTSTYLE ALL, rencana kueri untuk kueri yang sama menunjukkan DS_DIST_ALL_NONE sebagai pengganti DS_BCAST_INNER. Juga, ada perubahan dramatis dalam biaya relatif untuk langkah-langkah bergabung. Total biaya 14142.59 dibandingkan 3272334142.59 dengan permintaan sebelumnya.

-> XN Hash Join DS_DIST_ALL_NONE (cost=112.50..14142.59 rows=170771 width=84) Hash Cond: ("outer".venueid = "inner".venueid) -> XN Hash Join DS_DIST_ALL_NONE (cost=109.98..10276.71 rows=172456 width=47) Hash Cond: ("outer".eventid = "inner".eventid) -> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30) Merge Cond: ("outer".listid = "inner".listid) -> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)