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

Menganalisis tabel

ANALYZEOperasi memperbarui metadata statistik yang digunakan perencana kueri untuk memilih paket yang optimal.

Dalam kebanyakan kasus, Anda tidak perlu menjalankan perintah secara eksplisit. ANALYZE Amazon Redshift memantau perubahan pada beban kerja Anda dan secara otomatis memperbarui statistik di latar belakang. Selain itu, COPY perintah melakukan analisis secara otomatis ketika memuat data ke dalam tabel kosong.

Untuk secara eksplisit menganalisis tabel atau seluruh database, jalankan perintah. ANALYZE

Analisis otomatis

Amazon Redshift terus memantau database Anda dan secara otomatis melakukan operasi analisis di latar belakang. Untuk meminimalkan dampak terhadap kinerja sistem Anda, analisis otomatis berjalan selama periode ketika beban kerja ringan.

Analisis otomatis diaktifkan secara default. Untuk menonaktifkan analisis otomatis, atur auto_analyze parameter false dengan memodifikasi grup parameter cluster Anda.

Untuk mengurangi waktu pemrosesan dan meningkatkan kinerja sistem secara keseluruhan, Amazon Redshift melewatkan analisis otomatis untuk tabel mana pun yang tingkat modifikasinya kecil.

Operasi analisis melewatkan tabel yang memiliki up-to-date statistik. Jika Anda menjalankan ANALYZE sebagai bagian dari alur kerja ekstrak, transformasi, dan beban (ETL), analisis otomatis melewatkan tabel yang memiliki statistik saat ini. Demikian pula, eksplisit ANALYZE melewatkan tabel ketika analisis otomatis telah memperbarui statistik tabel.

Analisis data tabel baru

Secara default, COPY perintah melakukan ANALYZE setelah memuat data ke dalam tabel kosong. Anda dapat memaksa ANALYZE terlepas dari apakah tabel kosong dengan mengatur STATUPDATE ON. Jika Anda menentukan STATUPDATEOFF, ANALYZE tidak dilakukan. Hanya pemilik tabel atau superuser yang dapat menjalankan ANALYZE perintah atau menjalankan COPY perintah dengan STATUPDATE disetel ke ON.

Amazon Redshift juga menganalisis tabel baru yang Anda buat dengan perintah berikut:

Amazon Redshift mengembalikan pesan peringatan saat Anda menjalankan kueri terhadap tabel baru yang tidak dianalisis setelah datanya awalnya dimuat. Tidak ada peringatan yang terjadi saat Anda menanyakan tabel setelah pembaruan atau pemuatan berikutnya. Pesan peringatan yang sama dikembalikan saat Anda menjalankan EXPLAIN perintah pada kueri yang mereferensikan tabel yang belum dianalisis.

Setiap kali menambahkan data ke tabel nonempty secara signifikan mengubah ukuran tabel, Anda dapat secara eksplisit memperbarui statistik. Anda melakukannya baik dengan menjalankan ANALYZE perintah atau dengan menggunakan opsi STATUPDATE ON dengan COPY perintah. Untuk melihat detail tentang jumlah baris yang telah disisipkan atau dihapus sejak yang terakhirANALYZE, kueri tabel katalog PG_STATISTIC_INDICATOR sistem.

Anda dapat menentukan ruang lingkup ANALYZE perintah ke salah satu dari berikut ini:

ANALYZEPerintah mendapatkan sampel baris dari tabel, melakukan beberapa perhitungan, dan menyimpan statistik kolom yang dihasilkan. Secara default, Amazon Redshift menjalankan pass sampel untuk DISTKEY kolom dan pass sampel lain untuk semua kolom lain dalam tabel. Jika Anda ingin menghasilkan statistik untuk subset kolom, Anda dapat menentukan daftar kolom yang dipisahkan koma. Anda dapat menjalankan ANALYZE dengan PREDICATE COLUMNS klausa untuk melewati kolom yang tidak digunakan sebagai predikat.

ANALYZEoperasi intensif sumber daya, jadi jalankan hanya pada tabel dan kolom yang benar-benar memerlukan pembaruan statistik. Anda tidak perlu menganalisis semua kolom di semua tabel secara teratur atau pada jadwal yang sama. Jika data berubah secara substansif, analisis kolom yang sering digunakan sebagai berikut:

Untuk mengurangi waktu pemrosesan dan meningkatkan kinerja sistem secara keseluruhan, Amazon Redshift melompati ANALYZE tabel apa pun yang memiliki persentase baris yang diubah rendah, sebagaimana ditentukan oleh parameter. analyze_threshold_percent Secara default, ambang analisis diatur ke 10 persen. Anda dapat mengubah ambang analisis untuk sesi saat ini dengan menjalankan SET perintah.

Kolom yang cenderung tidak memerlukan analisis yang sering adalah kolom yang mewakili fakta dan ukuran dan atribut terkait apa pun yang tidak pernah benar-benar ditanyakan, seperti VARCHAR kolom besar. Misalnya, perhatikan LISTING tabel dalam TICKIT database.

