Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Aurora DSQL dan PostgreSQL
Aurora DSQL adalah database relasional terdistribusi yang kompatibel dengan PostgreSQL yang dirancang untuk beban kerja transaksional. Aurora DSQL menggunakan komponen PostgreSQL inti seperti parser, planner, optimizer, dan sistem tipe.
Desain Aurora DSQL memastikan bahwa semua sintaks PostgreSQL yang didukung memberikan perilaku yang kompatibel dan menghasilkan hasil kueri yang identik. Misalnya, Aurora DSQL menyediakan konversi tipe, operasi aritmatika, dan presisi numerik dan skala yang identik dengan PostgreSQL. Setiap penyimpangan didokumentasikan.
Aurora DSQL juga memperkenalkan kemampuan canggih seperti kontrol konkurensi optimis dan manajemen skema terdistribusi. Dengan fitur-fitur ini, Anda dapat menggunakan perkakas PostgreSQL yang sudah dikenal sambil memanfaatkan kinerja dan skalabilitas aplikasi terdistribusi modern, cloud-native.
## Sorotan kompatibilitas PostgreSQL
Aurora DSQL saat ini didasarkan pada PostgreSQL versi 16. Sorotan utama meliputi yang berikut:
**Protokol kawat**
Aurora DSQL menggunakan protokol kabel PostgreSQL v3 standar. Ini memungkinkan integrasi dengan klien PostgreSQL standar, driver, dan alat. Misalnya, Aurora DSQL kompatibel dengan`psql`,, dan. `pgjdbc` `psycopg`
**Sintaks SQL**
Aurora DSQL mendukung berbagai ekspresi dan fungsi PostgreSQL standar yang biasa digunakan dalam beban kerja transaksional. Ekspresi SQL yang didukung menghasilkan hasil yang identik dengan PostgreSQL, termasuk yang berikut:
+ Penanganan nol
+ Urutkan perilaku urutan
+ Skala dan presisi untuk operasi numerik
+ Kesetaraan untuk operasi string
Untuk informasi selengkapnya, lihat [Kompatibilitas fitur SQL di Aurora DSQL](working-with-postgresql-compatibility.md).
**Manajemen transaksi**
Aurora DSQL mempertahankan karakteristik utama PostgreSQL, seperti transaksi ACID dan tingkat isolasi yang setara dengan PostgreSQL Repeatable Read. Untuk informasi selengkapnya, lihat [Kontrol konkurensi di Aurora DSQL](working-with-concurrency-control.md).
## Manfaat arsitektur terdistribusi
Desain Aurora DSQL yang terdistribusi dan tidak dibagikan memberikan manfaat kinerja dan skalabilitas di luar basis data simpul tunggal tradisional. Kemampuan utama meliputi:
**Kontrol Konkurensi Optimis (OCC)**
Aurora DSQL menggunakan model kontrol konkurensi yang optimis. Pendekatan bebas kunci ini mencegah transaksi memblokir satu sama lain, menghilangkan kebuntuan, dan memungkinkan eksekusi paralel throughput tinggi. Fitur-fitur ini membuat Aurora DSQL sangat berharga untuk aplikasi yang membutuhkan kinerja yang konsisten pada skala besar. Untuk contoh lebih lanjut, lihat[Kontrol konkurensi di Aurora DSQL](working-with-concurrency-control.md).
**Operasi DDL asinkron**
Aurora DSQL menjalankan operasi DDL secara asinkron, yang memungkinkan pembacaan dan penulisan tanpa gangguan selama perubahan skema. Arsitektur terdistribusi memungkinkan Aurora DSQL untuk melakukan tindakan berikut:
+ Jalankan operasi DDL sebagai tugas latar belakang, meminimalkan gangguan.
+ Mengkoordinasikan perubahan katalog sebagai transaksi terdistribusi yang sangat konsisten. Ini memastikan visibilitas atom di semua node, bahkan selama kegagalan atau operasi bersamaan.
+ Beroperasi dengan cara yang terdistribusi penuh dan tanpa pemimpin di beberapa Availability Zone dengan lapisan komputasi dan penyimpanan terpisah.
Untuk lebih lanjut tentang menggunakan perintah EXPLORE di PostgreSQL, lihat. [DDL dan transaksi terdistribusi di Aurora DSQL](working-with-ddl.md)
# Kompatibilitas fitur SQL di Aurora DSQL
Pada bagian berikut, pelajari tentang dukungan Aurora DSQL untuk tipe data PostgreSQL dan perintah SQL.
**Topics**
+ [Tipe data yang didukung di Aurora DSQL](working-with-postgresql-compatibility-supported-data-types.md)
+ [SQL yang didukung untuk Aurora DSQL](working-with-postgresql-compatibility-supported-sql-features.md)
+ [Subset yang didukung dari perintah SQL di Aurora DSQL](working-with-postgresql-compatibility-supported-sql-subsets.md)
+ [Migrasi dari PostgreSQL ke Aurora DSQL](working-with-postgresql-compatibility-migration-guide.md)
# Tipe data yang didukung di Aurora DSQL
Aurora DSQL mendukung subset dari jenis PostgreSQL umum.
**Topics**
+ [Jenis data numerik](#numeric-data-types)
+ [Tipe data karakter](#character-data-types)
+ [Jenis data tanggal dan waktu](#date-time-data-types)
+ [Jenis data lain-lain](#miscellaneous-data-types)
+ [Jenis data runtime kueri](#working-with-postgresql-compatibility-query-runtime)
## Jenis data numerik
Aurora DSQL mendukung tipe data numerik PostgreSQL berikut.
| Nama | Alias | Rentang dan presisi | Ukuran penyimpanan | Dukungan indeks |
| --- | --- | --- | --- | --- |
| smallint | int2 | -32768 ke \$132767 | 2 byte | Ya |
| `integer` | `int`, `int4` | -2147483648 ke \$12147483647 | 4 byte | Ya |
| `bigint` | `int8` | -9223372036854775808 ke \$19223372036854775807 | 8 byte | Ya |
| `real` | `float4` | 6 digit desimal presisi | 4 byte | Ya |
| `double precision` | `float8` | 15 digit desimal presisi | 8 byte | Ya |
| `numeric` [ `(`*p*, *s*`)` ] | `decimal` [ `(`*p*, *s*`)` ] `dec`[ `(`*p*,*s*`)`] | Numerik yang tepat dari presisi yang dapat dipilih. Presisi maksimum adalah 38 dan skala maksimum adalah 37. 1 Defaultnya adalah`numeric (18,6)`. | 8 byte\$12 byte per digit presisi. Ukuran maksimum adalah 27 byte. | Ya |
1— Jika Anda tidak secara eksplisit menentukan ukuran saat Anda menjalankan `CREATE TABLE` atau, `ALTER TABLE ADD COLUMN` Aurora DSQL memberlakukan default. Aurora DSQL menerapkan batasan saat Anda menjalankan atau pernyataan. `INSERT` `UPDATE`
## Tipe data karakter
Aurora DSQL mendukung tipe data karakter PostgreSQL berikut.
| Nama | Alias | Deskripsi | Batas Aurora DSQL | Ukuran penyimpanan | Dukungan indeks |
| --- | --- | --- | --- | --- | --- |
| `character` [ `(`*n*`)` ] | `char` [ `(`*n*`)` ] | String karakter dengan panjang tetap | 4096 byte 1 | Variabel hingga 4100 byte | Ya |
| `character varying` [ `(`*n*`)` ] | `varchar` [ `(`*n*`)` ] | String karakter panjang variabel | 65535 byte 1 | Variabel hingga 65539 byte | Ya |
| `bpchar` [ `(`*n*`)` ] | | Jika panjang tetap, ini adalah alias untuk`char`. Jika panjang variabel, ini adalah alias untuk`varchar`, di mana spasi tambahan secara semantik tidak signifikan. | 4096 byte 1 | Variabel hingga 4100 byte | Ya |
| `text` | | String karakter panjang variabel | 1 MiB 1 | Variabel hingga 1 MiB | Ya |
1— Jika Anda tidak secara eksplisit menentukan ukuran ketika Anda menjalankan `CREATE TABLE` atau`ALTER TABLE ADD COLUMN`, maka Aurora DSQL memberlakukan default. Aurora DSQL menerapkan batasan saat Anda menjalankan atau pernyataan. `INSERT` `UPDATE`
## Jenis data tanggal dan waktu
Aurora DSQL mendukung tipe data tanggal dan waktu PostgreSQL berikut.
| Nama | Alias | Deskripsi | Kisaran | Resolusi | Ukuran penyimpanan | Dukungan indeks |
| --- | --- | --- | --- | --- | --- | --- |
| `date` | | Tanggal kalender (tahun, bulan, hari) | 4713 SM — 5874897 IKLAN | 1 hari | 4 byte | Ya |
| `time` [ `(`*p*`)` ] [ `without time zone` ] | `timestamp` | Waktu hari, tanpa zona waktu | 0 — 1 | 1 mikrodetik | 8 byte | Ya |
| `time` [ `(`*p*`)` ] `with time zone` | `timetz` | waktu hari, termasuk zona waktu | 00:00:00 \$11559 — 24:00:00 —1559 | 1 mikrodetik | 12 byte | Tidak |
| `timestamp` [ `(`*p*`)` ] [ `without time zone` ] | | Tanggal dan waktu, tanpa zona waktu | 4713 SM — 294276 IKLAN | 1 mikrodetik | 8 byte | Ya |
| `timestamp` [ `(`*p*`)` ] `with time zone` | `timestamptz` | Tanggal dan waktu, termasuk zona waktu | 4713 SM — 294276 IKLAN | 1 mikrodetik | 8 byte | Ya |
| `interval` [ `fields` ] [ `(`*p*`)` ] | | Rentang waktu | -178000000 tahun — 178000000 tahun | 1 mikrodetik | 16 byte | Tidak |
## Jenis data lain-lain
Aurora DSQL mendukung berbagai jenis data PostgreSQL berikut.
| Nama | Alias | Deskripsi | Batas Aurora DSQL | Ukuran penyimpanan | Dukungan indeks |
| --- | --- | --- | --- | --- | --- |
| `boolean` | `bool` | Logis Boolean (benar/salah) | | 1 byte | Ya |
| `bytea` | | Data biner (“array byte”) | 1 MiB 1 | Variabel hingga batas 1 MiB | Tidak |
| `UUID` | | Pengidentifikasi unik secara universal | | 16 byte | Ya |
1— Jika Anda tidak secara eksplisit menentukan ukuran ketika Anda menjalankan `CREATE TABLE` atau`ALTER TABLE ADD COLUMN`, maka Aurora DSQL memberlakukan default. Aurora DSQL menerapkan batasan saat Anda menjalankan atau pernyataan. `INSERT` `UPDATE`
## Jenis data runtime kueri
Query tipe data runtime adalah tipe data internal yang digunakan pada waktu eksekusi query. Tipe ini berbeda dari tipe yang kompatibel dengan PostgreSQL seperti `varchar` dan `integer` yang Anda tentukan dalam skema Anda. Sebagai gantinya, jenis ini adalah representasi runtime yang digunakan Aurora DSQL saat memproses kueri.
Tipe data berikut hanya didukung selama runtime kueri:
**Jenis array**
Aurora DSQL mendukung array dari tipe data yang didukung. Misalnya, Anda dapat memiliki array bilangan bulat. Fungsi `string_to_array` membagi string ke dalam array gaya PostgreSQL dengan pembatas koma () `,` seperti yang ditunjukkan pada contoh berikut. Anda dapat menggunakan array dalam ekspresi, output fungsi, atau perhitungan sementara selama eksekusi kueri.
```
SELECT string_to_array('1,2', ',');
```
Fungsi mengembalikan respon yang mirip dengan berikut ini:
```
string_to_array
-----------------
{1,2}
(1 row)
```
****jenis inet****
Tipe data mewakili IPv4, alamat IPv6 host, dan subnetnya. Jenis ini berguna saat mengurai log, memfilter pada subnet IP, atau melakukan perhitungan jaringan dalam kueri. Untuk informasi selengkapnya, lihat [inet di dokumentasi PostgreSQL](https://www.PostgreSQL.org/docs/16/datatype-net-types.html#DATATYPE-INET).
**Fungsi runtime JSON**
Aurora DSQL mendukung JSON dan JSONB sebagai tipe data runtime untuk pemrosesan kueri. Simpan data JSON sebagai `text` kolom dan lemparkan ke JSON selama eksekusi kueri untuk menggunakan fungsi dan operator PostgreSQL JSON.
[Aurora DSQL mendukung sebagian besar fungsi PostgreSQL JSON dari bagian 9.1.6 Fungsi JSON dan Operator dengan perilaku yang identik.](https://www.postgresql.org/docs/current/functions-json.html)
Fungsi yang mengembalikan tipe JSON atau JSONB mungkin memerlukan casting tambahan `text` untuk tampilan yang tepat.
```
SELECT json_build_array(1, 2, 'foo', 4, 5)::text;
```
Fungsi mengembalikan respon yang mirip dengan berikut ini:
```
json_build_array
---------------------
[1, 2, "foo", 4, 5]
(1 row)
```
# SQL yang didukung untuk Aurora DSQL
Aurora DSQL mendukung berbagai fitur inti PostgreSQL SQL. Di bagian berikut, Anda dapat mempelajari tentang dukungan ekspresi PostgreSQL umum. Daftar ini bukanlah daftar lengkap.
## Perintah `SELECT`
Aurora DSQL mendukung klausul perintah berikut. `SELECT`
| Klausul utama | Klausul yang didukung |
| --- | --- |
| `FROM` | |
| `GROUP BY` | `ALL`, `DISTINCT` |
| `ORDER BY` | `ASC`, `DESC`, `NULLS` |
| `LIMIT` | |
| `DISTINCT` | |
| `HAVING` | |
| `USING` | |
| `WITH`(ekspresi tabel umum) | |
| `INNER JOIN` | `ON` |
| `OUTER JOIN` | `LEFT`, `RIGHT`, `FULL`, `ON` |
| `CROSS JOIN` | `ON` |
| `UNION` | `ALL` |
| `INTERSECT` | `ALL` |
| `EXCEPT` | `ALL` |
| `OVER` | `RANK ()`, `PARTITION BY` |
| `FOR UPDATE` | |
## Bahasa Definisi Data (DDL)
Aurora DSQL mendukung perintah PostgreSQL DDL berikut.
| Perintah | Klausul Utama | Klausul yang Didukung |
| --- | --- | --- |
| `CREATE` | `TABLE` | Untuk informasi tentang sintaks `CREATE TABLE` perintah yang didukung, lihat[`CREATE TABLE`](create-table-syntax-support.md). |
| `ALTER` | `TABLE` | Untuk informasi tentang sintaks `ALTER TABLE` perintah yang didukung, lihat[`ALTER TABLE`](alter-table-syntax-support.md). |
| `DROP` | `TABLE` | |
| `CREATE` | `[UNIQUE] INDEX ASYNC` | Anda dapat menggunakan perintah ini dengan parameter berikut:`ON`,`NULLS FIRST`,`NULLS LAST`. Untuk informasi tentang sintaks `CREATE INDEX ASYNC` perintah yang didukung, lihat[Indeks asinkron di Aurora DSQL](working-with-create-index-async.md). |
| `DROP` | `INDEX` | |
| `CREATE` | `VIEW` | Untuk informasi selengkapnya tentang sintaks `CREATE VIEW` perintah yang didukung, lihat[`CREATE VIEW`](create-view.md). |
| ALTER | VIEW | Untuk informasi tentang sintaks `ALTER VIEW` perintah yang didukung, lihat[`ALTER VIEW`](alter-view-syntax-support.md). |
| DROP | VIEW | Untuk informasi tentang sintaks DROP VIEW perintah yang didukung, lihat[`DROP VIEW`](drop-view-overview.md). |
| `CREATE` | `SEQUENCE` | Untuk informasi tentang sintaks `CREATE SEQUENCE` perintah yang didukung, lihat[`CREATE SEQUENCE`](create-sequence-syntax-support.md). |
| `ALTER` | `SEQUENCE` | Untuk informasi tentang sintaks `ALTER SEQUENCE` perintah yang didukung, lihat[`ALTER SEQUENCE`](alter-sequence-syntax-support.md). |
| `DROP` | `SEQUENCE` | Untuk informasi tentang sintaks `DROP SEQUENCE` perintah yang didukung, lihat[`DROP SEQUENCE`](drop-sequence-syntax-support.md). |
| `CREATE` | `ROLE`, `WITH` | |
| `CREATE` | `FUNCTION` | `LANGUAGE SQL` |
| `CREATE` | `DOMAIN` | |
## Bahasa Manipulasi Data (DML)
Aurora DSQL mendukung perintah PostgreSQL DHTML berikut.
| Perintah | Klausul utama | Klausul yang didukung |
| --- | --- | --- |
| `INSERT` | `INTO` | `VALUES`SELECT |
| `UPDATE` | `SET` | `WHERE (SELECT)` `FROM, WITH` |
| DELETE | FROM | USING, WHERE |
## Bahasa Kontrol Data (DCL)
Aurora DSQL mendukung perintah PostgreSQL DCL berikut.
| Perintah | Klausul yang didukung |
| --- | --- |
| `GRANT` | `ON`, `TO` |
| `REVOKE` | `ON`, `FROM`, `CASCADE`, `RESTRICT` |
## Bahasa Kontrol Transaksi (TCL)
Aurora DSQL mendukung perintah PostgreSQL TCL berikut.
| Perintah | Klausul yang didukung | Alias |
| --- | --- | --- |
| `COMMIT` | [`WORK` \$1 `TRANSACTION`] [`AND NO CHAIN`] | `END` |
| `BEGIN` | [`WORK` \$1 `TRANSACTION`] [`ISOLATION LEVEL REPEATABLE READ`] [`READ WRITE` \$1 `READ ONLY`] | |
| `START TRANSACTION` | [`ISOLATION LEVEL REPEATABLE READ`] [`READ WRITE` \$1 `READ ONLY`] | |
| `ROLLBACK` | [`WORK` \$1 `TRANSACTION`] [`AND NO CHAIN`] | `ABORT` |
## Perintah utilitas
Aurora DSQL mendukung perintah utilitas PostgreSQL berikut:
+ `EXPLAIN`
+ `ANALYZE`(nama relasi saja)
# Subset yang didukung dari perintah SQL di Aurora DSQL
Bagian ini memberikan informasi terperinci tentang perintah SQL yang didukung, dengan fokus pada perintah dengan set parameter dan subperintah yang luas. Misalnya, CREATE TABLE di PostgreSQL menawarkan banyak klausa dan parameter, subset yang didukung oleh Aurora DSQL. Bagian ini menjelaskan subset yang didukung dari perintah SQL umum menggunakan elemen sintaks PostgreSQL yang sudah dikenal yang didukung Aurora DSQL.
**Topics**
+ [`CREATE TABLE`](create-table-syntax-support.md)
+ [`ALTER TABLE`](alter-table-syntax-support.md)
+ [`CREATE SEQUENCE`](create-sequence-syntax-support.md)
+ [`ALTER SEQUENCE`](alter-sequence-syntax-support.md)
+ [`DROP SEQUENCE`](drop-sequence-syntax-support.md)
+ [`CREATE VIEW`](create-view.md)
+ [`ALTER VIEW`](alter-view-syntax-support.md)
+ [`DROP VIEW`](drop-view-overview.md)
# `CREATE TABLE`
`CREATE TABLE`mendefinisikan tabel baru.
```
CREATE TABLE [ IF NOT EXISTS ] table_name ( [
{ column_name data_type [ column_constraint [ ... ] ]
| table_constraint
| LIKE source_table [ like_option ... ] }
[, ... ]
] )
where column_constraint is:
[ CONSTRAINT constraint_name ]
{ NOT NULL |
NULL |
CHECK ( expression )|
DEFAULT default_expr |
GENERATED ALWAYS AS ( generation_expr ) STORED |
GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY ( sequence_options ) |
UNIQUE [ NULLS [ NOT ] DISTINCT ] index_parameters |
PRIMARY KEY index_parameters |
and table_constraint is:
[ CONSTRAINT constraint_name ]
{ CHECK ( expression ) |
UNIQUE [ NULLS [ NOT ] DISTINCT ] ( column_name [, ... ] ) index_parameters |
PRIMARY KEY ( column_name [, ... ] ) index_parameters |
and like_option is:
{ INCLUDING | EXCLUDING } { COMMENTS | CONSTRAINTS | DEFAULTS | GENERATED | IDENTITY | INDEXES | STATISTICS | ALL }
index_parameters in UNIQUE, and PRIMARY KEY constraints are:
[ INCLUDE ( column_name [, ... ] ) ]
```
## Kolom identitas
**catatan**
Saat menggunakan kolom identitas, nilai cache harus dipertimbangkan dengan cermat. Untuk informasi selengkapnya, lihat info penting di [`CREATE SEQUENCE`](create-sequence-syntax-support.md) halaman.
Untuk panduan tentang cara terbaik menggunakan kolom identitas berdasarkan pola beban kerja, lihat[Bekerja dengan urutan dan kolom identitas](sequences-identity-columns-working-with.md).
`GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY ( sequence_options )`Klausa membuat kolom sebagai *kolom identitas*. Ini akan memiliki urutan implisit yang melekat padanya dan di baris yang baru disisipkan kolom akan secara otomatis memiliki nilai dari urutan yang ditetapkan padanya. Kolom seperti itu secara implisit`NOT NULL`.
Klausa `ALWAYS` dan `BY DEFAULT` menentukan bagaimana nilai yang ditentukan pengguna secara eksplisit ditangani dan perintah. `INSERT` `UPDATE`
Dalam sebuah `INSERT` perintah, jika `ALWAYS` dipilih, nilai yang ditentukan pengguna hanya diterima jika `INSERT` pernyataan menentukan. `OVERRIDING SYSTEM VALUE` Jika `BY DEFAULT` dipilih, maka nilai yang ditentukan pengguna diutamakan.
Dalam sebuah `UPDATE` perintah, jika `ALWAYS` dipilih, setiap pembaruan kolom ke nilai apa pun selain `DEFAULT` akan ditolak. Jika `BY DEFAULT` dipilih, kolom dapat diperbarui secara normal. (Tidak ada `OVERRIDING` klausul untuk `UPDATE` perintah.)
*sequence\$1options*Klausa dapat digunakan untuk mengganti parameter urutan. Opsi yang tersedia termasuk yang ditampilkan untuk[`CREATE SEQUENCE`](create-sequence-syntax-support.md), plus`SEQUENCE NAME name`. Tanpa`SEQUENCE NAME`, sistem memilih nama yang tidak digunakan untuk urutan.
# `ALTER TABLE`
`ALTER TABLE`mengubah definisi tabel.
```
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
action [, ... ]
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
RENAME [ COLUMN ] column_name TO new_column_name
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
RENAME CONSTRAINT constraint_name TO new_constraint_name
ALTER TABLE [ IF EXISTS ] name
RENAME TO new_name
ALTER TABLE [ IF EXISTS ] name
SET SCHEMA new_schema
where action is one of:
ADD [ COLUMN ] [ IF NOT EXISTS ] column_name data_type
ALTER [ COLUMN ] column_name { SET GENERATED { ALWAYS | BY DEFAULT } | SET sequence_option | RESTART [ [ WITH ] restart ] } [...]
ALTER [ COLUMN ] column_name DROP IDENTITY [ IF EXISTS ]
OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
```
## Tindakan kolom identitas
**`SET GENERATED { ALWAYS | BY DEFAULT }` / `SET sequence_option` / `RESTART`**
Formulir ini mengubah apakah kolom adalah kolom identitas atau mengubah atribut generasi dari kolom identitas yang ada. Lihat [`CREATE TABLE`](create-table-syntax-support.md) untuk detail. Seperti`SET DEFAULT`, bentuk-bentuk ini hanya mempengaruhi perilaku berikutnya `INSERT` dan `UPDATE` perintah; mereka tidak menyebabkan baris yang sudah ada dalam tabel berubah.
*sequence\$1option*Ini adalah opsi yang didukung oleh [`ALTER SEQUENCE`](alter-sequence-syntax-support.md) seperti`INCREMENT BY`. Bentuk-bentuk ini mengubah urutan yang mendasari kolom identitas yang ada.
**`DROP IDENTITY [ IF EXISTS ]`**
Formulir ini menghapus properti identitas dari kolom. Jika `DROP IDENTITY IF EXISTS` ditentukan dan kolom bukan kolom identitas, tidak ada kesalahan yang dilemparkan. Dalam hal ini pemberitahuan dikeluarkan sebagai gantinya.
# `CREATE SEQUENCE`
`CREATE SEQUENCE`— tentukan generator urutan baru.
**penting**
Dalam PostgreSQL, `CACHE` menentukan adalah opsional dan default ke 1. Dalam sistem terdistribusi seperti Amazon Aurora DSQL, operasi urutan melibatkan koordinasi, dan ukuran cache 1 dapat meningkatkan overhead koordinasi di bawah konkurensi tinggi. Sementara nilai cache yang lebih besar memungkinkan nomor urut dilayani dari rentang yang telah dialokasikan secara lokal, meningkatkan throughput, nilai cadangan yang tidak digunakan dapat hilang, membuat kesenjangan dan efek pemesanan lebih terlihat. Karena aplikasi berbeda dalam sensitivitasnya terhadap pengurutan alokasi versus throughput, Amazon Aurora DSQL `CACHE` harus ditentukan secara eksplisit dan saat ini `CACHE = 1` mendukung `CACHE >= 65536` atau, memberikan perbedaan yang jelas antara perilaku alokasi yang lebih dekat dengan pembuatan sekuensial yang ketat dan alokasi yang dioptimalkan untuk beban kerja yang sangat bersamaan.
Kapan`CACHE >= 65536`, nilai urutan tetap dijamin unik tetapi mungkin tidak dihasilkan dalam urutan peningkatan yang ketat di seluruh sesi, dan kesenjangan dapat terjadi, terutama ketika nilai yang di-cache tidak sepenuhnya dikonsumsi. Karakteristik ini konsisten dengan semantik PostgreSQL untuk urutan yang di-cache dalam penggunaan bersamaan, di mana kedua sistem menjamin nilai yang berbeda tetapi tidak menjamin urutan urutan yang ketat di seluruh sesi.
Dalam satu sesi klien, nilai urutan mungkin tidak selalu tampak meningkat secara ketat, terutama transaksi eksplisit di luar. Perilaku ini mirip dengan penerapan PostgreSQL yang menggunakan penyatuan koneksi. Perilaku alokasi lebih dekat ke lingkungan PostgreSQL sesi tunggal dapat dicapai dengan menggunakan `CACHE = 1` atau dengan memperoleh nilai urutan dalam transaksi eksplisit.
Dengan`CACHE = 1`, alokasi urutan mengikuti perilaku urutan non-cache PostgreSQL.
Untuk panduan tentang cara terbaik menggunakan urutan berdasarkan pola beban kerja, lihat. [Bekerja dengan urutan dan kolom identitas](sequences-identity-columns-working-with.md)
## Sintaksis yang didukung
```
CREATE SEQUENCE [ IF NOT EXISTS ] name CACHE cache
[ AS data_type ]
[ INCREMENT [ BY ] increment ]
[ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
[ [ NO ] CYCLE ]
[ START [ WITH ] start ]
[ OWNED BY { table_name.column_name | NONE } ]
where data_type is BIGINT
and cache = 1 or cache >= 65536
```
## Deskripsi
`CREATE SEQUENCE`membuat generator nomor urut baru. Ini melibatkan pembuatan dan inisialisasi tabel baris tunggal khusus baru dengan nama. *name* Generator akan dimiliki oleh pengguna yang mengeluarkan perintah.
Jika nama skema diberikan maka urutan dibuat dalam skema yang ditentukan. Jika tidak, itu dibuat dalam skema saat ini. Nama urutan harus berbeda dari nama relasi lainnya (tabel, urutan, indeks, tampilan, tampilan terwujud, atau tabel asing) dalam skema yang sama.
Setelah urutan dibuat, Anda menggunakan fungsi`nextval`,`currval`, dan `setval` untuk beroperasi pada urutan. Fungsi-fungsi ini didokumentasikan dalam[Fungsi manipulasi urutan](sequence-functions-syntax-support.md).
Meskipun Anda tidak dapat memperbarui urutan secara langsung, Anda dapat menggunakan kueri seperti:
```
SELECT * FROM name;
```
untuk memeriksa beberapa parameter dan keadaan urutan saat ini. Secara khusus, `last_value` bidang urutan menunjukkan nilai terakhir yang dialokasikan oleh sesi apa pun. (Tentu saja, nilai ini mungkin sudah usang pada saat dicetak, jika sesi lain secara aktif melakukan `nextval` panggilan.) Parameter lain seperti *increment* dan *maxvalue* dapat diamati dalam `pg_sequences` tampilan.
## Parameter
**`IF NOT EXISTS`**
Jangan melempar kesalahan jika relasi dengan nama yang sama sudah ada. Pemberitahuan dikeluarkan dalam kasus ini. Perhatikan bahwa tidak ada jaminan bahwa relasi yang ada adalah sesuatu seperti urutan yang akan dibuat — bahkan mungkin bukan urutan.
***name***
Nama (opsional schema-qualified) dari urutan yang akan dibuat.
***data\$1type***
Klausa opsional `AS data_type` menentukan tipe data dari urutan. Jenis yang valid adalah`bigint`. `bigint`adalah default. Tipe data menentukan nilai minimum dan maksimum default dari urutan.
***increment***
Klausa opsional `INCREMENT BY increment` menentukan nilai yang ditambahkan ke nilai urutan saat ini untuk membuat nilai baru. Nilai positif akan membuat urutan naik, yang negatif menjadi urutan menurun. Nilai default adalah 1.
***minvalue* / `NO MINVALUE`**
Klausa opsional `MINVALUE minvalue` menentukan nilai minimum yang dapat dihasilkan oleh urutan. Jika klausa ini tidak disediakan atau `NO MINVALUE` ditentukan, maka default akan digunakan. Default untuk urutan naik adalah 1. Default untuk urutan menurun adalah nilai minimum tipe data.
***maxvalue* / `NO MAXVALUE`**
Klausa opsional `MAXVALUE maxvalue` menentukan nilai maksimum untuk urutan. Jika klausa ini tidak disediakan atau `NO MAXVALUE` ditentukan, maka nilai default akan digunakan. Default untuk urutan menaik adalah nilai maksimum tipe data. Default untuk urutan menurun adalah -1.
**`CYCLE` / `NO CYCLE`**
`CYCLE`Opsi ini memungkinkan urutan untuk membungkus ketika *maxvalue* atau *minvalue* telah dicapai oleh urutan naik atau turun masing-masing. Jika batas tercapai, nomor berikutnya yang dihasilkan akan menjadi *minvalue* atau*maxvalue*, masing-masing.
Jika `NO CYCLE` ditentukan, panggilan apa pun `nextval` setelah urutan mencapai nilai maksimumnya akan mengembalikan kesalahan. Jika tidak `NO CYCLE` ada `CYCLE` atau ditentukan, `NO CYCLE` adalah default.
***start***
Klausa opsional `START WITH start` memungkinkan urutan dimulai di mana saja. Nilai awal default adalah *minvalue* untuk urutan naik dan *maxvalue* untuk urutan turun.
***cache***
Klausa `CACHE cache` menentukan berapa banyak nomor urut yang akan dialokasikan sebelumnya dan disimpan dalam memori untuk akses yang lebih cepat. Nilai yang dapat diterima untuk `CACHE` Aurora DSQL adalah 1 atau nomor apa pun >= 65536. Nilai minimum adalah 1 (hanya satu nilai yang dapat dihasilkan pada satu waktu, artinya tidak ada cache).
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
`OWNED BY`Opsi ini menyebabkan urutan dikaitkan dengan kolom tabel tertentu, sehingga jika kolom itu (atau seluruh tabelnya) dijatuhkan, urutan akan secara otomatis turun juga. Tabel yang ditentukan harus memiliki pemilik yang sama dan berada dalam skema yang sama dengan urutannya. `OWNED BY NONE`, default, menentukan bahwa tidak ada asosiasi seperti itu.
## Catatan
Gunakan [`DROP SEQUENCE`](drop-sequence-syntax-support.md) untuk menghapus urutan.
Urutan didasarkan pada `bigint` aritmatika, sehingga kisarannya tidak dapat melebihi kisaran bilangan bulat delapan byte (-9223372036854775808 hingga 9223372036854775807).
Karena `nextval` dan `setval` panggilan tidak pernah diputar kembali, objek urutan tidak dapat digunakan jika penugasan nomor urut “tanpa celah” diperlukan.
Setiap sesi akan mengalokasikan dan menyimpan nilai urutan berturut-turut selama satu akses ke objek urutan dan meningkatkan objek urutan yang sesuai. `last_value` Kemudian, penggunaan *cache* -1 berikutnya dari `nextval` dalam sesi itu hanya mengembalikan nilai yang telah dialokasikan sebelumnya tanpa menyentuh objek urutan. Jadi, angka apa pun yang dialokasikan tetapi tidak digunakan dalam sesi akan hilang ketika sesi itu berakhir, menghasilkan “lubang” dalam urutan.
Selain itu, meskipun beberapa sesi dijamin untuk mengalokasikan nilai urutan yang berbeda, nilai mungkin dihasilkan di luar urutan ketika semua sesi dipertimbangkan. Misalnya, dengan *cache* pengaturan 10, sesi A mungkin mencadangkan nilai 1.. 10 dan kembali `nextval` = 1, maka sesi B mungkin mencadangkan nilai 11.. 20 dan kembali `nextval` = 11 sebelum sesi A dihasilkan `nextval` = 2. Jadi, dengan *cache* pengaturan satu, aman untuk mengasumsikan bahwa `nextval` nilai dihasilkan secara berurutan; dengan *cache* pengaturan yang lebih besar dari satu Anda hanya boleh berasumsi bahwa `nextval` nilainya semuanya berbeda, bukan bahwa mereka dihasilkan murni secara berurutan. Juga, `last_value` akan mencerminkan nilai terbaru yang dicadangkan oleh sesi apa pun, apakah itu belum dikembalikan oleh`nextval`.
Pertimbangan lain adalah bahwa `setval` eksekusi pada urutan seperti itu tidak akan diperhatikan oleh sesi lain sampai mereka menggunakan nilai yang telah dialokasikan sebelumnya yang telah mereka cache.
## Contoh
Buat urutan naik yang disebut`serial`, mulai dari 101:
```
CREATE SEQUENCE serial CACHE 65536 START 101;
```
Pilih nomor berikutnya dari urutan ini:
```
SELECT nextval('serial');
nextval
---------
101
```
Pilih nomor berikutnya dari urutan ini:
```
SELECT nextval('serial');
nextval
---------
102
```
Gunakan urutan ini dalam sebuah `INSERT` perintah:
```
INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
```
Setel ulang urutan ke nilai tertentu menggunakan`setval`:
```
SELECT setval('serial', 200);
SELECT nextval('serial');
nextval
---------
201
```
## Kompatibilitas
`CREATE SEQUENCE`sesuai dengan standar SQL, dengan pengecualian berikut:
+ Memperoleh nilai berikutnya dilakukan dengan menggunakan `nextval()` fungsi alih-alih `NEXT VALUE FOR` ekspresi standar.
+ `OWNED BY`Klausul ini adalah ekstensi PostgreSQL.
# `ALTER SEQUENCE`
`ALTER SEQUENCE`— mengubah definisi generator urutan.
**penting**
Saat menggunakan urutan, nilai cache harus dipertimbangkan dengan cermat. Untuk informasi selengkapnya, lihat info penting di [`CREATE SEQUENCE`](create-sequence-syntax-support.md) halaman.
Untuk panduan tentang cara terbaik menggunakan urutan berdasarkan pola beban kerja, lihat. [Bekerja dengan urutan dan kolom identitas](sequences-identity-columns-working-with.md)
## Sintaksis yang didukung
```
ALTER SEQUENCE [ IF EXISTS ] name
[ INCREMENT [ BY ] increment ]
[ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
[ [ NO ] CYCLE ]
[ START [ WITH ] start ]
[ RESTART [ [ WITH ] restart ] ]
[ CACHE cache ]
[ OWNED BY { table_name.column_name | NONE } ]
ALTER SEQUENCE [ IF EXISTS ] name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER SEQUENCE [ IF EXISTS ] name RENAME TO new_name
ALTER SEQUENCE [ IF EXISTS ] name SET SCHEMA new_schema
where cache is 1 or cache >= 65536
```
## Deskripsi
`ALTER SEQUENCE`mengubah parameter generator urutan yang ada. Parameter apa pun yang tidak secara khusus ditetapkan dalam `ALTER SEQUENCE` perintah mempertahankan pengaturan sebelumnya.
Anda harus memiliki urutan untuk digunakan`ALTER SEQUENCE`. Untuk mengubah skema urutan, Anda juga harus memiliki `CREATE` hak istimewa pada skema baru. Untuk mengubah pemilik, Anda harus `SET ROLE` dapat memiliki peran baru, dan peran itu harus memiliki `CREATE` hak istimewa pada skema urutan. (Pembatasan ini memberlakukan bahwa mengubah pemilik tidak melakukan apa pun yang tidak dapat Anda lakukan dengan menjatuhkan dan membuat ulang urutan. Namun, superuser dapat mengubah kepemilikan urutan apa pun.)
## Parameter
***name***
Nama (opsional schema-qualified) dari urutan yang akan diubah.
**`IF EXISTS`**
Jangan melempar kesalahan jika urutannya tidak ada. Pemberitahuan dikeluarkan dalam kasus ini.
***increment***
Klausul `INCREMENT BY increment` ini opsional. Nilai positif akan membuat urutan naik, yang negatif menjadi urutan menurun. Jika tidak ditentukan, nilai kenaikan lama akan dipertahankan.
***minvalue* / `NO MINVALUE`**
Klausa opsional `MINVALUE minvalue` menentukan nilai minimum yang dapat dihasilkan oleh urutan. Jika `NO MINVALUE` ditentukan, default 1 dan nilai minimum tipe data untuk urutan naik dan turun, masing-masing, akan digunakan. Jika tidak ada opsi yang ditentukan, nilai minimum saat ini akan dipertahankan.
***maxvalue* / `NO MAXVALUE`**
Klausa opsional `MAXVALUE maxvalue` menentukan nilai maksimum untuk urutan. Jika `NO MAXVALUE` ditentukan, default dari nilai maksimum tipe data dan -1 untuk urutan naik dan turun, masing-masing, akan digunakan. Jika tidak ada opsi yang ditentukan, nilai maksimum saat ini akan dipertahankan.
**`CYCLE`**
Kata `CYCLE` kunci opsional dapat digunakan untuk mengaktifkan urutan untuk membungkus ketika *maxvalue* atau *minvalue* telah dicapai oleh urutan naik atau turun masing-masing. Jika batas tercapai, nomor berikutnya yang dihasilkan akan menjadi *minvalue* atau*maxvalue*, masing-masing.
**`NO CYCLE`**
Jika kata `NO CYCLE` kunci opsional ditentukan, panggilan apa pun `nextval` setelah urutan mencapai nilai maksimumnya akan mengembalikan kesalahan. Jika tidak `NO CYCLE` ada `CYCLE` atau ditentukan, perilaku siklus lama akan dipertahankan.
***start***
Klausa opsional `START WITH start` mengubah nilai awal urutan yang direkam. Ini tidak berpengaruh pada nilai urutan saat ini; itu hanya menetapkan nilai yang akan digunakan `ALTER SEQUENCE RESTART` perintah future.
***restart***
Klausa opsional `RESTART [ WITH restart ]` mengubah nilai urutan saat ini. Ini mirip dengan memanggil `setval` fungsi dengan `is_called` =`false`: nilai yang ditentukan akan dikembalikan oleh panggilan berikutnya dari`nextval`. Menulis `RESTART` tanpa *restart* nilai setara dengan memasok nilai awal yang direkam oleh `CREATE SEQUENCE` atau terakhir ditetapkan oleh`ALTER SEQUENCE START WITH`.
Berbeda dengan `setval` panggilan, `RESTART` operasi pada urutan bersifat transaksional dan memblokir transaksi bersamaan dari mendapatkan nomor dari urutan yang sama. Jika itu bukan mode operasi yang diinginkan, `setval` harus digunakan.
***cache***
Klausul `CACHE cache` ini memungkinkan nomor urut untuk dialokasikan sebelumnya dan disimpan dalam memori untuk akses yang lebih cepat. Nilai harus berupa 1 atau beberapa nilai >= 65536. Jika tidak ditentukan, nilai cache lama akan dipertahankan. Untuk informasi selengkapnya tentang perilaku cache, lihat panduan di bawah[`CREATE SEQUENCE`](create-sequence-syntax-support.md).
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
`OWNED BY`Opsi ini menyebabkan urutan dikaitkan dengan kolom tabel tertentu, sehingga jika kolom itu (atau seluruh tabelnya) dijatuhkan, urutan akan secara otomatis turun juga. Jika ditentukan, asosiasi ini menggantikan asosiasi yang ditentukan sebelumnya untuk urutan tersebut. Tabel yang ditentukan harus memiliki pemilik yang sama dan berada dalam skema yang sama dengan urutannya. Menentukan `OWNED BY NONE` menghapus asosiasi yang ada, membuat urutan “berdiri bebas”.
***new\$1owner***
Nama pengguna dari pemilik baru urutan.
***new\$1name***
Nama baru untuk urutan.
***new\$1schema***
Skema baru untuk urutan.
## Catatan
`ALTER SEQUENCE`tidak akan segera mempengaruhi `nextval` hasil di backend, selain yang sekarang, yang memiliki nilai urutan yang telah dialokasikan sebelumnya (di-cache). Mereka akan menggunakan semua nilai yang di-cache sebelum memperhatikan parameter pembuatan urutan yang diubah. Backend saat ini akan segera terpengaruh.
`ALTER SEQUENCE`tidak mempengaruhi `currval` status untuk urutan.
`ALTER SEQUENCE`dapat menyebabkan transaksi lain ke OCC.
Untuk alasan historis, `ALTER TABLE` dapat digunakan dengan urutan juga; tetapi satu-satunya varian `ALTER TABLE` yang diizinkan dengan urutan setara dengan bentuk yang ditunjukkan di atas.
## Contoh
Mulai ulang urutan yang disebut`serial`, pada 105:
```
ALTER SEQUENCE serial RESTART WITH 105;
```
## Kompatibilitas
`ALTER SEQUENCE`sesuai dengan standar SQL, kecuali untuk,,,,`AS`, dan `SET SCHEMA` klausa `START WITH` `OWNED BY` `OWNER TO``RENAME TO`, yang merupakan ekstensi PostgreSQL.
# `DROP SEQUENCE`
`DROP SEQUENCE`— menghapus urutan.
## Sintaksis yang didukung
```
DROP SEQUENCE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## Deskripsi
`DROP SEQUENCE`menghapus generator nomor urut. Urutan hanya dapat dijatuhkan oleh pemiliknya atau superuser.
## Parameter
**`IF EXISTS`**
Jangan melempar kesalahan jika urutannya tidak ada. Pemberitahuan dikeluarkan dalam kasus ini.
***name***
Nama (opsional skema-kualifikasi) dari urutan.
**`CASCADE`**
Secara otomatis menjatuhkan objek yang bergantung pada urutan, dan pada gilirannya semua objek yang bergantung pada objek tersebut.
**`RESTRICT`**
Menolak untuk menjatuhkan urutan jika ada objek yang bergantung padanya. Ini adalah opsi default.
## Contoh
Untuk menghapus urutan`seq`:
```
DROP SEQUENCE seq;
```
## Kompatibilitas
`DROP SEQUENCE`sesuai dengan standar SQL, kecuali bahwa standar hanya memungkinkan satu urutan untuk dijatuhkan per perintah, dan terlepas dari `IF EXISTS` opsi, yang merupakan ekstensi PostgreSQL.
# `CREATE VIEW`
`CREATE VIEW`mendefinisikan pandangan persisten baru. Aurora DSQL tidak mendukung tampilan sementara; hanya tampilan permanen yang didukung.
## Sintaksis yang didukung
```
CREATE [ OR REPLACE ] [ RECURSIVE ] VIEW name [ ( column_name [, ...] ) ]
[ WITH ( view_option_name [= view_option_value] [, ... ] ) ]
AS query
[ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
```
## Deskripsi
`CREATE VIEW`mendefinisikan tampilan kueri. Pandangan itu tidak terwujud secara fisik. Sebagai gantinya, kueri dijalankan setiap kali tampilan direferensikan dalam kueri.
`CREATE or REPLACE VIEW`mirip, tetapi jika tampilan dengan nama yang sama sudah ada, itu diganti. Kueri baru harus menghasilkan kolom yang sama yang dihasilkan oleh kueri tampilan yang ada (yaitu, nama kolom yang sama dalam urutan yang sama dan dengan tipe data yang sama), tetapi mungkin menambahkan kolom tambahan ke akhir daftar. Perhitungan yang memunculkan kolom output mungkin berbeda.
Jika nama skema diberikan, seperti`CREATE VIEW myschema.myview ...`) maka tampilan dibuat dalam skema yang ditentukan. Jika tidak, itu dibuat dalam skema saat ini.
Nama tampilan harus berbeda dari nama relasi lainnya (tabel, indeks, tampilan) dalam skema yang sama.
## Parameter
`CREATE VIEW`mendukung berbagai parameter untuk mengontrol perilaku tampilan yang dapat diperbarui secara otomatis.
**`RECURSIVE`**
Menciptakan tampilan rekursif. Sintaks: `CREATE RECURSIVE VIEW [ schema . ] view_name (column_names) AS SELECT ...;` setara dengan. `CREATE VIEW [ schema . ] view_name AS WITH RECURSIVE view_name (column_names) AS (SELECT ...) SELECT column_names FROM view_name;`
Daftar nama kolom tampilan harus ditentukan untuk tampilan rekursif.
**`name`**
Nama tampilan yang akan dibuat, yang mungkin secara opsional memenuhi syarat skema. Daftar nama kolom harus ditentukan untuk tampilan rekursif.
**`column_name`**
Daftar opsional nama yang akan digunakan untuk kolom tampilan. Jika tidak diberikan, nama kolom disimpulkan dari kueri.
**`WITH ( view_option_name [= view_option_value] [, ... ] )`**
Klausa ini menentukan parameter opsional untuk tampilan; parameter berikut didukung.
+ `check_option (enum)`— Parameter ini mungkin salah satu `local` atau`cascaded`, dan setara dengan menentukan`WITH [ CASCADED | LOCAL ] CHECK OPTION`.
+ `security_barrier (boolean)`—Ini harus digunakan jika tampilan dimaksudkan untuk memberikan keamanan tingkat baris. Aurora DSQL saat ini tidak mendukung keamanan tingkat baris, tetapi opsi ini masih akan memaksa kondisi tampilan (dan `WHERE` kondisi apa pun yang menggunakan operator yang ditandai sebagai`LEAKPROOF`) untuk dievaluasi terlebih dahulu.
+ `security_invoker (boolean)`—Opsi ini menyebabkan hubungan dasar yang mendasarinya diperiksa terhadap hak istimewa pengguna tampilan daripada pemilik tampilan. Lihat catatan di bawah ini untuk detail selengkapnya.
Semua opsi di atas dapat diubah pada tampilan yang ada menggunakan`ALTER VIEW`.
**`query`**
A `SELECT` atau `VALUES` perintah yang akan menyediakan kolom dan baris tampilan.
**`WITH [ CASCADED | LOCAL ] CHECK OPTION`**
Opsi ini mengontrol perilaku tampilan yang dapat diperbarui secara otomatis. Ketika opsi ini ditentukan, `INSERT` dan `UPDATE` perintah pada tampilan akan diperiksa untuk memastikan bahwa baris baru memenuhi kondisi penentuan tampilan (yaitu, baris baru diperiksa untuk memastikan bahwa mereka terlihat melalui tampilan). Jika tidak, pembaruan akan ditolak. Jika tidak `CHECK OPTION` ditentukan, `INSERT` dan `UPDATE` perintah pada tampilan diizinkan untuk membuat baris yang tidak terlihat melalui tampilan.
`LOCAL`—Baris baru hanya diperiksa terhadap kondisi yang ditentukan secara langsung dalam tampilan itu sendiri. Setiap kondisi yang ditentukan pada tampilan dasar yang mendasarinya tidak dicentang (kecuali mereka juga menentukan`CHECK OPTION`).
`CASCADED`—Baris baru diperiksa terhadap kondisi tampilan dan semua tampilan dasar yang mendasarinya. Jika `CHECK OPTION` ditentukan, dan tidak `LOCAL` juga `CASCADED` ditentukan, maka `CASCADED` diasumsikan.
Ini tidak `CHECK OPTION` dapat digunakan dengan `RECURSIVE` tampilan. `CHECK OPTION`Ini hanya didukung pada tampilan yang dapat diperbarui secara otomatis.
## Catatan
Gunakan `DROP VIEW` pernyataan untuk menghapus tampilan.
Nama dan tipe data kolom tampilan harus dipertimbangkan dengan cermat. Misalnya, CREATE VIEW vista AS SELECT 'Hello World'; tidak disarankan karena nama kolom default ke. `?column?;` Juga, tipe data kolom default ke`text`, yang mungkin bukan yang Anda inginkan.
Pendekatan yang lebih baik adalah secara eksplisit menentukan nama kolom dan tipe data, seperti:. `CREATE VIEW vista AS SELECT text 'Hello World' AS hello;`
Secara default, akses ke relasi dasar yang dirujuk dalam tampilan ditentukan oleh izin pemilik tampilan. Dalam beberapa kasus, ini dapat digunakan untuk menyediakan akses yang aman tetapi terbatas ke tabel yang mendasarinya. Namun, tidak semua pandangan aman terhadap gangguan.
+ Jika tampilan memiliki `security_invoker` properti yang disetel ke true, akses ke relasi dasar yang mendasarinya ditentukan oleh izin pengguna yang mengeksekusi kueri, bukan pemilik tampilan. Dengan demikian, pengguna tampilan pemanggil keamanan harus memiliki izin yang relevan pada tampilan dan hubungan dasar yang mendasarinya.
+ Jika salah satu hubungan dasar yang mendasarinya adalah tampilan pemanggil keamanan, itu akan diperlakukan seolah-olah telah diakses langsung dari kueri asli. Dengan demikian, tampilan pemanggil keamanan akan selalu memeriksa hubungan dasar yang mendasarinya menggunakan izin pengguna saat ini, bahkan jika itu diakses dari tampilan tanpa properti. `security_invoker`
+ Fungsi yang dipanggil dalam tampilan diperlakukan sama seperti jika mereka telah dipanggil langsung dari kueri menggunakan tampilan. Oleh karena itu, pengguna tampilan harus memiliki izin untuk memanggil semua fungsi yang digunakan oleh tampilan. Fungsi dalam tampilan dijalankan dengan hak istimewa pengguna yang mengeksekusi kueri atau pemilik fungsi, tergantung pada apakah fungsi didefinisikan sebagai `SECURITY INVOKER` atau. `SECURITY DEFINER`
+ Pengguna yang membuat atau mengganti tampilan harus memiliki `USAGE` hak istimewa pada skema apa pun yang dirujuk dalam kueri tampilan, untuk mencari objek yang direferensikan dalam skema tersebut.
+ Ketika `CREATE OR REPLACE VIEW` digunakan pada tampilan yang ada, hanya `SELECT` aturan penentu tampilan, ditambah `WITH ( ... )` parameter apa pun dan `CHECK OPTION` yang diubah. Properti tampilan lainnya, termasuk kepemilikan, izin, dan aturan non-Pilih, tetap tidak berubah. Anda harus memiliki tampilan untuk menggantinya (ini termasuk menjadi anggota peran pemilik).
## Tampilan yang dapat diperbarui
Tampilan sederhana dapat diperbarui secara otomatis: sistem akan memungkinkan`INSERT`,`UPDATE`, dan `DELETE` pernyataan yang akan digunakan pada tampilan dengan cara yang sama seperti pada tabel biasa. Tampilan dapat diperbarui secara otomatis jika memenuhi semua kondisi berikut:
+ Tampilan harus memiliki tepat satu entri dalam `FROM` daftarnya, yang harus berupa tabel atau tampilan lain yang dapat diperbarui.
+ Definisi tampilan tidak boleh berisi`WITH`,,`DISTINCT`,`GROUP BY`, `HAVING``LIMIT`, atau `OFFSET` klausa di tingkat atas.
+ Definisi tampilan tidak boleh berisi operasi set (`UNION`,`INTERSECT`, atau`EXCEPT`) di tingkat atas.
+ Daftar pilih tampilan tidak boleh berisi agregat, fungsi jendela, atau fungsi set-return.
Tampilan yang dapat diperbarui secara otomatis mungkin berisi campuran kolom yang dapat diperbarui dan yang tidak dapat diperbarui. Kolom dapat diperbarui jika itu adalah referensi sederhana ke kolom yang dapat diperbarui dari hubungan dasar yang mendasarinya. Jika tidak, kolom tersebut hanya-baca, dan kesalahan terjadi jika `UPDATE` pernyataan `INSERT` atau mencoba untuk menetapkan nilai untuk itu.
Tampilan yang lebih kompleks yang tidak memenuhi semua kondisi ini adalah hanya-baca secara default: sistem tidak mengizinkan penyisipan, pembaruan, atau penghapusan pada tampilan.
**catatan**
Pengguna yang melakukan penyisipan, pembaruan, atau penghapusan pada tampilan harus memiliki hak sisipan, pembaruan, atau hapus yang sesuai pada tampilan. Secara default, pemilik tampilan harus memiliki hak istimewa yang relevan pada relasi dasar yang mendasarinya, sementara pengguna yang melakukan pembaruan tidak memerlukan izin apa pun pada relasi dasar yang mendasarinya. Namun, jika tampilan memiliki security\$1invoker disetel ke true, pengguna yang melakukan pembaruan, bukan pemilik tampilan, harus memiliki hak istimewa yang relevan pada relasi dasar yang mendasarinya.
## Contoh
Untuk membuat tampilan yang terdiri dari semua film komedi.
```
CREATE VIEW comedies AS
SELECT *
FROM films
WHERE kind = 'Comedy';
```
Buat tampilan dengan`LOCAL CHECK OPTION`.
```
CREATE VIEW pg_comedies AS
SELECT *
FROM comedies
WHERE classification = 'PG'
WITH CASCADED CHECK OPTION;
```
Buat tampilan rekursif.
```
CREATE RECURSIVE VIEW public.nums_1_100 (n) AS
VALUES (1)
UNION ALL
SELECT n+1 FROM nums_1_100 WHERE n < 100;
```
## Kompatibilitas
`CREATE OR REPLACE VIEW`adalah ekstensi bahasa PostgreSQL. `WITH ( ... )`Klausul ini juga merupakan perpanjangan, seperti juga pandangan penghalang keamanan dan pandangan pemanggil keamanan. Aurora DSQL mendukung ekstensi bahasa ini.
# `ALTER VIEW`
`ALTER VIEW`Pernyataan ini memungkinkan mengubah berbagai properti dari tampilan yang ada, dan Aurora DSQL mendukung semua sintaks PostgreSQL untuk perintah ini.
## Sintaksis yang didukung
```
ALTER VIEW [ IF EXISTS ] name ALTER [ COLUMN ] column_name SET DEFAULT expression
ALTER VIEW [ IF EXISTS ] name ALTER [ COLUMN ] column_name DROP DEFAULT
ALTER VIEW [ IF EXISTS ] name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER VIEW [ IF EXISTS ] name RENAME [ COLUMN ] column_name TO new_column_name
ALTER VIEW [ IF EXISTS ] name RENAME TO new_name
ALTER VIEW [ IF EXISTS ] name SET SCHEMA new_schema
ALTER VIEW [ IF EXISTS ] name SET ( view_option_name [= view_option_value] [, ... ] )
ALTER VIEW [ IF EXISTS ] name RESET ( view_option_name [, ... ] )
```
## Deskripsi
`ALTER VIEW`mengubah berbagai properti tambahan tampilan. (Jika Anda ingin mengubah kueri penentu tampilan, gunakan`CREATE OR REPLACE VIEW`.) Anda harus memiliki pandangan untuk digunakan`ALTER VIEW`. Untuk mengubah skema tampilan, Anda juga harus memiliki `CREATE` hak istimewa pada skema baru. Untuk mengubah pemilik, Anda harus `SET ROLE` dapat memiliki peran baru, dan peran itu harus memiliki `CREATE` hak istimewa pada skema tampilan.
## Parameter
**`name`**
Nama (opsional schema-qualified) dari tampilan yang ada.
**`column_name`**
Nama kolom yang ada, atau nama baru untuk kolom yang ada.
**`IF EXISTS`**
Jangan melempar kesalahan jika tampilan tidak ada. Pemberitahuan dikeluarkan dalam kasus ini.
**`SET/DROP DEFAULT`**
Formulir ini mengatur atau menghapus nilai default untuk kolom. Nilai default untuk kolom tampilan diganti ke salah satu `INSERT` atau `UPDATE` perintah di mana target adalah tampilan.
**`new_owner`**
Nama pengguna dari pemilik tampilan yang baru.
**`new_name`**
Nama baru untuk tampilan.
**`new_schema`**
Skema baru untuk tampilan.
**`SET ( view_option_name [= view_option_value] [, ... ] )`**
Menetapkan opsi tampilan. Berikut ini adalah opsi yang didukung:
+ `check_option (enum)`- Mengubah opsi centang tampilan. Nilainya harus `local` atau`cascaded`.
+ `security_barrier (boolean)`- Mengubah properti penghalang keamanan tampilan.
+ `security_invoker (boolean)`- Mengubah properti security-invoker tampilan.
**`RESET ( view_option_name [, ... ] )`**
Mengatur ulang opsi tampilan ke nilai defaultnya.
## Contoh
Mengganti nama tampilan `foo` menjadi`bar`:
```
ALTER VIEW foo RENAME TO bar;
```
Melampirkan nilai kolom default ke tampilan yang dapat diperbarui:
```
CREATE TABLE base_table (id int, ts timestamptz);
CREATE VIEW a_view AS SELECT * FROM base_table;
ALTER VIEW a_view ALTER COLUMN ts SET DEFAULT now();
INSERT INTO base_table(id) VALUES(1); -- ts will receive a NULL
INSERT INTO a_view(id) VALUES(2); -- ts will receive the current time
```
## Kompatibilitas
`ALTER VIEW`adalah ekstensi PostgreSQL dari standar SQL yang didukung Aurora DSQL.
# `DROP VIEW`
`DROP VIEW`Pernyataan tersebut menghapus tampilan yang ada. Aurora DSQL mendukung sintaks PostgreSQL lengkap untuk perintah ini.
## Sintaksis yang didukung
```
DROP VIEW [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## Deskripsi
`DROP VIEW`menjatuhkan tampilan yang ada. Untuk menjalankan perintah ini, Anda harus menjadi pemilik tampilan.
## Parameter
**`IF EXISTS`**
Jangan melempar kesalahan jika tampilan tidak ada. Pemberitahuan dikeluarkan dalam kasus ini.
**`name`**
Nama (opsional schema-qualified) dari tampilan yang akan dihapus.
**`CASCADE`**
Secara otomatis menjatuhkan objek yang bergantung pada tampilan (seperti tampilan lain), dan pada gilirannya semua objek yang bergantung pada objek tersebut.
**`RESTRICT`**
Menolak untuk menjatuhkan tampilan jika ada objek yang bergantung padanya. Ini adalah opsi default.
## Contoh
```
DROP VIEW kinds;
```
## Kompatibilitas
Perintah ini sesuai dengan standar SQL, kecuali bahwa standar hanya memungkinkan satu tampilan untuk dijatuhkan per perintah, dan terlepas dari `IF EXISTS` opsi, yang merupakan ekstensi PostgreSQL yang didukung Aurora DSQL.
# Migrasi dari PostgreSQL ke Aurora DSQL
Aurora DSQL dirancang agar [kompatibel](working-with-postgresql-compatibility.md) dengan PostgreSQL, mendukung fitur relasional inti seperti transaksi ACID, indeks sekunder, gabungan, dan operasi DHTML standar. Sebagian besar aplikasi PostgreSQL yang ada dapat bermigrasi ke Aurora DSQL dengan sedikit perubahan.
Bagian ini memberikan panduan praktis untuk memigrasikan aplikasi Anda ke Aurora DSQL, termasuk kompatibilitas kerangka kerja, pola migrasi, dan pertimbangan arsitektur.
## Kerangka kerja dan kompatibilitas ORM
Aurora DSQL menggunakan protokol kawat PostgreSQL standar, memastikan kompatibilitas dengan driver dan kerangka kerja PostgreSQL. ORMs Pekerjaan paling populer dengan Aurora DSQL dengan sedikit atau tanpa perubahan. Lihat [Adaptor dan dialek Aurora DSQL](aws-sdks.md#aurora-dsql-adapters) untuk implementasi referensi dan integrasi ORM yang tersedia.
## Pola migrasi umum
Saat bermigrasi dari PostgreSQL ke Aurora DSQL, beberapa fitur bekerja secara berbeda atau memiliki sintaks alternatif. Bagian ini memberikan panduan tentang skenario migrasi umum.
### Alternatif operasi DDL
Aurora DSQL menyediakan alternatif modern untuk operasi PostgreSQL DDL tradisional:
**Pembuatan indeks**
Gunakan `CREATE INDEX ASYNC` alih-alih `CREATE INDEX` untuk pembuatan indeks non-pemblokiran.
**Manfaat:** Pembuatan indeks nol-downtime pada tabel besar.
**Penghapusan data**
Gunakan `DELETE FROM table_name` sebagai pengganti`TRUNCATE`.
**Alternatif:** Untuk rekreasi meja lengkap, gunakan `DROP TABLE` diikuti oleh`CREATE TABLE`.
**Konfigurasi sistem**
Aurora DSQL sepenuhnya dikelola, sehingga konfigurasi ditangani secara otomatis berdasarkan pola beban kerja. Gunakan AWS Management Console atau API untuk mengelola setelan klaster.
**Manfaat:** Tidak perlu penyetelan basis data atau manajemen parameter.
### Pola desain skema
Sesuaikan pola PostgreSQL umum ini untuk kompatibilitas Aurora DSQL:
**Pola integritas referensial**
Aurora DSQL mendukung hubungan tabel dan operasi. `JOIN` Untuk integritas referensial, terapkan validasi di lapisan aplikasi Anda. Desain ini selaras dengan pola database terdistribusi modern di mana validasi lapisan aplikasi memberikan lebih banyak fleksibilitas dan menghindari kemacetan kinerja dari operasi cascading.
**Pola:** Menerapkan pemeriksaan integritas referensial di lapisan aplikasi Anda menggunakan konvensi penamaan yang konsisten, logika validasi, dan batas transaksi. Banyak aplikasi skala tinggi lebih memilih pendekatan ini untuk kontrol yang lebih baik atas penanganan kesalahan dan kinerja.
**Penanganan data sementara**
Gunakan CTEs, subkueri, atau tabel biasa dengan logika pembersihan, bukan tabel sementara.
**Alternatif:** Buat tabel dengan nama khusus sesi dan bersihkan di aplikasi Anda.
## Memahami perbedaan arsitektur
Arsitektur Aurora DSQL yang didistribusikan dan tanpa server sengaja berbeda dari PostgreSQL tradisional di beberapa area. Perbedaan ini memungkinkan manfaat utama Aurora DSQL dari kesederhanaan dan skala.
### Model basis data yang disederhanakan
**Database tunggal per cluster**
Aurora DSQL menyediakan satu database built-in bernama per cluster. `postgres`
**Tip migrasi:** Jika aplikasi Anda menggunakan beberapa database, buat cluster Aurora DSQL terpisah untuk pemisahan logis, atau gunakan skema dalam satu cluster.
**Tidak ada tabel sementara**
Untuk penanganan data sementara, Anda HARUS menggunakan ekspresi tabel umum (CTEs) dan subkueri, yang menyediakan alternatif fleksibel untuk kueri kompleks.
**Alternatif:** Gunakan CTEs dengan `WITH` klausa untuk set hasil sementara, atau tabel reguler dengan penamaan unik untuk data khusus sesi.
**Manajemen penyimpanan otomatis**
Aurora DSQL menghilangkan ruang meja dan manajemen penyimpanan manual. Penyimpanan secara otomatis menskalakan dan mengoptimalkan berdasarkan pola data Anda.
**Manfaat:** Tidak perlu memantau ruang disk, merencanakan alokasi penyimpanan, atau mengelola konfigurasi tablespace.
### Pola aplikasi modern
Aurora DSQL mendorong pola pengembangan aplikasi modern yang meningkatkan pemeliharaan dan kinerja:
**Logika tingkat aplikasi alih-alih pemicu basis data**
Untuk fungsionalitas seperti pemicu, terapkan logika berbasis peristiwa di lapisan aplikasi Anda.
**Strategi migrasi:** Pindahkan logika pemicu ke kode aplikasi, gunakan arsitektur berbasis peristiwa dengan AWS layanan seperti EventBridge, atau terapkan jejak audit menggunakan pencatatan aplikasi.
**Fungsi SQL untuk pemrosesan data**
Aurora DSQL mendukung fungsi berbasis SQL tetapi tidak bahasa prosedural seperti PL/PGSQL.
**Alternatif:** Gunakan fungsi SQL untuk transformasi data, atau pindahkan logika kompleks ke lapisan aplikasi atau fungsi Lambda AWS Anda.
**Kontrol konkurensi yang optimis alih-alih penguncian pesimis**
Aurora DSQL menggunakan optimistic concurrency control (OCC), pendekatan bebas kunci yang berbeda dari mekanisme penguncian basis data tradisional. Alih-alih memperoleh kunci yang memblokir transaksi lain, Aurora DSQL memungkinkan transaksi untuk dilanjutkan tanpa memblokir dan mendeteksi konflik pada waktu komit. Ini menghilangkan kebuntuan dan mencegah transaksi lambat memblokir operasi lain.
**Perbedaan utama:** Ketika konflik terjadi, Aurora DSQL mengembalikan kesalahan serialisasi daripada membuat transaksi menunggu kunci. Ini mengharuskan aplikasi untuk mengimplementasikan logika coba lagi, mirip dengan menangani batas waktu kunci dalam database tradisional, tetapi konflik diselesaikan segera daripada menyebabkan pemblokiran menunggu.
**Pola desain:** Menerapkan logika transaksi idempoten dengan mekanisme coba lagi. Rancang skema untuk meminimalkan pertengkaran dengan menggunakan kunci primer acak dan menyebarkan pembaruan di seluruh rentang kunci Anda. Lihat perinciannya di [Kontrol konkurensi di Aurora DSQL](working-with-concurrency-control.md).
**Hubungan dan integritas referensial**
Aurora DSQL mendukung hubungan kunci asing antar tabel, termasuk operasi. ` JOIN ` Untuk integritas referensial, terapkan validasi di lapisan aplikasi Anda. Meskipun menegakkan integritas referensial dapat berharga, operasi cascading (seperti penghapusan cascading) dapat menciptakan masalah kinerja yang tidak terduga — misalnya, menghapus pesanan dengan 1.000 item baris menjadi transaksi 1.001-baris. Banyak pelanggan menghindari kendala kunci asing karena alasan ini.
**Pola desain:** Menerapkan pemeriksaan integritas referensial di lapisan aplikasi Anda, gunakan pola konsistensi akhirnya, atau manfaatkan AWS layanan untuk validasi data.
### Penyederhanaan operasional
Aurora DSQL menghilangkan banyak tugas pemeliharaan basis data tradisional, mengurangi overhead operasional:
**Tidak diperlukan perawatan manual**
Aurora DSQL secara otomatis mengelola pengoptimalan penyimpanan, pengumpulan statistik, dan penyetelan kinerja. Perintah pemeliharaan tradisional seperti `VACUUM` ditangani oleh sistem.
**Manfaat:** Menghilangkan kebutuhan akan jendela pemeliharaan basis data, penjadwalan vakum, dan penyetelan parameter sistem.
**Partisi dan penskalaan otomatis**
Aurora DSQL secara otomatis mempartisi dan mendistribusikan data Anda berdasarkan pola akses. Penggunaan UUIDs atau aplikasi yang dihasilkan IDs untuk distribusi yang optimal.
**Tip migrasi:** Hapus logika partisi manual dan biarkan Aurora DSQL menangani distribusi data. Penggunaan UUIDs atau aplikasi yang dihasilkan IDs untuk distribusi yang optimal. Jika aplikasi Anda memerlukan pengidentifikasi berurutan, lihat. [Urutan dan kolom identitas](sequences-identity-columns.md)
# Migrasi agen dengan alat AI
Agen pengkodean AI dapat mempercepat migrasi Anda ke Aurora DSQL dengan menganalisis skema, mengubah kode, dan menjalankan migrasi DDL dengan pemeriksaan keamanan bawaan.
## Menggunakan Kiro untuk migrasi
Agen pengkodean seperti [Kiro](https://kiro.dev/) dapat membantu Anda menganalisis dan memigrasikan kode PostgreSQL Anda ke Aurora DSQL:
+ **Analisis skema:** Unggah file skema yang ada dan minta Kiro mengidentifikasi potensi masalah kompatibilitas dan menyarankan alternatif
+ **Transformasi kode:** Berikan kode aplikasi Anda dan minta Kiro untuk membantu memfaktorkan ulang logika pemicu, mengganti urutan dengan UUIDs, atau memodifikasi pola transaksi
+ **Perencanaan migrasi:** Minta Kiro untuk membuat rencana step-by-step migrasi berdasarkan arsitektur aplikasi spesifik Anda
+ **Migrasi DDL:** Jalankan modifikasi skema menggunakan pola rekreasi meja dengan pemeriksaan keamanan bawaan dan verifikasi pengguna
**Contoh petunjuk:**
```
"Analyze this PostgreSQL schema for DSQL compatibility and suggest alternatives for any unsupported features"
"Help me refactor this trigger function into application-level logic for DSQL migration"
"Create a migration checklist for moving my Django application from PostgreSQL to DSQL"
"Drop the legacy_status column from the orders table"
"Change the price column from VARCHAR to DECIMAL in the products table"
```
## Migrasi DDL dengan rekreasi meja
Saat menggunakan agen AI dengan server MCP Aurora DSQL, operasi ALTER TABLE tertentu menggunakan *pola rekreasi tabel* yang memigrasikan data Anda dengan aman. Agen menangani kompleksitas sambil memberi Anda informasi di setiap langkah.
Operasi berikut menggunakan pola rekreasi meja:
| Operasi | Pendekatan |
| --- | --- |
| DROP COLUMN | Kecualikan kolom dari tabel baru |
| ALTER COLUMN TYPE | Mentransmisikan tipe data selama migrasi |
| ALTER COLUMN SET/DROP NOT NULL | Ubah kendala dalam definisi tabel baru |
| ALTER COLUMN SET/DROP DEFAULT | Tentukan default dalam definisi tabel baru |
| ADD/DROP CONSTRAINT | Sertakan atau hapus kendala di tabel baru |
| MODIFY PRIMARY KEY | Tentukan PK baru dengan validasi keunikan |
| Pisah/Gabungkan kolom | Gunakan SPLIT\$1PART, SUBSTRING, atau CONCAT |
Operasi ALTER TABLE berikut didukung secara langsung tanpa rekreasi meja:
+ `ALTER TABLE ... RENAME COLUMN`— Ganti nama kolom
+ `ALTER TABLE ... RENAME TO`— Ganti nama tabel
+ `ALTER TABLE ... ADD COLUMN`- Tambahkan kolom baru
**Fitur keamanan:** Saat menjalankan migrasi DDL, agen AI menyajikan rencana migrasi, memverifikasi kompatibilitas data, mengonfirmasi jumlah baris, dan meminta persetujuan eksplisit sebelum operasi destruktif seperti DROP TABLE.
**Migrasi batch:** Untuk tabel yang melebihi 3.000 baris, agen secara otomatis mengumpulkan migrasi dengan penambahan 500-1.000 baris agar tetap berada dalam batas transaksi.
## Server MCP Aurora DSQL
Server Aurora DSQL Model Context Protocol (MCP) memungkinkan asisten AI untuk terhubung langsung ke cluster Aurora DSQL Anda dan mencari dokumentasi Aurora DSQL. Ini memungkinkan AI untuk:
+ Analisis skema yang ada dan sarankan perubahan migrasi
+ Jalankan migrasi DDL dengan pola rekreasi meja
+ Uji kueri dan verifikasi kompatibilitas selama migrasi
+ Berikan up-to-date panduan yang akurat berdasarkan dokumentasi Aurora DSQL terbaru
[Untuk menggunakan server Aurora DSQL MCP dengan asisten AI, lihat instruksi penyiapan untuk server MCP Aurora DSQL.](SECTION_aurora-dsql-mcp-server.md)
## Pertimbangan Aurora DSQL untuk kompatibilitas PostgreSQL
Aurora DSQL memiliki perbedaan dukungan fitur dari PostgreSQL yang dikelola sendiri yang memungkinkan arsitektur terdistribusi, operasi tanpa server, dan penskalaan otomatis. Sebagian besar aplikasi bekerja dalam perbedaan ini tanpa modifikasi.
Untuk pertimbangan umum, lihat[Pertimbangan untuk bekerja dengan Amazon Aurora DSQL](considerations.md). Untuk kuota dan batasan, lihat[Kuota klaster dan batas basis data di Amazon Aurora DSQL](CHAP_quotas.md).
+ Aurora DSQL menggunakan database built-in tunggal bernama per cluster. `postgres` Untuk pemisahan logis, buat cluster Aurora DSQL terpisah atau gunakan skema dalam satu cluster.
+ `postgres`Basis data menggunakan pengkodean karakter UTF-8, yang menyediakan dukungan karakter internasional yang luas.
+ Basis data hanya `C` menggunakan pemeriksaan.
+ Aurora DSQL digunakan `UTC` sebagai zona waktu sistem. Postgres menyimpan semua tanggal dan waktu yang sadar zona waktu secara internal di UTC. Anda dapat mengatur parameter `TimeZone` konfigurasi untuk mengonversi bagaimana itu ditampilkan ke klien dan berfungsi sebagai default untuk input klien yang akan digunakan server untuk mengonversi ke UTC secara internal.
+ Tingkat isolasi transaksi ditetapkan di PostgreSQL`Repeatable Read`.
+ Transaksi memiliki kendala sebagai berikut:
+ Operasi DDL dan DMLmemerlukan transaksi terpisah
+ Transaksi hanya dapat mencakup 1 pernyataan DDL
+ Transaksi dapat memodifikasi hingga 3.000 baris, terlepas dari jumlah indeks sekunder
+ Batas 3.000 baris berlaku untuk semua pernyataan DHTML (,,) `INSERT` `UPDATE` `DELETE`
+ Waktu koneksi database habis setelah 1 jam.
+ Aurora DSQL mengelola izin melalui hibah tingkat skema. Pengguna admin membuat skema menggunakan `CREATE SCHEMA` dan memberikan akses menggunakan`GRANT USAGE ON SCHEMA`. Pengguna admin mengelola objek dalam skema publik, sementara pengguna non-admin membuat objek dalam skema yang dibuat pengguna untuk batas kepemilikan yang jelas. Untuk informasi selengkapnya, lihat [Mengotorisasi peran database untuk menggunakan SQL dalam database Anda](using-database-and-iam-roles.md#using-database-and-iam-roles-custom-database-roles-sql).
## Butuh bantuan dengan migrasi?
Jika Anda menemukan fitur yang penting untuk migrasi Anda tetapi saat ini tidak didukung di Aurora DSQL, lihat [Memberikan umpan balik tentang Amazon Aurora DSQL](providing-feedback.md) untuk informasi tentang cara berbagi umpan balik dengan AWS.
# Kontrol konkurensi di Aurora DSQL
Concurrency memungkinkan beberapa sesi untuk mengakses dan memodifikasi data secara bersamaan tanpa mengorbankan integritas dan konsistensi data. Aurora DSQL menyediakan kompatibilitas [PostgreSQL sambil menerapkan mekanisme kontrol konkurensi modern yang bebas](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html) kunci. Ini mempertahankan kepatuhan ACID penuh melalui isolasi snapshot, memastikan konsistensi dan keandalan data.
Keuntungan utama Aurora DSQL adalah arsitekturnya yang bebas kunci, yang menghilangkan kemacetan kinerja database yang umum. Aurora DSQL mencegah transaksi lambat memblokir operasi lain dan menghilangkan risiko kebuntuan. Pendekatan ini membuat Aurora DSQL sangat berharga untuk aplikasi throughput tinggi di mana kinerja dan skalabilitas sangat penting.
## Konflik transaksi
Aurora DSQL menggunakan kontrol konkurensi optimis (OCC), yang bekerja secara berbeda dari sistem berbasis kunci tradisional. Alih-alih menggunakan kunci, OCC mengevaluasi konflik pada waktu komit. Ketika beberapa transaksi bertentangan saat memperbarui baris yang sama, Aurora DSQL mengelola transaksi sebagai berikut:
+ Transaksi dengan waktu komit paling awal diproses oleh Aurora DSQL.
+ Transaksi yang bertentangan menerima kesalahan serialisasi PostgreSQL, yang menunjukkan perlunya dicoba lagi.
Rancang aplikasi Anda untuk menerapkan logika coba lagi untuk menangani konflik. Pola desain yang ideal adalah idempoten, memungkinkan percobaan ulang transaksi sebagai jalan pertama bila memungkinkan. Logika yang direkomendasikan mirip dengan logika batalkan dan coba lagi dalam batas waktu kunci PostgreSQL standar atau situasi kebuntuan. Namun, OCC mengharuskan aplikasi Anda untuk menggunakan logika ini lebih sering.
## Pedoman untuk mengoptimalkan kinerja transaksi
Untuk mengoptimalkan kinerja, minimalkan pertengkaran tinggi pada tombol tunggal atau rentang kunci kecil. Untuk mencapai tujuan ini, rancang skema Anda untuk menyebarkan pembaruan pada rentang kunci klaster Anda dengan menggunakan pedoman berikut:
+ Pilih kunci primer acak untuk tabel Anda.
+ Hindari pola yang meningkatkan pertengkaran pada satu tombol. Pendekatan ini memastikan kinerja optimal bahkan ketika volume transaksi tumbuh.
# DDL dan transaksi terdistribusi di Aurora DSQL
Bahasa definisi data (DDL) berperilaku berbeda di Aurora DSQL dari PostgreSQL. Aurora DSQL memiliki lapisan database multi-AZ yang didistribusikan dan tidak dibagikan yang dibangun di atas armada komputasi dan penyimpanan multi-tenant. Karena tidak ada satu pun node atau pemimpin basis data utama yang ada, katalog database didistribusikan. Dengan demikian, Aurora DSQL mengelola perubahan skema DDL sebagai transaksi terdistribusi.
Secara khusus, DDL berperilaku berbeda di Aurora DSQL sebagai berikut:
**Kesalahan kontrol konkurensi**
Aurora DSQL mengembalikan kesalahan pelanggaran kontrol konkurensi jika Anda menjalankan satu transaksi sementara transaksi lain memperbarui sumber daya. Misalnya, pertimbangkan urutan tindakan berikut:
1. Di sesi 1, pengguna menambahkan kolom ke tabel`mytable`.
1. Di sesi 2, pengguna mencoba memasukkan baris ke dalam`mytable`.
Aurora DSQL mengembalikan kesalahan `SQL Error [40001]: ERROR: schema has been updated by another transaction, please retry: (OC001).`
**DDL dan DML dalam transaksi yang sama**
Transaksi di Aurora DSQL hanya dapat berisi satu pernyataan DDL dan tidak dapat memiliki pernyataan DDL dan DHTML. Pembatasan ini berarti Anda tidak dapat membuat tabel dan menyisipkan data ke dalam tabel yang sama dalam transaksi yang sama. Misalnya, Aurora DSQL mendukung transaksi berurutan berikut.
```
BEGIN;
CREATE TABLE mytable (ID_col integer);
COMMIT;
BEGIN;
INSERT into FOO VALUES (1);
COMMIT;
```
Aurora DSQL tidak mendukung transaksi berikut, yang mencakup keduanya dan pernyataan. `CREATE` `INSERT`
```
BEGIN;
CREATE TABLE FOO (ID_col integer);
INSERT into FOO VALUES (1);
COMMIT;
```
**DDL asinkron**
Dalam PostgreSQL standar, operasi DDL `CREATE INDEX` seperti mengunci tabel yang terpengaruh, membuatnya tidak tersedia untuk dibaca dan ditulis dari sesi lain. Di Aurora DSQL, pernyataan DDL ini berjalan secara asinkron menggunakan pengelola latar belakang. Akses ke tabel yang terpengaruh tidak diblokir. Dengan demikian, DDL pada tabel besar dapat berjalan tanpa downtime atau dampak kinerja. Untuk informasi selengkapnya tentang manajer pekerjaan asinkron di Aurora DSQL, lihat. [Indeks asinkron di Aurora DSQL](working-with-create-index-async.md)
# Kunci utama di Aurora DSQL
Dalam Aurora DSQL, kunci utama adalah fitur yang secara fisik mengatur data tabel. Ini mirip dengan `CLUSTER` operasi di PostgreSQL atau indeks berkerumun di database lain. Saat Anda menentukan kunci primer, Aurora DSQL membuat indeks yang mencakup semua kolom dalam tabel. Struktur kunci utama di Aurora DSQL memastikan akses dan manajemen data yang efisien.
## Struktur dan penyimpanan data
Saat Anda menentukan kunci primer, Aurora DSQL menyimpan data tabel dalam urutan kunci primer. Struktur terorganisir indeks ini memungkinkan pencarian kunci primer untuk mengambil semua nilai kolom secara langsung, alih-alih mengikuti penunjuk ke data seperti dalam indeks B-tree tradisional. Berbeda dengan `CLUSTER` operasi di PostgreSQL, yang mengatur ulang data hanya sekali, Aurora DSQL mempertahankan urutan ini secara otomatis dan terus menerus. Pendekatan ini meningkatkan kinerja kueri yang bergantung pada akses kunci primer.
Aurora DSQL juga menggunakan kunci utama untuk menghasilkan kunci unik di seluruh cluster untuk setiap baris dalam tabel dan indeks. Kunci unik ini juga mendukung manajemen data terdistribusi. Ini memungkinkan partisi data secara otomatis di beberapa node, mendukung penyimpanan yang dapat diskalakan dan konkurensi tinggi. Akibatnya, struktur kunci utama membantu Aurora DSQL menskalakan secara otomatis dan mengelola beban kerja bersamaan secara efisien.
## Pedoman untuk memilih kunci utama
Saat memilih dan menggunakan kunci primer di Aurora DSQL, pertimbangkan pedoman berikut:
+ Tentukan kunci utama saat Anda membuat tabel. Anda tidak dapat mengubah kunci ini atau menambahkan kunci utama baru nanti. Kunci primer menjadi bagian dari kunci seluruh cluster yang digunakan untuk partisi data dan penskalaan otomatis throughput tulis. Jika Anda tidak menentukan kunci utama, Aurora DSQL menetapkan ID tersembunyi sintetis.
+ Untuk tabel dengan volume tulis tinggi, hindari penggunaan bilangan bulat yang meningkat secara monoton sebagai kunci utama. Hal ini dapat menyebabkan masalah kinerja dengan mengarahkan semua sisipan baru ke satu partisi. Sebagai gantinya, gunakan kunci primer dengan distribusi acak untuk memastikan distribusi penulisan yang merata di seluruh partisi penyimpanan.
+ Untuk tabel yang jarang berubah atau hanya-baca, Anda dapat menggunakan tombol naik. Contoh kunci naik adalah stempel waktu atau nomor urut. Kunci padat memiliki banyak nilai yang berjarak dekat atau duplikat. Anda dapat menggunakan tombol naik meskipun padat karena kinerja tulis kurang kritis.
+ Jika pemindaian tabel lengkap tidak memenuhi persyaratan kinerja Anda, pilih metode akses yang lebih efisien. Dalam kebanyakan kasus, ini berarti menggunakan kunci utama yang cocok dengan kunci gabungan dan pencarian Anda yang paling umum dalam kueri.
+ Ukuran gabungan maksimum kolom dalam kunci primer adalah 1 kibibyte. Untuk informasi selengkapnya, lihat [Batas basis data di Aurora DSQL dan [tipe data yang didukung di](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-data-types) Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html#SECTION_database-limits).
+ Anda dapat menyertakan hingga 8 kolom dalam kunci primer atau indeks sekunder. Untuk informasi selengkapnya, lihat [Batas basis data di Aurora DSQL dan [tipe data yang didukung di](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-data-types) Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html#SECTION_database-limits).
# Urutan dan kolom identitas
Urutan dan kolom identitas menghasilkan nilai integer dan berguna ketika pengidentifikasi kompak atau dapat dibaca manusia diperlukan. Nilai-nilai ini melibatkan alokasi dan perilaku caching yang dijelaskan dalam dokumentasi. [`CREATE SEQUENCE`](create-sequence-syntax-support.md)
**Topics**
+ [Fungsi manipulasi urutan](sequence-functions-syntax-support.md)
+ [Kolom identitas](sequences-identity-columns-overview.md)
+ [Bekerja dengan urutan dan kolom identitas](sequences-identity-columns-working-with.md)
# Fungsi manipulasi urutan
Bagian ini menjelaskan fungsi untuk beroperasi pada objek urutan, juga disebut generator urutan atau hanya urutan. Objek urutan adalah tabel baris tunggal khusus yang dibuat dengan[`CREATE SEQUENCE`](create-sequence-syntax-support.md). Objek urutan biasanya digunakan untuk menghasilkan pengidentifikasi unik untuk baris tabel. Fungsi urutan menyediakan metode sederhana yang aman untuk multipengguna untuk mendapatkan nilai urutan berturut-turut dari objek urutan.
**penting**
Saat menggunakan urutan, nilai cache harus dipertimbangkan dengan cermat. Untuk informasi selengkapnya, lihat info penting di [`CREATE SEQUENCE`](create-sequence-syntax-support.md) halaman.
Untuk panduan tentang cara terbaik menggunakan urutan berdasarkan pola beban kerja, lihat. [Bekerja dengan urutan dan kolom identitas](sequences-identity-columns-working-with.md)
| Fungsi | Deskripsi |
| --- | --- |
| nextval ( regclass ) → bigint | Memajukan objek urutan ke nilai berikutnya dan mengembalikan nilai itu. Ini dilakukan secara atom: bahkan jika beberapa sesi berjalan secara nextval bersamaan, masing-masing akan dengan aman menerima nilai urutan yang berbeda. Jika objek urutan telah dibuat dengan parameter default, nextval panggilan berturut-turut akan mengembalikan nilai yang meningkat dimulai dengan 1. Perilaku lain dapat diperoleh dengan menggunakan parameter yang sesuai dalam [`CREATE SEQUENCE`](create-sequence-syntax-support.md) perintah. Fungsi ini membutuhkan USAGE atau UPDATE hak istimewa pada urutan. |
| setval ( regclass, bigint [, boolean ] ) → bigint | Menetapkan nilai objek urutan saat ini, dan opsional is\$1called benderanya. Bentuk dua parameter menetapkan last\$1value bidang urutan ke nilai yang ditentukan dan menetapkan is\$1called bidangnyatrue, yang berarti bahwa yang berikutnya nextval akan memajukan urutan sebelum mengembalikan nilai. Nilai yang akan dilaporkan oleh juga currval diatur ke nilai yang ditentukan. Dalam bentuk tiga parameter, is\$1called dapat diatur ke salah satu true ataufalse. truememiliki efek yang sama dengan bentuk dua parameter. Jika diatur kefalse, berikutnya nextval akan mengembalikan persis nilai yang ditentukan, dan kemajuan urutan dimulai dengan yang berikut ini. nextval Selain itu, nilai yang dilaporkan oleh currval tidak diubah di sini. Contoh: SELECT setval('myseq', 42); -- Next nextval will return 43
SELECT setval('myseq', 42, true); -- Same as above
SELECT setval('myseq', 42, false); -- Next nextval will return 42 Hasil yang dikembalikan oleh setval hanyalah nilai dari argumen keduanya. Fungsi ini membutuhkan UPDATE hak istimewa pada urutan. |
| currval ( regclass ) → bigint | Mengembalikan nilai yang paling baru diperoleh nextval untuk urutan ini dalam sesi saat ini. (Kesalahan dilaporkan jika tidak nextval pernah dipanggil untuk urutan ini dalam sesi ini.) Karena ini mengembalikan nilai session-local, ini memberikan jawaban yang dapat diprediksi apakah sesi lain telah berjalan atau tidak nextval karena sesi saat ini melakukannya. Fungsi ini membutuhkan USAGE atau SELECT hak istimewa pada urutan. |
| lastval () → bigint | Mengembalikan nilai yang terakhir dikembalikan oleh nextval dalam transaksi saat ini. Fungsi ini identik dengancurrval, kecuali bahwa alih-alih mengambil nama urutan sebagai argumen, ini mengacu pada urutan nextval mana pun yang paling baru diterapkan dalam transaksi saat ini. Ini adalah kesalahan untuk menelepon lastval jika nextval belum dipanggil dalam transaksi saat ini. Fungsi ini membutuhkan USAGE atau SELECT hak istimewa pada urutan yang terakhir digunakan. |
**Awas**
Nilai yang diperoleh `nextval` tidak direklamasi untuk digunakan kembali jika transaksi pemanggilan kemudian dibatalkan. Ini berarti bahwa transaksi dibatalkan atau kerusakan database dapat mengakibatkan kesenjangan dalam urutan nilai yang ditetapkan. Itu bisa terjadi tanpa membatalkan transaksi juga. Misalnya, `ON CONFLICT` klausa `INSERT` with an akan menghitung to-be-inserted tuple, termasuk melakukan `nextval` panggilan yang diperlukan, sebelum mendeteksi konflik apa pun yang akan menyebabkannya mengikuti aturan sebagai gantinya. `ON CONFLICT` Dengan demikian, objek urutan Aurora DSQL *tidak dapat digunakan untuk mendapatkan urutan “*tanpa celah”.
Demikian juga, perubahan status urutan `setval` yang dibuat oleh segera terlihat oleh transaksi lain, dan tidak dibatalkan jika transaksi panggilan kembali.
Urutan yang akan dioperasikan oleh fungsi urutan ditentukan oleh `regclass` argumen, yang hanyalah OID dari urutan dalam katalog `pg_class` sistem. Namun, Anda tidak perlu mencari OID dengan tangan, karena konverter input tipe `regclass` data akan melakukan pekerjaan untuk Anda. [Lihat dokumentasi PostgreSQL tentang Jenis Pengenal Objek untuk detailnya.](https://www.postgresql.org/docs/current/datatype-oid.html)
# Kolom identitas
**penting**
Saat menggunakan kolom identitas, nilai cache harus dipertimbangkan dengan cermat. Untuk informasi selengkapnya, lihat info penting di [`CREATE SEQUENCE`](create-sequence-syntax-support.md) halaman.
Untuk panduan tentang cara terbaik menggunakan kolom identitas berdasarkan pola beban kerja, lihat[Bekerja dengan urutan dan kolom identitas](sequences-identity-columns-working-with.md).
Kolom identitas adalah kolom khusus yang dihasilkan secara otomatis dari urutan implisit. Hal ini dapat digunakan untuk menghasilkan nilai-nilai kunci. Untuk membuat kolom identitas, gunakan `GENERATED ... AS IDENTITY` klausa di[`CREATE TABLE`](create-table-syntax-support.md), misalnya:
```
CREATE TABLE people (
id bigint GENERATED ALWAYS AS IDENTITY (CACHE 70000),
...
);
```
atau sebagai alternatif:
```
CREATE TABLE people (
id bigint GENERATED BY DEFAULT AS IDENTITY (CACHE 70000),
...
);
```
Lihat [`CREATE TABLE`](create-table-syntax-support.md) untuk detail selengkapnya.
Jika `INSERT` perintah dijalankan pada tabel dengan kolom identitas dan tidak ada nilai yang secara eksplisit ditentukan untuk kolom identitas, maka nilai yang dihasilkan oleh urutan implisit dimasukkan. Misalnya, dengan definisi sebelumnya dan mengasumsikan kolom tambahan yang sesuai, menulis:
```
INSERT INTO people (name, address) VALUES ('A', 'foo');
INSERT INTO people (name, address) VALUES ('B', 'bar');
```
akan menghasilkan nilai untuk `id` kolom mulai dari 1 dan menghasilkan data tabel berikut:
```
id | name | address
----+------+---------
1 | A | foo
2 | B | bar
```
Atau, kata kunci `DEFAULT` dapat ditentukan sebagai pengganti nilai untuk secara eksplisit meminta nilai yang dihasilkan urutan:
```
INSERT INTO people (id, name, address) VALUES (DEFAULT, 'C', 'baz');
```
Demikian pula, kata kunci `DEFAULT` dapat digunakan dalam `UPDATE` perintah.
Jadi, dalam banyak hal, kolom identitas berperilaku seperti kolom dengan nilai default.
Klausa `ALWAYS` dan `BY DEFAULT` definisi kolom menentukan bagaimana nilai yang ditentukan pengguna secara eksplisit ditangani dan perintah. `INSERT` `UPDATE` Dalam sebuah `INSERT` perintah, jika `ALWAYS` dipilih, nilai yang ditentukan pengguna hanya diterima jika `INSERT` pernyataan menentukan. `OVERRIDING SYSTEM VALUE` Jika `BY DEFAULT` dipilih, maka nilai yang ditentukan pengguna diutamakan. Dengan demikian, menggunakan `BY DEFAULT` hasil dalam perilaku yang lebih mirip dengan nilai default, di mana nilai default dapat diganti dengan nilai eksplisit, sedangkan `ALWAYS` memberikan beberapa perlindungan lebih terhadap memasukkan nilai eksplisit secara tidak sengaja.
Tipe data kolom identitas harus menjadi salah satu tipe data yang didukung oleh urutan. (Lihat [`CREATE SEQUENCE`](create-sequence-syntax-support.md)). Properti dari urutan terkait dapat ditentukan saat membuat kolom identitas (lihat[`CREATE TABLE`](create-table-syntax-support.md)) atau diubah setelahnya (lihat[`ALTER TABLE`](alter-table-syntax-support.md)).
Kolom identitas secara otomatis ditandai sebagai`NOT NULL`. Kolom identitas, bagaimanapun, tidak menjamin keunikan. (Urutan biasanya mengembalikan nilai unik, tetapi urutan dapat diatur ulang, atau nilai dapat dimasukkan secara manual ke dalam kolom identitas, seperti yang dibahas sebelumnya.) Keunikan perlu ditegakkan menggunakan a `PRIMARY KEY` atau kendala. `UNIQUE`
# Bekerja dengan urutan dan kolom identitas
Bagian ini membantu Anda memahami cara terbaik untuk menggunakan urutan dan kolom identitas berdasarkan pola beban kerja.
**penting**
Lihat info penting di [`CREATE SEQUENCE`](create-sequence-syntax-support.md) halaman untuk detail selengkapnya tentang alokasi dan perilaku caching.
## Memilih jenis pengenal
Amazon Aurora DSQL mendukung pengidentifikasi berbasis UUID dan nilai integer yang dihasilkan menggunakan urutan atau kolom identitas. Opsi-opsi ini berbeda dalam bagaimana nilai dialokasikan dan bagaimana skalanya di bawah beban.
Nilai UUID dapat dihasilkan tanpa koordinasi dan sangat cocok untuk beban kerja di mana pengidentifikasi sering dibuat atau di banyak sesi. Karena Amazon Aurora DSQL dirancang untuk operasi terdistribusi, menghindari koordinasi seringkali bermanfaat. Untuk alasan ini, UUIDs direkomendasikan sebagai tipe pengenal default, terutama untuk kunci utama dalam beban kerja di mana skalabilitas penting dan urutan pengenal yang ketat tidak diperlukan.
Urutan dan kolom identitas menghasilkan nilai bilangan bulat kompak yang nyaman untuk pengidentifikasi, pelaporan, dan antarmuka eksternal yang dapat dibaca manusia. Ketika pengidentifikasi numerik lebih disukai karena alasan kegunaan atau integrasi, pertimbangkan untuk menggunakan kolom urutan atau identitas dalam kombinasi dengan pengidentifikasi berbasis UUID. Ketika urutan bilangan bulat atau nilai identitas diperlukan, memilih ukuran cache yang sesuai menjadi bagian penting dari desain beban kerja. Lihat bagian berikut untuk panduan memilih ukuran cache.
## Memilih ukuran cache
Memilih nilai cache yang sesuai adalah bagian penting dari penggunaan urutan dan kolom identitas secara efektif. Pengaturan cache menentukan bagaimana alokasi pengidentifikasi berperilaku di bawah beban, mempengaruhi throughput sistem dan seberapa dekat nilai mencerminkan urutan alokasi.
**Ukuran cache yang lebih besar `CACHE >= 65536` sangat cocok ketika:**
+ Pengidentifikasi dihasilkan pada frekuensi tinggi
+ Banyak sesi menyisipkan secara bersamaan
+ Beban kerja dapat mentolerir kesenjangan dan efek pemesanan yang terlihat
Misalnya, beban kerja konsumsi peristiwa volume tinggi (seperti IoT atau telemetri), serta pengidentifikasi operasional seperti menjalankan pekerjaan, referensi kasus dukungan IDs, atau nomor pesanan internal biasanya mendapat manfaat dari ukuran cache yang lebih besar, di mana pengidentifikasi sering dibuat dan pemesanan yang ketat tidak diperlukan.
**Ukuran cache 1 lebih selaras ketika:**
+ Tingkat alokasi relatif rendah
+ Pengidentifikasi diharapkan mengikuti urutan alokasi lebih dekat dari waktu ke waktu
+ Meminimalkan kesenjangan lebih penting daripada throughput maksimum
Beban kerja seperti menetapkan akun atau nomor referensi, di mana pengidentifikasi dihasilkan lebih jarang dan pemesanan lebih dekat diinginkan, lebih baik diselaraskan dengan ukuran cache 1.
# Indeks asinkron di Aurora DSQL
`CREATE INDEX ASYNC`Perintah membuat indeks pada satu atau lebih kolom dari tabel tertentu. Perintah ini adalah operasi DDL asinkron yang tidak memblokir transaksi lain. Ketika Anda menjalankan`CREATE INDEX ASYNC`, Aurora DSQL segera mengembalikan file. `job_id`
Anda dapat memantau status pekerjaan asinkron ini menggunakan tampilan sistem. `sys.jobs` Saat pekerjaan pembuatan indeks sedang berlangsung, Anda dapat menggunakan prosedur dan perintah ini:
**`sys.wait_for_job(job_id)'your_index_creation_job_id'`**
Memblokir sesi saat ini sampai pekerjaan yang ditentukan selesai atau gagal. Mengembalikan nilai Boolean yang menunjukkan keberhasilan atau kegagalan.
**`DROP INDEX`**
Membatalkan pekerjaan pembuatan indeks yang sedang berlangsung.
Ketika pembuatan indeks asinkron selesai, Aurora DSQL memperbarui katalog sistem untuk menandai indeks sebagai aktif.
Perhatikan bahwa transaksi bersamaan yang mengakses objek di namespace yang sama selama pembaruan ini mungkin mengalami kesalahan konkurensi.
Ketika Aurora DSQL menyelesaikan tugas indeks asinkron, Aurora akan memperbarui katalog sistem untuk menunjukkan bahwa indeks aktif. Jika transaksi lain mereferensikan objek di namespace yang sama saat ini, Anda mungkin melihat kesalahan konkurensi.
## Sintaksis
`CREATE INDEX ASYNC`menggunakan sintaks berikut.
```
CREATE [ UNIQUE ] INDEX ASYNC [ IF NOT EXISTS ] name ON table_name
( { column_name } [ NULLS { FIRST | LAST } ] )
[ INCLUDE ( column_name [, ...] ) ]
[ NULLS [ NOT ] DISTINCT ]
```
## Parameter
**`UNIQUE`**
Menunjukkan ke Aurora DSQL untuk memeriksa nilai duplikat dalam tabel saat membuat indeks dan setiap kali Anda menambahkan data. Jika Anda menentukan parameter ini, menyisipkan dan memperbarui operasi yang akan menghasilkan entri duplikat menghasilkan kesalahan.
**`IF NOT EXISTS`**
Menunjukkan bahwa Aurora DSQL seharusnya tidak melempar pengecualian jika indeks dengan nama yang sama sudah ada. Dalam situasi ini, Aurora DSQL tidak membuat indeks baru. Perhatikan bahwa indeks yang Anda coba buat bisa memiliki struktur yang sangat berbeda dari indeks yang ada. Jika Anda menentukan parameter ini, nama indeks diperlukan.
**`name`**
Nama indeks. Anda tidak dapat menyertakan nama skema Anda dalam parameter ini.
Aurora DSQL membuat indeks dalam skema yang sama dengan tabel induknya. Nama indeks harus berbeda dari nama objek lain, seperti tabel atau indeks, dalam skema.
Jika Anda tidak menentukan nama, Aurora DSQL menghasilkan nama secara otomatis berdasarkan nama tabel induk dan kolom yang diindeks. Misalnya, jika Anda menjalankan`CREATE INDEX ASYNC on table1 (col1, col2)`, Aurora DSQL secara otomatis memberi nama indeks. `table1_col1_col2_idx`
**`NULLS FIRST | LAST`**
Urutan urutan kolom null dan non-null. `FIRST`menunjukkan bahwa Aurora DSQL harus mengurutkan kolom null sebelum kolom non-null. `LAST`menunjukkan bahwa Aurora DSQL harus mengurutkan kolom null setelah kolom non-null.
**`INCLUDE`**
Daftar kolom untuk disertakan dalam indeks sebagai kolom non-kunci. Anda tidak dapat menggunakan kolom non-kunci dalam kualifikasi pencarian pemindaian indeks. Aurora DSQL mengabaikan kolom dalam hal keunikan untuk indeks.
**`NULLS DISTINCT | NULLS NOT DISTINCT`**
Menentukan apakah Aurora DSQL harus mempertimbangkan nilai null sebagai berbeda dalam indeks unik. Defaultnya adalah`DISTINCT`, yang berarti bahwa indeks unik dapat berisi beberapa nilai null dalam kolom. `NOT DISTINCT`menunjukkan bahwa indeks tidak dapat berisi beberapa nilai null dalam kolom.
## Catatan penggunaan
Pertimbangkan panduan berikut ini:
+ `CREATE INDEX ASYNC`Perintah tidak memperkenalkan kunci. Ini juga tidak mempengaruhi tabel dasar yang Aurora DSQL gunakan untuk membuat indeks.
+ Selama operasi migrasi skema, `sys.wait_for_job(job_id)'your_index_creation_job_id'` prosedur ini berguna. Ini memastikan bahwa operasi DDL dan DML berikutnya menargetkan indeks yang baru dibuat.
+ Setiap kali Aurora DSQL menjalankan tugas asinkron baru, ia memeriksa `sys.jobs` tampilan dan menghapus tugas yang memiliki status atau selama lebih dari 30 menit. `completed` `failed` Dengan demikian, `sys.jobs` terutama menunjukkan tugas yang sedang berlangsung dan tidak berisi informasi tentang tugas-tugas lama.
+ Jika Aurora DSQL gagal membangun indeks asinkron, indeks tetap ada. `INVALID` Untuk indeks unik, operasi DHTML tunduk pada kendala keunikan sampai Anda menjatuhkan indeks. Kami menyarankan Anda menjatuhkan indeks yang tidak valid dan membuatnya kembali.
## Membuat indeks: contoh
Contoh berikut menunjukkan cara membuat skema, tabel, dan kemudian indeks.
1. Buat tabel bernama`test.departments`.
```
CREATE SCHEMA test;
CREATE TABLE test.departments (name varchar(255) primary key NOT null,
manager varchar(255),
size varchar(4));
```
1. Masukkan baris ke dalam tabel.
```
INSERT INTO test.departments VALUES ('Human Resources', 'John Doe', '10')
```
1. Buat indeks asinkron.
```
CREATE INDEX ASYNC test_index on test.departments(name, manager, size);
```
`CREATE INDEX`Perintah mengembalikan ID pekerjaan, seperti yang ditunjukkan di bawah ini.
```
job_id
--------------------------
jh2gbtx4mzhgfkbimtgwn5j45y
```
`job_id`Ini menunjukkan bahwa Aurora DSQL telah mengirimkan pekerjaan baru untuk membuat indeks. Anda dapat menggunakan prosedur `sys.wait_for_job(job_id)'your_index_creation_job_id'` untuk memblokir pekerjaan lain pada sesi sampai pekerjaan selesai atau habis waktu.
## Menanyakan status pembuatan indeks: contoh
Kueri tampilan `sys.jobs` sistem untuk memeriksa status pembuatan indeks Anda, seperti yang ditunjukkan pada contoh berikut.
```
SELECT * FROM sys.jobs where job_id = 'wqhu6ewifze5xitg3umt24h5ua';
```
Aurora DSQL mengembalikan respon yang mirip dengan berikut ini.
```
job_id | status | details | job_type | class_id | object_id | object_name | start_time | update_time
----------------------------+-----------+---------+-------------+----------+-----------+-------------------+------------------------+------------------------
wqhu6ewifze5xitg3umt24h5ua | completed | | INDEX_BUILD | 1259 | 26433 | public.nt2_c1_idx | 2025-09-25 22:07:31+00 | 2025-09-25 22:07:46+00
```
Kolom status dapat menjadi salah satu nilai berikut.
| Status | Deskripsi |
| --- | --- |
| submitted | Tugas dikirimkan, tetapi Aurora DSQL belum mulai memprosesnya. |
| processing | Aurora DSQL sedang memproses tugas. |
| failed | Tugas gagal. Lihat kolom detail untuk informasi lebih lanjut. Jika Aurora DSQL gagal membangun indeks, Aurora DSQL tidak secara otomatis menghapus definisi indeks. Anda harus menghapus indeks secara manual dengan DROP INDEX perintah. |
| completed | Aurora DSQL telah menyelesaikan tugas dengan sukses. |
Anda juga dapat menanyakan status indeks melalui tabel katalog `pg_index` dan`pg_class`. Secara khusus, atribut `indisvalid` dan `indisimmediate` dapat memberi tahu Anda status indeks Anda. Sementara Aurora DSQL membuat indeks Anda, ia memiliki status awal. `INVALID` `indisvalid`Bendera untuk indeks mengembalikan `FALSE` atau`f`, yang menunjukkan bahwa indeks tidak valid. Jika bendera kembali `TRUE` atau`t`, indeks sudah siap.
```
SELECT relname AS index_name, indisvalid as is_valid, pg_get_indexdef(indexrelid) AS index_definition
from pg_index, pg_class
WHERE pg_class.oid = indexrelid AND indrelid = 'test.departments'::regclass;
```
```
index_name | is_valid | index_definition
------------------+----------+-------------------------------------------------------------------------------------------------------------------
department_pkey | t | CREATE UNIQUE INDEX department_pkey ON test.departments USING btree_index (title) INCLUDE (name, manager, size)
test_index1 | t | CREATE INDEX test_index1 ON test.departments USING btree_index (name, manager, size)
```
## Kegagalan pembuatan indeks unik
Jika pekerjaan pembuatan indeks unik asinkron Anda menunjukkan status gagal dengan detail`Found duplicate key while validating index for UCVs`, ini menunjukkan bahwa indeks unik tidak dapat dibuat karena pelanggaran batasan keunikan.
**Untuk mengatasi kegagalan pembuatan indeks unik**
1. Hapus baris apa pun di tabel utama Anda yang memiliki entri duplikat untuk kunci yang ditentukan dalam indeks sekunder unik Anda.
1. Jatuhkan indeks yang gagal.
1. Keluarkan perintah buat indeks baru.
## Mendeteksi pelanggaran keunikan di tabel utama
Kueri SQL berikut membantu Anda mengidentifikasi nilai duplikat dalam kolom tertentu dari tabel Anda. Ini sangat berguna ketika Anda perlu menerapkan keunikan pada kolom yang saat ini tidak ditetapkan sebagai kunci utama atau tidak memiliki kendala unik, seperti alamat email dalam tabel pengguna.
Contoh di bawah ini menunjukkan cara membuat tabel pengguna sampel, mengisinya dengan data uji yang berisi duplikat yang diketahui, dan kemudian menjalankan kueri deteksi.
**Tentukan skema tabel**
```
-- Drop the table if it exists
DROP TABLE IF EXISTS users;
-- Create the users table with a simple integer primary key
CREATE TABLE users (
user_id INTEGER PRIMARY KEY,
email VARCHAR(255),
first_name VARCHAR(100),
last_name VARCHAR(100),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
```
**Masukkan data sampel yang mencakup kumpulan alamat email duplikat**
```
-- Insert sample data with explicit IDs
INSERT INTO users (user_id, email, first_name, last_name) VALUES
(1, 'john.doe@example.com', 'John', 'Doe'),
(2, 'jane.smith@example.com', 'Jane', 'Smith'),
(3, 'john.doe@example.com', 'Johnny', 'Doe'),
(4, 'alice.wong@example.com', 'Alice', 'Wong'),
(5, 'bob.jones@example.com', 'Bob', 'Jones'),
(6, 'alice.wong@example.com', 'Alicia', 'Wong'),
(7, 'bob.jones@example.com', 'Robert', 'Jones');
```
**Jalankan kueri deteksi duplikat**
```
-- Query to find duplicates
WITH duplicates AS (
SELECT email, COUNT(*) as duplicate_count
FROM users
GROUP BY email
HAVING COUNT(*) > 1
)
SELECT u.*, d.duplicate_count
FROM users u
INNER JOIN duplicates d ON u.email = d.email
ORDER BY u.email, u.user_id;
```
**Lihat semua catatan dengan alamat email duplikat**
```
user_id | email | first_name | last_name | created_at | duplicate_count
---------+------------------------+------------+-----------+----------------------------+-----------------
4 | akua.mansa@example.com | Akua | Mansa | 2025-05-21 20:55:53.714432 | 2
6 | akua.mansa@example.com | Akua | Mansa | 2025-05-21 20:55:53.714432 | 2
1 | john.doe@example.com | John | Doe | 2025-05-21 20:55:53.714432 | 2
3 | john.doe@example.com | Johnny | Doe | 2025-05-21 20:55:53.714432 | 2
(4 rows)
```
**Jika kita mencoba pernyataan pembuatan indeks sekarang, itu akan gagal:**
```
postgres=> CREATE UNIQUE INDEX ASYNC idx_users_email ON users(email);
job_id
----------------------------
ve32upmjz5dgdknpbleeca5tri
(1 row)
postgres=> select * from sys.jobs;
job_id | status | details | job_type | class_id | object_id | object_name | start_time | update_time
----------------------------+-----------+-----------------------------------------------------+-------------+----------+-----------+------------------------+------------------------+------------------------
qpn6aqlkijgmzilyidcpwrpova | completed | | DROP | 1259 | 26384 | | 2025-05-20 00:47:10+00 | 2025-05-20 00:47:32+00
ve32upmjz5dgdknpbleeca5tri | failed | Found duplicate key while validating index for UCVs | INDEX_BUILD | 1259 | 26396 | public.idx_users_email | 2025-05-20 00:49:49+00 | 2025-05-20 00:49:56+00
(2 rows)
```
# Tabel dan perintah sistem di Aurora DSQL
Lihat bagian berikut untuk mempelajari tentang tabel dan katalog sistem yang didukung di Aurora DSQL serta kueri yang berguna untuk mengambil informasi tentang sistem, seperti versi.
## Tabel sistem
[Aurora DSQL kompatibel dengan PostgreSQL, begitu banyak tabel [katalog sistem dan tampilan](https://www.PostgreSQL.org/docs/current/catalogs-overview.html) dari PostgreSQL juga ada di Aurora DSQL.](https://www.PostgreSQL.org/docs/current/views.html)
### Tabel dan tampilan katalog PostgreSQL penting
Tabel berikut menjelaskan tabel dan tampilan paling umum yang mungkin Anda gunakan di Aurora DSQL.
| Nama | Deskripsi |
| --- | --- |
| `pg_namespace` | Informasi tentang semua skema |
| `pg_tables` | Informasi tentang semua tabel |
| `pg_attribute` | Informasi tentang semua atribut |
| `pg_views` | Informasi tentang (pra-) tampilan yang ditentukan |
| `pg_class` | Menjelaskan semua tabel, kolom, indeks, dan objek serupa |
| `pg_stats` | Pandangan tentang statistik perencana |
| `pg_user` | Informasi tentang pengguna |
| `pg_roles` | Informasi tentang pengguna dan grup |
| `pg_indexes` | Daftar semua indeks |
| `pg_constraint` | Daftar kendala pada tabel |
### Tabel katalog yang didukung dan tidak didukung
Tabel berikut menunjukkan tabel mana yang didukung dan tidak didukung di Aurora DSQL.
| Nama | Berlaku untuk Aurora DSQL |
| --- | --- |
| `pg_aggregate` | Tidak |
| `pg_am` | Ya |
| `pg_amop` | Tidak |
| `pg_amproc` | Tidak |
| `pg_attrdef` | Ya |
| `pg_attribute` | Ya |
| `pg_authid` | Tidak (gunakan`pg_roles`) |
| `pg_auth_members` | Ya |
| `pg_cast` | Ya |
| `pg_class` | Ya |
| `pg_collation` | Ya |
| `pg_constraint` | Ya |
| `pg_conversion` | Tidak |
| `pg_database` | Tidak |
| `pg_db_role_setting` | Ya |
| `pg_default_acl` | Ya |
| `pg_depend` | Ya |
| `pg_description` | Ya |
| `pg_enum` | Tidak |
| `pg_event_trigger` | Tidak |
| `pg_extension` | Tidak |
| `pg_foreign_data_wrapper` | Tidak |
| `pg_foreign_server` | Tidak |
| `pg_foreign_table` | Tidak |
| `pg_index` | Ya |
| `pg_inherits` | Ya |
| `pg_init_privs` | Tidak |
| `pg_language` | Tidak |
| `pg_largeobject` | Tidak |
| `pg_largeobject_metadata` | Ya |
| `pg_namespace` | Ya |
| `pg_opclass` | Tidak |
| `pg_operator` | Ya |
| `pg_opfamily` | Tidak |
| `pg_parameter_acl` | Ya |
| `pg_partitioned_table` | Tidak |
| `pg_policy` | Tidak |
| `pg_proc` | Tidak |
| `pg_publication` | Tidak |
| `pg_publication_namespace` | Tidak |
| `pg_publication_rel` | Tidak |
| `pg_range` | Ya |
| `pg_replication_origin` | Tidak |
| `pg_rewrite` | Tidak |
| `pg_seclabel` | Tidak |
| `pg_sequence` | Tidak |
| `pg_shdepend` | Ya |
| `pg_shdescription` | Ya |
| `pg_shseclabel` | Tidak |
| `pg_statistic` | Ya |
| `pg_statistic_ext` | Tidak |
| `pg_statistic_ext_data` | Tidak |
| `pg_subscription` | Tidak |
| `pg_subscription_rel` | Tidak |
| `pg_tablespace` | Tidak |
| `pg_transform` | Tidak |
| `pg_trigger` | Tidak |
| `pg_ts_config` | Ya |
| `pg_ts_config_map` | Ya |
| `pg_ts_dict` | Ya |
| `pg_ts_parser` | Ya |
| `pg_ts_template` | Ya |
| `pg_type` | Ya |
| `pg_user_mapping` | Tidak |
### Tampilan sistem yang didukung dan tidak didukung
Tabel berikut menunjukkan tampilan mana yang didukung dan tidak didukung di Aurora DSQL.
| Nama | Berlaku untuk Aurora DSQL |
| --- | --- |
| `pg_available_extensions` | Tidak |
| `pg_available_extension_versions` | Tidak |
| `pg_backend_memory_contexts` | Ya |
| `pg_config` | Tidak |
| `pg_cursors` | Tidak |
| `pg_file_settings` | Tidak |
| `pg_group` | Ya |
| `pg_hba_file_rules` | Tidak |
| `pg_ident_file_mappings` | Tidak |
| `pg_indexes` | Ya |
| `pg_locks` | Tidak |
| `pg_matviews` | Tidak |
| `pg_policies` | Tidak |
| `pg_prepared_statements` | Tidak |
| `pg_prepared_xacts` | Tidak |
| `pg_publication_tables` | Tidak |
| `pg_replication_origin_status` | Tidak |
| `pg_replication_slots` | Tidak |
| `pg_roles` | Ya |
| `pg_rules` | Tidak |
| `pg_seclabels` | Tidak |
| `pg_sequences` | Tidak |
| `pg_settings` | Ya |
| `pg_shadow` | Ya |
| `pg_shmem_allocations` | Ya |
| `pg_stats` | Ya |
| `pg_stats_ext` | Tidak |
| `pg_stats_ext_exprs` | Tidak |
| `pg_tables` | Ya |
| `pg_timezone_abbrevs` | Ya |
| `pg_timezone_names` | Ya |
| `pg_user` | Ya |
| `pg_user_mappings` | Tidak |
| `pg_views` | Ya |
| `pg_stat_activity` | Tidak |
| `pg_stat_replication` | Tidak |
| `pg_stat_replication_slots` | Tidak |
| `pg_stat_wal_receiver` | Tidak |
| `pg_stat_recovery_prefetch` | Tidak |
| `pg_stat_subscription` | Tidak |
| `pg_stat_subscription_stats` | Tidak |
| `pg_stat_ssl` | Ya |
| `pg_stat_gssapi` | Tidak |
| `pg_stat_archiver` | Tidak |
| `pg_stat_io` | Tidak |
| `pg_stat_bgwriter` | Tidak |
| `pg_stat_wal` | Tidak |
| `pg_stat_database` | Tidak |
| `pg_stat_database_conflicts` | Tidak |
| `pg_stat_all_tables` | Tidak |
| `pg_stat_all_indexes` | Tidak |
| `pg_statio_all_tables` | Tidak |
| `pg_statio_all_indexes` | Tidak |
| `pg_statio_all_sequences` | Tidak |
| `pg_stat_slru` | Tidak |
| `pg_statio_user_tables` | Tidak |
| `pg_statio_user_sequences` | Tidak |
| `pg_stat_user_functions` | Tidak |
| `pg_stat_user_indexes` | Tidak |
| `pg_stat_progress_analyze` | Tidak |
| `pg_stat_progress_basebackup` | Tidak |
| `pg_stat_progress_cluster` | Tidak |
| `pg_stat_progress_create_index` | Tidak |
| `pg_stat_progress_vacuum` | Tidak |
| `pg_stat_sys_indexes` | Tidak |
| `pg_stat_sys_tables` | Tidak |
| `pg_stat_xact_all_tables` | Tidak |
| `pg_stat_xact_sys_tables` | Tidak |
| `pg_stat_xact_user_functions` | Tidak |
| `pg_stat_xact_user_tables` | Tidak |
| `pg_statio_sys_indexes` | Tidak |
| `pg_statio_sys_sequences` | Tidak |
| `pg_statio_sys_tables` | Tidak |
| `pg_statio_user_indexes` | Tidak |
### Tampilan sys.jobs
`sys.jobs`memberikan informasi status tentang pekerjaan asinkron. Misalnya, setelah Anda [membuat indeks asinkron, Aurora DSQL](working-with-create-index-async.md) mengembalikan file. `job_uuid` Anda dapat menggunakan ini `job_uuid` `sys.jobs` untuk mencari status pekerjaan.
```
SELECT * FROM sys.jobs;
```
Aurora DSQL mengembalikan respon yang mirip dengan berikut ini.
```
job_id | status | details | job_type | class_id | object_id | object_name | start_time | update_time
----------------------------+-----------+---------+-------------+----------+-----------+-------------------+------------------------+------------------------
wqhu6ewifze5xitg3umt24h5ua | completed | | INDEX_BUILD | 1259 | 26433 | public.nt2_c1_idx | 2025-09-25 22:07:31+00 | 2025-09-25 22:07:46+00
kkngzf33dndl3daacxehpx5eba | completed | | ANALYZE | 1259 | 26419 | public.nt | 2025-09-25 21:57:05+00 | 2025-09-25 21:57:27+00
fyopxjb6ovdn7po6lrkj63cyea | completed | | DROP | 1259 | 26422 | | 2025-09-25 22:05:57+00 | 2025-09-25 22:06:03+00
```
Tabel berikut menjelaskan kolom dalam `sys.jobs` tampilan.
**sys.jobs lihat kolom**
| Kolom | Jenis | Deskripsi |
| --- | --- | --- |
| job\$1id | text | UUID basis-32 yang mewakili pekerjaan. |
| status | text | Status pekerjaan saat ini. Nilai yang mungkin adalah submitted, processing, completed, dan failed. Untuk informasi selengkapnya, lihat [nilai status sys.jobs](#dsql-sys-jobs-status-values). |
| details | text | Setiap detail yang relevan tentang pekerjaan itu. Jika pekerjaan gagal, alasan terperinci disediakan. |
| job\$1type | text | Jenis pekerjaan asinkron. Nilai yang mungkin adalah: INDEX\$1BUILD — build indeks asinkron. ANALYZE— pekerjaan analisis otomatis yang dikirimkan sistem. DROPMenghapus data fisik setelah DROP INDEX operasi DROP TABLE atau |
| class\$1id | oid | OID dari tabel katalog yang berisi objek. |
| object\$1id | oid | OID objek. |
| object\$1name | text | Nama objek yang sepenuhnya memenuhi syarat. DROPpekerjaan tidak dapat mereferensikan objek yang sudah dijatuhkan. Jika objek yang direferensikan telah dijatuhkan, object\$1name mungkin NULL. |
| start\$1time | timestamp with time zone | Stempel waktu di mana pekerjaan itu diserahkan. |
| update\$1time | timestamp with time zone | Stempel waktu di mana baris pekerjaan terakhir diperbarui. |
**nilai status sys.jobs**
| Status | Deskripsi |
| --- | --- |
| submitted | Tugas dikirimkan, tetapi Aurora DSQL belum mulai memprosesnya. |
| processing | Aurora DSQL sedang memproses tugas. |
| failed | Tugas gagal. Lihat details kolom untuk informasi lebih lanjut. |
| completed | Aurora DSQL telah menyelesaikan tugas dengan sukses. |
### Tampilan sys.iam\$1pg\$1role\$1mappings
Tampilan `sys.iam_pg_role_mappings` memberikan informasi tentang izin yang diberikan kepada pengguna IAM. Misalnya, jika `DQSLDBConnect` peran IAM yang memberikan Aurora DSQL akses ke non-admin dan pengguna `testuser` bernama diberikan `DQSLDBConnect` peran dan izin yang sesuai, Anda dapat menanyakan tampilan untuk melihat pengguna mana yang diberikan izin `sys.iam_pg_role_mappings` mana.
```
SELECT * FROM sys.iam_pg_role_mappings;
```
## Kueri metadata sistem yang berguna
Gunakan kueri ini untuk mendapatkan statistik tabel dan metadata sistem tanpa melakukan operasi mahal seperti pemindaian tabel penuh.
### Dapatkan perkiraan jumlah baris untuk tabel
Untuk mendapatkan perkiraan hitungan baris dalam tabel tanpa melakukan pemindaian tabel lengkap, gunakan kueri berikut:
```
SELECT reltuples FROM pg_class WHERE relname = 'table_name';
```
Perintah tersebut mengembalikan output serupa dengan berikut ini:
```
reltuples
--------------
9.993836e+08
```
Pendekatan ini lebih efisien daripada `SELECT COUNT(*)` tabel besar di Aurora DSQL.
### Dapatkan versi utama Aurora DSQL saat ini
Untuk mendapatkan versi utama cluster Aurora DSQL saat ini, gunakan kueri berikut:
```
SELECT * FROM sys.dsql_major_version();
```
Perintah tersebut mengembalikan output serupa dengan berikut ini:
```
dsql_major_version
--------------------
1
```
Ini mengembalikan versi utama koneksi SQL di Aurora DSQL.
### Dapatkan versi PostgreSQL saat ini
Untuk mendapatkan versi PostgreSQL cluster Aurora DSQL saat ini, gunakan kueri berikut:
```
SHOW server_version;
```
Perintah tersebut mengembalikan output serupa dengan berikut ini:
```
server_version
----------------
16.13
```
Ini mengembalikan versi PostgreSQL koneksi SQL di Aurora DSQL.
## `ANALYZE`Perintah
`ANALYZE `Perintah mengumpulkan statistik tentang isi tabel dalam database dan menyimpan hasilnya dalam tampilan `pg_stats` sistem. Selanjutnya, perencana kueri menggunakan statistik ini untuk membantu menentukan rencana eksekusi yang paling efisien untuk kueri.
Di Aurora DSQL, Anda tidak dapat menjalankan `ANALYZE` perintah dalam transaksi eksplisit. `ANALYZE`tidak tunduk pada batas batas waktu transaksi database.
Untuk mengurangi kebutuhan intervensi manual dan menjaga statistik tetap up to date, Aurora DSQL secara otomatis berjalan `ANALYZE` sebagai proses latar belakang. Pekerjaan latar belakang ini dipicu secara otomatis berdasarkan tingkat perubahan yang diamati dalam tabel. Ini terkait dengan jumlah baris (tupel) yang telah dimasukkan, diperbarui, atau dihapus sejak analisis terakhir.
`ANALYZE`berjalan secara asinkron di latar belakang dan aktivitasnya dapat dipantau dalam tampilan sistem sys.jobs dengan kueri berikut:
```
SELECT * FROM sys.jobs WHERE job_type = 'ANALYZE';
```
**Pertimbangan utama**
**catatan**
`ANALYZE`pekerjaan ditagih seperti pekerjaan asinkron lainnya di Aurora DSQL. Saat Anda memodifikasi tabel, ini secara tidak langsung dapat memicu pekerjaan pengumpulan statistik latar belakang otomatis, yang dapat mengakibatkan biaya pengukuran karena aktivitas tingkat sistem terkait.
`ANALYZE`Pekerjaan latar belakang, dipicu secara otomatis, mengumpulkan jenis statistik yang sama dengan manual `ANALYZE` dan menerapkannya secara default ke tabel pengguna. Tabel sistem dan katalog dikecualikan dari proses otomatis ini.
# Bekerja dengan rencana Aurora DSQL EXPLY
Aurora DSQL menggunakan struktur rencana EXPLORE yang mirip dengan PostgreSQL, tetapi dengan penambahan kunci yang mencerminkan arsitektur terdistribusi dan model eksekusi.
Dalam dokumentasi ini, kami akan memberikan gambaran umum tentang rencana Aurora DSQL EXPLORE, menyoroti persamaan dan perbedaan dibandingkan dengan PostgreSQL. Kami akan membahas berbagai jenis operasi pemindaian yang tersedia di Aurora DSQL dan membantu Anda memahami biaya menjalankan kueri Anda.
## PostgreSQL VS Aurora DSQL JELASKAN rencana
Aurora DSQL dibangun di atas database PostgreSQL dan berbagi sebagian besar struktur rencana dengan PostgreSQL, tetapi memiliki perbedaan arsitektur utama yang mempengaruhi eksekusi dan pengoptimalan kueri:
| Fitur | PostgreSQL | Aurora DSQL |
| --- | --- | --- |
| Penyimpanan Data | Penyimpanan Tumpukan | Tidak ada tumpukan, semua baris diindeks oleh pengidentifikasi unik |
| Kunci Utama | Indeks kunci primer terpisah dari data tabel | Indeks kunci primer adalah tabel dengan semua kolom tambahan sebagai kolom INCLUDE |
| Indeks Sekunder | Indeks sekunder standar | Bekerja sama dengan PostgreSQL, dengan kemampuan untuk menyertakan kolom non-kunci |
| Kemampuan Penyaringan | Kondisi Indeks, Filter Tumpukan | Kondisi Indeks, Filter Penyimpanan, Filter Prosesor Kueri |
| Jenis Pindai | Pemindaian Berurutan, Pemindaian Indeks, Pemindaian Hanya Indeks | Pemindaian Penuh, Pemindaian Hanya Indeks, Pemindaian Indeks |
| Eksekusi Kueri | Lokal ke Database | Didistribusikan (komputasi dan penyimpanan terpisah) |
Aurora DSQL menyimpan data tabel secara langsung dalam urutan kunci primer daripada di tumpukan terpisah. Setiap baris diidentifikasi oleh kunci unik, biasanya kunci utama, yang memungkinkan database untuk mengoptimalkan pencarian lebih efisien. Perbedaan arsitektur menjelaskan mengapa Aurora DSQL sering menggunakan Index Only Scan dalam kasus di mana PostgreSQL mungkin memilih pemindaian sekuensial.
Perbedaan utama lainnya adalah bahwa Aurora DSQL memisahkan komputasi dari penyimpanan, memungkinkan filter diterapkan sebelumnya di jalur eksekusi untuk mengurangi pergerakan data dan meningkatkan kinerja.
[Untuk selengkapnya menggunakan rencana EXPLORE dengan PostgreSQL, lihat dokumentasi PostgreSQL EXPLORE.](https://www.postgresql.org/docs/current/using-explain.html)
## Elemen kunci dalam rencana Aurora DSQL JELASKAN
Rencana Aurora DSQL EXPLOW memberikan informasi rinci tentang bagaimana kueri dijalankan, termasuk di mana pemfilteran terjadi dan kolom mana yang diambil dari penyimpanan. Memahami keluaran ini membantu Anda mengoptimalkan kinerja kueri.
Indeks Cond
Kondisi yang digunakan untuk menavigasi indeks. Pemfilteran paling efisien yang mengurangi data yang dipindai. Di Aurora DSQL, kondisi indeks dapat diterapkan pada beberapa lapisan rencana eksekusi.
Proyeksi
Kolom diambil dari penyimpanan. Proyeksi yang lebih sedikit berarti kinerja yang lebih baik.
Filter Penyimpanan
Kondisi diterapkan pada tingkat penyimpanan. Lebih efisien daripada filter prosesor kueri.
Filter Prosesor Kueri
Kondisi diterapkan pada tingkat prosesor kueri. Memerlukan transfer semua data sebelum penyaringan, yang menghasilkan pergerakan data yang lebih tinggi dan overhead pemrosesan.
## Filter dalam Aurora DSQL
Aurora DSQL memisahkan komputasi dari penyimpanan, yang berarti bahwa titik di mana filter diterapkan selama eksekusi kueri memiliki dampak signifikan pada kinerja. Filter yang diterapkan sebelum volume besar data ditransfer mengurangi latensi dan meningkatkan efisiensi. Semakin awal filter diterapkan, semakin sedikit data yang perlu diproses, dipindahkan, dan dipindai, menghasilkan kueri yang lebih cepat.
Aurora DSQL dapat menerapkan filter pada beberapa tahap di jalur kueri. Memahami tahapan ini adalah kunci untuk menafsirkan rencana kueri dan mengoptimalkan kinerja.
| Tingkat | Jenis Filter | Deskripsi |
| --- | --- | --- |
| 1 | Kondisi Indeks | Diterapkan saat memindai indeks. Membatasi berapa banyak data yang dibaca dari penyimpanan dan mengurangi data yang dikirim ke lapisan komputasi. |
| 2 | Filter Penyimpanan | Diterapkan setelah data dibaca dari penyimpanan tetapi sebelum dikirim ke komputasi. Contoh di sini adalah filter pada kolom include indeks. Mengurangi transfer data tetapi bukan jumlah yang dibaca. |
| 3 | Filter Prosesor Kueri | Diterapkan setelah data mencapai lapisan komputasi. Semua data harus ditransfer terlebih dahulu, yang meningkatkan latensi dan biaya. Saat ini, Aurora DSQL tidak dapat melakukan semua operasi penyaringan dan proyeksi pada penyimpanan, sehingga beberapa kueri mungkin terpaksa kembali ke jenis penyaringan ini. |
# Membaca Aurora DSQL JELASKAN rencana
Memahami cara membaca rencana EXPLORE adalah kunci untuk mengoptimalkan kinerja kueri. Di bagian ini, kita akan menelusuri contoh nyata dari rencana kueri Aurora DSQL, menunjukkan bagaimana berbagai jenis pemindaian berperilaku, menjelaskan di mana filter diterapkan, dan menyoroti peluang untuk pengoptimalan.
## Tabel sampel yang digunakan dalam contoh-contoh ini
Contoh di bawah ini merujuk dua tabel: `transaction` dan`account`.
`transaction`Tabel tidak memiliki kunci utama, yang menyebabkan Aurora DSQL melakukan pemindaian tabel penuh saat menanyakannya.
`account`Tabel memiliki indeks pada`customer_id`. Indeks ini mencakup `balance` dan `status` sebagai kolom penutup, yang memungkinkan kueri tertentu dipenuhi langsung dari indeks tanpa membaca dari tabel dasar. Namun, indeks tidak termasuk`created_at`, sehingga kueri yang merujuk kolom ini memerlukan akses tabel tambahan.
```
CREATE TABLE transaction (
account_id uuid,
transaction_date timestamp,
description text
);
CREATE TABLE account (
customer_id uuid,
balance numeric,
status varchar,
created_at timestamp
);
CREATE INDEX ASYNC idx1 ON account (customer_id) INCLUDE (balance, status);
```
## Contoh Pemindaian Lengkap
Aurora DSQL memiliki Pemindaian Berurutan, yang secara fungsional identik dengan PostgreSQL, serta Pemindaian Penuh. Satu-satunya perbedaan antara keduanya adalah bahwa Full Scan dapat memanfaatkan penyaringan ekstra pada penyimpanan. Karena ini, hampir selalu dipilih di atas Pemindaian Berurutan. Karena kesamaannya, kami hanya akan membahas contoh Pemindaian Penuh yang lebih menarik.
Pemindaian Penuh sebagian besar akan digunakan pada tabel tanpa kunci utama. Karena kunci primer Aurora DSQL secara default mencakup indeks penuh, Aurora DSQL kemungkinan besar akan menggunakan Index Only Scan pada kunci utama dalam banyak situasi di mana PostgreSQL akan menggunakan Sequential Scan. Seperti kebanyakan database lainnya, tabel tanpa indeks di atasnya akan berskala buruk.
```
EXPLAIN SELECT account_id FROM transaction WHERE transaction_date > '2025-01-01' AND description LIKE '%external%';
```
```
QUERY PLAN
----------------------------------------------------------------------------------------------------------------
Full Scan (btree-table) on transaction (cost=125100.05..177933.38 rows=33333 width=16)
Filter: (description ~~ '%external%'::text)
-> Storage Scan on transaction (cost=12510.05..17793.38 rows=66666 width=16)
Projections: account_id, description
Filters: (transaction_date > '2025-01-01 00:00:00'::timestamp without time zone)
-> B-Tree Scan on transaction (cost=12510.05..17793.38 rows=100000 width=30)
```
Rencana ini menunjukkan dua filter yang diterapkan pada tahap yang berbeda. `transaction_date > '2025-01-01'`Kondisi ini diterapkan pada lapisan penyimpanan, mengurangi berapa banyak data yang dikembalikan. `description LIKE '%external%'`Kondisi ini diterapkan kemudian di prosesor kueri, setelah data ditransfer, membuatnya kurang efisien. Mendorong filter yang lebih selektif ke dalam lapisan penyimpanan atau indeks umumnya meningkatkan kinerja.
## Contoh Index Only Scan
Index Only Scan adalah jenis pemindaian yang paling optimal di Aurora DSQL karena menghasilkan perjalanan pulang pergi paling sedikit ke lapisan penyimpanan dan dapat melakukan pemfilteran paling banyak. Tetapi hanya karena Anda melihat Index Only Scan tidak berarti Anda memiliki rencana terbaik. Karena semua tingkat penyaringan yang berbeda yang dapat terjadi, penting untuk tetap memperhatikan berbagai tempat penyaringan dapat terjadi.
```
EXPLAIN SELECT balance FROM account
WHERE customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'
AND balance > 100
AND status = 'pending';
```
```
QUERY PLAN
-------------------------------------------------------------------------------
Index Only Scan using idx1 on account (cost=725.05..1025.08 rows=8 width=18)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
Filter: (balance > '100'::numeric)
-> Storage Scan on idx1 (cost=12510.05..17793.38 rows=9 width=16)
Projections: balance
Filters: ((status)::text = 'pending'::text)
-> B-Tree Scan on idx1 (cost=12510.05..17793.38 rows=10 width=30)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
```
Dalam rencana ini, kondisi indeks,`customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'`), dievaluasi terlebih dahulu selama pemindaian indeks, yang merupakan tahap paling efisien karena membatasi berapa banyak data yang dibaca dari penyimpanan. Filter penyimpanan`status = 'pending'`,, diterapkan setelah data dibaca tetapi sebelum dikirim ke lapisan komputasi, mengurangi jumlah data yang ditransfer. Akhirnya, filter prosesor kueri`balance > 100`,, berjalan terakhir, setelah data dipindahkan, membuatnya paling tidak efisien. Dari jumlah tersebut, kondisi indeks memberikan kinerja terbesar karena secara langsung mengontrol berapa banyak data yang dipindai.
## Contoh Pemindaian Indeks
Index Scan mirip dengan Index Only Scan, kecuali mereka memiliki langkah ekstra untuk memanggil ke tabel dasar. Karena Aurora DSQL dapat menentukan filter penyimpanan, ia dapat melakukannya baik pada panggilan indeks maupun panggilan pencarian.
Untuk memperjelas hal ini, Aurora DSQL menyajikan rencana sebagai dua node. Dengan cara ini, Anda dapat dengan jelas melihat seberapa banyak menambahkan kolom include akan membantu dalam hal baris yang dikembalikan dari penyimpanan.
```
EXPLAIN SELECT balance FROM account
WHERE customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'
AND balance > 100
AND status = 'pending'
AND created_at > '2025-01-01';
```
```
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Index Scan using idx1 on account (cost=728.18..1132.20 rows=3 width=18)
Filter: (balance > '100'::numeric)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
-> Storage Scan on idx1 (cost=12510.05..17793.38 rows=8 width=16)
Projections: balance
Filters: ((status)::text = 'pending'::text)
-> B-Tree Scan on account (cost=12510.05..17793.38 rows=10 width=30)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
-> Storage Lookup on account (cost=12510.05..17793.38 rows=4 width=16)
Filters: (created_at > '2025-01-01 00:00:00'::timestamp without time zone)
-> B-Tree Lookup on transaction (cost=12510.05..17793.38 rows=8 width=30)
```
Rencana ini menunjukkan bagaimana penyaringan terjadi di beberapa tahap:
+ Kondisi indeks pada data `customer_id ` filter lebih awal.
+ Filter penyimpanan pada `status` lebih lanjut mempersempit hasil sebelum dikirim ke komputasi.
+ Filter prosesor kueri pada `balance` diterapkan kemudian, setelah transfer.
+ Filter pencarian `created_at` dievaluasi saat mengambil kolom tambahan dari tabel dasar.
Menambahkan kolom yang sering digunakan sebagai `INCLUDE` bidang seringkali dapat menghilangkan pencarian ini dan meningkatkan kinerja.
## Praktik Terbaik
+ **Sejajarkan filter dengan kolom yang diindeks** untuk mendorong pemfilteran sebelumnya.
+ **Gunakan kolom INCLUDE** untuk mengizinkan Pemindaian Hanya Indeks dan menghindari pencarian.
+ **Validasi estimasi baris** saat menyelidiki masalah kinerja. Aurora DSQL mengelola statistik secara otomatis dengan berjalan `ANALYZE` di latar belakang berdasarkan tingkat perubahan data. Jika perkiraan tampak tidak akurat, Anda dapat menjalankan `ANALYZE` secara manual untuk menyegarkan statistik segera.
+ **Hindari kueri yang tidak diindeks** pada tabel besar untuk mencegah Pemindaian Penuh yang mahal.
# Memahami DPUs dalam EXPLY ANALYSIS
Aurora DSQL menyediakan informasi Distributed Processing Unit (DPU) **tingkat pernyataan** dalam output `EXPLAIN ANALYZE VERBOSE` rencana, memberi Anda visibilitas yang lebih dalam ke biaya kueri selama pengembangan. Bagian ini menjelaskan DPUs apa dan bagaimana menafsirkannya dalam `EXPLAIN ANALYZE VERBOSE` output.
## Apa itu DPU?
Distributed Processing Unit (DPU) adalah ukuran normalisasi dari pekerjaan yang dilakukan oleh Aurora DSQL. Ini terdiri dari:
+ **ComputedPU** - Waktu yang dihabiskan untuk mengeksekusi kueri SQL
+ **ReadDPU** — Sumber daya yang digunakan untuk membaca data dari penyimpanan
+ **WriteDPU** - Sumber daya yang digunakan untuk menulis data ke penyimpanan
+ **MultiRegionWriteDPU** — Sumber daya yang digunakan untuk mereplikasi penulisan ke cluster peered dalam konfigurasi Multi-wilayah.
## Penggunaan DPU di EXPLY ANALYZE VERBOSE
Aurora DSQL diperluas `EXPLAIN ANALYZE VERBOSE` untuk menyertakan perkiraan penggunaan DPU tingkat pernyataan hingga akhir output. Ini memberikan visibilitas langsung ke biaya kueri, membantu Anda mengidentifikasi driver biaya beban kerja, menyesuaikan kinerja kueri, dan perkiraan penggunaan sumber daya yang lebih baik.
Contoh berikut menunjukkan bagaimana menafsirkan estimasi DPU tingkat pernyataan yang termasuk dalam EXPLORE ANALYZE VERBOSE output.
### Contoh 1: SELECT Query
```
EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;
```
```
QUERY PLAN
----------------------------------------------------
Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1)
Output: id, context
-> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Projections: id, context
-> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Query Identifier: qymgw1m77maoe
Planning Time: 11.415 ms
Execution Time: 4.528 ms
Statement DPU Estimate:
Compute: 0.01607 DPU
Read: 0.04312 DPU
Write: 0.00000 DPU
Total: 0.05919 DPU
```
Dalam contoh ini, pernyataan SELECT melakukan pemindaian indeks saja, sehingga sebagian besar biaya berasal dari Baca DPU (0,04312), mewakili data yang diambil dari penyimpanan dan Compute DPU (0,01607), yang mencerminkan sumber daya komputasi yang digunakan untuk memproses dan mengembalikan hasilnya. Tidak ada Write DPU karena kueri tidak mengubah data. Total DPU (0,05919) adalah jumlah dari Compute \$1 Read\$1Write.
### Contoh 2: INSERT Query
```
EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');
```
```
QUERY PLAN
----------------------------------------------------
Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1)
-> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1)
Output: "*VALUES*".column1, "*VALUES*".column2
Query Identifier: jtkjkexhjotbo
Planning Time: 0.068 ms
Execution Time: 0.543 ms
Statement DPU Estimate:
Compute: 0.01550 DPU
Read: 0.00307 DPU (Transaction minimum: 0.00375)
Write: 0.01875 DPU (Transaction minimum: 0.05000)
Total: 0.03732 DPU
```
Pernyataan ini terutama melakukan penulisan, sehingga sebagian besar biaya dikaitkan dengan Tulis DPU. Compute DPU (0,01550) mewakili pekerjaan yang dilakukan untuk memproses dan menyisipkan nilai. DPU Baca (0,00307) mencerminkan pembacaan sistem minor (untuk pencarian katalog atau pemeriksaan indeks).
Perhatikan minimum Transaksi yang ditampilkan di samping Baca dan Tulis DPUs. Ini menunjukkan biaya dasar per transaksi yang berlaku *hanya ketika operasi termasuk* membaca atau menulis. Bukan berarti setiap transaksi otomatis dikenakan biaya 0,00375 Read DPU atau 0,05 Write DPU. Sebaliknya, minimum ini diterapkan pada tingkat transaksi selama agregasi biaya dan hanya jika pembacaan atau penulisan terjadi dalam transaksi itu. Karena perbedaan ruang lingkup ini, perkiraan tingkat pernyataan `EXPLAIN ANALYZE VERBOSE` mungkin tidak sama persis dengan metrik tingkat transaksi yang dilaporkan dalam atau data penagihan. CloudWatch
## Menggunakan Informasi DPU untuk Optimalisasi
Perkiraan DPU per pernyataan memberi Anda cara yang ampuh untuk mengoptimalkan kueri di luar waktu eksekusi. Kasus penggunaan umum meliputi:
+ **Kesadaran Biaya:** Memahami seberapa mahal kueri relatif terhadap orang lain.
+ **Optimasi Skema:** Bandingkan dampak indeks atau perubahan skema pada kinerja dan efisiensi sumber daya.
+ **Perencanaan Anggaran:** Perkirakan biaya beban kerja berdasarkan penggunaan DPU yang diamati.
+ **Perbandingan Kueri:** Evaluasi pendekatan kueri alternatif dengan konsumsi DPU relatifnya.
## Menafsirkan Informasi DPU
Ingatlah praktik terbaik berikut saat menggunakan data DPU dari`EXPLAIN ANALYZE VERBOSE`:
+ **Gunakan secara terarah:** Perlakukan DPU yang dilaporkan sebagai cara untuk memahami biaya *relatif* kueri daripada kecocokan persis dengan CloudWatch metrik atau data penagihan. Perbedaan diharapkan karena `EXPLAIN ANALYZE VERBOSE` melaporkan biaya tingkat pernyataan, sementara CloudWatch agregat aktivitas tingkat transaksi. CloudWatch juga mencakup operasi latar belakang (seperti ANALISIS atau pemadatan) dan overhead transaksi (`BEGIN`/`COMMIT`) yang `EXPLAIN ANALYZE VERBOSE` sengaja dikecualikan.
+ **Variabilitas DPU di seluruh proses normal** dalam sistem terdistribusi dan tidak menunjukkan kesalahan. Faktor-faktor seperti caching, perubahan rencana eksekusi, konkurensi, atau pergeseran dalam distribusi data semuanya dapat menyebabkan kueri yang sama mengkonsumsi sumber daya yang berbeda dari satu proses ke yang berikutnya.
+ **Operasi kecil batch:** Jika beban kerja Anda mengeluarkan banyak pernyataan kecil, pertimbangkan untuk mengelompokkannya ke dalam operasi yang lebih besar (tidak melebihi 10MB). Ini mengurangi overhead pembulatan dan menghasilkan perkiraan biaya yang lebih berarti.
+ **Gunakan untuk penyetelan, bukan penagihan:** Data DPU `EXPLAIN ANALYZE VERBOSE` dirancang untuk kesadaran biaya, penyetelan kueri, dan pengoptimalan. Ini bukan metrik tingkat penagihan. Selalu mengandalkan CloudWatch metrik atau laporan penagihan bulanan untuk data biaya dan penggunaan otoritatif.