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 NONE

Tidak diperlukan redistribusi, karena irisan yang sesuai ditempatkan pada node komputasi. Anda biasanya hanya memiliki satu NONE langkah DIST DS_ _, penggabungan antara tabel fakta dan satu tabel dimensi.

DS_ _ DIST _ ALL NONE

Tidak diperlukan redistribusi, karena tabel gabungan bagian dalam digunakan DISTSTYLEALL. 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 DISTSTYLEALL.

DS_ _ DIST BOTH

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. Setel 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 ALL distribusi untuk tabel bagian dalam. Jika tabel tidak sering diperbarui atau ekstensif, dan cukup besar untuk membawa biaya redistribusi yang tinggi, ubah gaya distribusi ALL dan uji lagi. ALLdistribusi menyebabkan peningkatan waktu muat, jadi ketika Anda menguji ulang, sertakan waktu muat dalam faktor evaluasi Anda.

DS_ DIST _ ALL _ INNER tidak baik. Ini berarti bahwa seluruh tabel bagian dalam didistribusikan kembali ke satu irisan karena tabel luar menggunakan DISTSTYLEALL, sehingga salinan dari seluruh tabel luar terletak pada setiap node. Ini menghasilkan runtime serial yang tidak efisien dari gabungan pada satu node, alih-alih memanfaatkan runtime paralel menggunakan semua node. DISTSTYLEALLdimaksudkan 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 _ tidak BOTH 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 DISTSTYLE ALL tabel bagian dalam.

Contoh berikut menunjukkan sebagian dari rencana kueri 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 yang akan digunakan DISTSTYLEALL, 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)