select "column", type, encoding, distkey, sortkey
from pg_table_def where tablename = 'listing';


column         |        type        | encoding | distkey | sortkey 
---------------+--------------------+----------+---------+---------
listid         | integer            | none     | t       | 1       
sellerid       | integer            | none     | f       | 0       
eventid        | integer            | mostly16 | f       | 0       
dateid         | smallint           | none     | f       | 0       
numtickets     | smallint           | mostly8  | f       | 0       
priceperticket | numeric(8,2)       | bytedict | f       | 0       
totalprice     | numeric(8,2)       | mostly32 | f       | 0       
listtime       | timestamp with...  | none     | f       | 0       

Jika tabel ini dimuat setiap hari dengan sejumlah besar catatan baru, LISTID kolom, yang sering digunakan dalam kueri sebagai kunci gabungan, harus dianalisis secara teratur. Jika TOTALPRICE dan LISTTIME merupakan kendala yang sering digunakan dalam kueri, Anda dapat menganalisis kolom tersebut dan kunci distribusi setiap hari kerja.

analyze listing(listid, totalprice, listtime);

Misalkan penjual dan acara dalam aplikasi jauh lebih statis, dan tanggalnya IDs mengacu pada serangkaian hari tetap yang hanya mencakup dua atau tiga tahun. Dalam hal ini, nilai unik untuk kolom ini tidak berubah secara signifikan. Namun, jumlah contoh dari setiap nilai unik akan terus meningkat.

Selain itu, pertimbangkan kasus di mana NUMTICKETS dan PRICEPERTICKET ukuran jarang ditanyakan dibandingkan dengan kolom. TOTALPRICE Dalam hal ini, Anda dapat menjalankan ANALYZE perintah di seluruh tabel sekali setiap akhir pekan untuk memperbarui statistik untuk lima kolom yang tidak dianalisis setiap hari:

Kolom predikat

Sebagai alternatif yang nyaman untuk menentukan daftar kolom, Anda dapat memilih untuk menganalisis hanya kolom yang kemungkinan akan digunakan sebagai predikat. Saat Anda menjalankan kueri, kolom apa pun yang digunakan dalam gabungan, kondisi filter, atau grup berdasarkan klausa ditandai sebagai kolom predikat dalam katalog sistem. Ketika Anda menjalankan ANALYZE dengan PREDICATE COLUMNS klausa, operasi analisis hanya mencakup kolom yang memenuhi kriteria berikut:

Jika tidak ada kolom tabel yang ditandai sebagai predikat, ANALYZE termasuk semua kolom, bahkan ketika PREDICATE COLUMNS ditentukan. Jika tidak ada kolom yang ditandai sebagai kolom predikat, mungkin karena tabel belum ditanyakan.

Anda dapat memilih untuk menggunakan PREDICATE COLUMNS ketika pola kueri beban kerja Anda relatif stabil. Ketika pola kueri bervariasi, dengan kolom yang berbeda sering digunakan sebagai predikat, penggunaan PREDICATE COLUMNS mungkin untuk sementara menghasilkan statistik basi. Statistik basi dapat menyebabkan rencana runtime kueri suboptimal dan runtime yang lama. Namun, saat berikutnya Anda menjalankan ANALYZE menggunakan PREDICATECOLUMNS, kolom predikat baru disertakan.

Untuk melihat detail kolom predikat, gunakan yang berikut ini SQL untuk membuat tampilan bernama PREDICATE _COLUMNS.

CREATE VIEW predicate_columns AS
WITH predicate_column_info as (
SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num,  a.attname as col_name,
        CASE
            WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') 
            WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||')
            WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||')
            WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||')
            ELSE NULL::varchar
        END AS pred_ts
   FROM pg_statistic s
   JOIN pg_class c ON c.oid = s.starelid
   JOIN pg_namespace ns ON c.relnamespace = ns.oid
   JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum)
SELECT schema_name, table_name, col_num, col_name,
       pred_ts NOT LIKE '2000-01-01%' AS is_predicate,
       CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use,
       CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze
FROM predicate_column_info;

Misalkan Anda menjalankan query berikut terhadap LISTING tabel. Perhatikan bahwaLISTID,LISTTIME, dan EVENTID digunakan dalam klausa join, filter, dan group by.

select s.buyerid,l.eventid, sum(l.totalprice)
from listing l
join sales s on l.listid = s.listid
where l.listtime > '2008-12-01'
group by l.eventid, s.buyerid;

Saat Anda menanyakan COLUMNS tampilan PREDICATE _, seperti yang ditunjukkan pada contoh berikut, Anda melihatnyaLISTID,EVENTID, dan LISTTIME ditandai sebagai kolom predikat.

select * from predicate_columns 
where table_name = 'listing';

schema_name | table_name | col_num | col_name       | is_predicate | first_predicate_use | last_analyze       
------------+------------+---------+----------------+--------------+---------------------+--------------------
public      | listing    |       1 | listid         | true         | 2017-05-05 19:27:59 | 2017-05-03 18:27:41
public      | listing    |       2 | sellerid       | false        |                     | 2017-05-03 18:27:41
public      | listing    |       3 | eventid        | true         | 2017-05-16 20:54:32 | 2017-05-03 18:27:41
public      | listing    |       4 | dateid         | false        |                     | 2017-05-03 18:27:41
public      | listing    |       5 | numtickets     | false        |                     | 2017-05-03 18:27:41
public      | listing    |       6 | priceperticket | false        |                     | 2017-05-03 18:27:41
public      | listing    |       7 | totalprice     | false        |                     | 2017-05-03 18:27:41
public      | listing    |       8 | listtime       | true         | 2017-05-16 20:54:32 | 2017-05-03 18:27:41

Menjaga statistik terkini meningkatkan kinerja kueri dengan memungkinkan perencana kueri untuk memilih paket yang optimal. Amazon Redshift menyegarkan statistik secara otomatis di latar belakang, dan Anda juga dapat menjalankan perintah secara eksplisit. ANALYZE Jika Anda memilih untuk menjalankan secara eksplisitANALYZE, lakukan hal berikut:

Anda tidak perlu menjalankan ANALYZE perintah secara eksplisit setelah memulihkan snapshot ke cluster yang disediakan atau namespace tanpa server, atau setelah melanjutkan cluster penyediaan yang dijeda. Amazon Redshift menyimpan informasi tabel sistem dalam kasus ini, membuat perintah manual ANALYZE tidak diperlukan. Amazon Redshift akan terus menjalankan operasi analisis otomatis sesuai kebutuhan.

Operasi analisis melewatkan tabel yang memiliki up-to-date statistik. Jika Anda menjalankan ANALYZE sebagai bagian dari alur kerja ekstrak, transformasi, dan beban (ETL), analisis otomatis melewatkan tabel yang memiliki statistik saat ini. Demikian pula, eksplisit ANALYZE melewatkan tabel ketika analisis otomatis telah memperbarui statistik tabel.

ANALYZEsejarah perintah

Ini berguna untuk mengetahui kapan ANALYZE perintah terakhir dijalankan pada tabel atau database. Saat ANALYZE perintah dijalankan, Amazon Redshift menjalankan beberapa kueri yang terlihat seperti ini:

padb_fetch_sample: select * from table_name
               

Query STL _ ANALYZE untuk melihat riwayat operasi analisis. Jika Amazon Redshift menganalisis tabel menggunakan analisis otomatis, is_background kolom disetel ke t (true). Jika tidak, itu diatur ke f (false). Contoh berikut bergabung dengan STV _ TBL _ PERM untuk menunjukkan nama tabel dan rincian runtime.

select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, a.starttime, a.endtime
from stl_analyze a 
join stv_tbl_perm t  on t.id=a.table_id
where name = 'users'
order by starttime;


xid    | name  | status          | rows  | modified_rows | starttime           | endtime            
-------+-------+-----------------+-------+---------------+---------------------+--------------------
  1582 | users | Full            | 49990 |         49990 | 2016-09-22 22:02:23 | 2016-09-22 22:02:28
244287 | users | Full            | 24992 |         74988 | 2016-10-04 22:50:58 | 2016-10-04 22:51:01
244712 | users | Full            | 49984 |         24992 | 2016-10-04 22:56:07 | 2016-10-04 22:56:07
245071 | users | Skipped         | 49984 |             0 | 2016-10-04 22:58:17 | 2016-10-04 22:58:17
245439 | users | Skipped         | 49984 |          1982 | 2016-10-04 23:00:13 | 2016-10-04 23:00:13
(5 rows)

Atau, Anda dapat menjalankan kueri yang lebih kompleks yang mengembalikan semua pernyataan yang berjalan di setiap transaksi selesai yang menyertakan ANALYZE perintah:

select xid, to_char(starttime, 'HH24:MM:SS.MS') as starttime,
datediff(sec,starttime,endtime ) as secs, substring(text, 1, 40)
from svl_statementtext
where sequence = 0
and xid in (select xid from svl_statementtext s where s.text like 'padb_fetch_sample%' )
order by xid desc, starttime;

xid  |  starttime   | secs |                  substring
-----+--------------+------+------------------------------------------
1338 | 12:04:28.511 |    4 | Analyze date
1338 | 12:04:28.511 |    1 | padb_fetch_sample: select count(*) from
1338 | 12:04:29.443 |    2 | padb_fetch_sample: select * from date
1338 | 12:04:31.456 |    1 | padb_fetch_sample: select * from date
1337 | 12:04:24.388 |    1 | padb_fetch_sample: select count(*) from
1337 | 12:04:24.388 |    4 | Analyze sales
1337 | 12:04:25.322 |    2 | padb_fetch_sample: select * from sales
1337 | 12:04:27.363 |    1 | padb_fetch_sample: select * from sales
...