Meningkatkan performa kueri untuk Aurora PostgreSQL dengan Aurora Optimized Reads - Amazon Aurora
Gambaran umum Aurora Optimized Reads di PostgreSQLPenggunaanKasus penggunaanMemantauPraktik terbaik

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

Meningkatkan performa kueri untuk Aurora PostgreSQL dengan Aurora Optimized Reads

Anda dapat mencapai pemrosesan kueri yang lebih cepat untuk Aurora PostgreSQL dengan Aurora Optimized Reads. Instans DB Aurora PostgreSQL yang menggunakan Aurora Optimized Reads memberikan latensi kueri hingga 8x lebih baik dan penghematan biaya hingga 30% untuk aplikasi dengan set data besar, yang melebihi kapasitas memori instans DB.

Gambaran umum Aurora Optimized Reads di PostgreSQL

Aurora Optimized Reads tersedia secara default saat Anda membuat klaster DB yang menggunakan instans R6gd berbasis Graviton dan R6id berbasis Intel dengan penyimpanan non-volatile memory express (NVMe). Fitur ini tersedia dari versi PostgreSQL berikut:

  • 16.1 dan semua versi yang lebih tinggi

  • 15.4 dan versi yang lebih tinggi

  • 14.9 dan versi yang lebih tinggi

Aurora Optimized Reads mendukung dua kemampuan: cache berjenjang dan objek sementara.

Cache berjenjang yang didukung Optimized Reads - Menggunakan cache berjenjang, Anda dapat memperluas kapasitas caching instans DB hingga 5x memori instans. Kemampuan ini secara otomatis mempertahankan cache untuk menyimpan data terbaru yang konsisten secara transaksional, sehingga membebaskan aplikasi dari overhead dalam mengelola keterkinian data dalam solusi caching berbasis hasil set eksternal. Kemampuan ini menawarkan latensi hingga 8x lebih baik untuk kueri yang sebelumnya mengambil data dari penyimpanan Aurora.

Di Aurora, nilai untuk shared_buffers dalam kelompok parameter default biasanya diatur ke sekitar 75% dari memori yang tersedia. Namun, untuk jenis instans r6gd dan r6id, Aurora akan mengurangi shared_buffers ruang sebesar 4,5% untuk meng-host metadata untuk cache Bacaan yang Dioptimalkan.

Objek sementara yang didukung Optimized Reads - Menggunakan objek sementara, Anda dapat mencapai pemrosesan kueri yang lebih cepat dengan menempatkan file sementara yang dihasilkan oleh PostgreSQL pada penyimpanan NVMe lokal. Kemampuan ini mengurangi lalu lintas ke Elastic Block Storage (EBS) melalui jaringan. Ini menawarkan latensi dan throughput hingga 2x lebih baik untuk kueri lanjutan yang mengurutkan, menggabungkan, atau menggabungkan volume besar data yang tidak sesuai dengan kapasitas memori yang tersedia pada instans DB.

Pada klaster Aurora I/O Dioptimalkan, Optimized Reads menggunakan cache berjenjang dan objek sementara pada penyimpanan NVMe. Dengan kemampuan cache berjenjang yang didukung Optimized Reads, Aurora mengalokasikan 2x memori instans untuk objek sementara, sekitar 10% penyimpanan untuk operasi internal, dan penyimpanan yang tersisa sebagai cache berjenjang. Pada klaster Standar Aurora, Optimized Reads hanya menggunakan objek sementara.

Mesin Konfigurasi penyimpanan klaster Objek sementara yang didukung Optimized Reads Cache berjenjang yang didukung Optimized Reads Versi yang didukung
yang kompatibel dengan Aurora PostgreSQL Standar Ya Tidak Aurora PostgreSQL versi 16.1 dan semua versi yang lebih tinggi, 15.4 dan lebih tinggi, versi 14.9 dan lebih tinggi
I/O Dioptimalkan Ya Ya
catatan

Peralihan antara klaster I/O Dioptimalkan dan Standar pada kelas instans DB berbasis NVMe akan menyebabkan pengaktifan ulang mesin basis data langsung.

Di Aurora PostgreSQL, gunakan temp_tablespaces parameter untuk mengkonfigurasi ruang tabel tempat objek sementara disimpan.

Untuk memeriksa apakah objek sementara dikonfigurasi, gunakan perintah berikut:

postgres=> show temp_tablespaces;
temp_tablespaces
---------------------
aurora_temp_tablespace
(1 row)

aurora_temp_tablespace adalah ruang tabel yang dikonfigurasi oleh Aurora yang menunjuk ke penyimpanan lokal NVMe. Anda tidak dapat mengubah parameter ini atau beralih kembali ke penyimpanan Amazon EBS.

Untuk memeriksa apakah cache baca yang dioptimalkan diaktifkan, gunakan perintah berikut:

postgres=> show shared_preload_libraries;
                 shared_preload_libraries
--------------------------------------------------------
rdsutils,pg_stat_statements,aurora_optimized_reads_cache

Menggunakan Aurora Optimized Reads

Saat Anda menyediakan instans DB PostgreSQL Aurora dengan salah satu instans DB berbasis NVME, instans DB secara otomatis menggunakan Aurora Optimized Reads.

Untuk mengaktifkan Aurora Optimized Reads, lakukan salah satu hal berikut ini:

Bacaan yang Dioptimalkan Aurora tersedia di semua Wilayah AWS tempat di mana satu atau lebih kelas instans DB dengan penyimpanan SSD NVMe lokal didukung. Untuk informasi selengkapnya, lihat Kelas instans DB Aurora.

Untuk beralih kembali ke instance Aurora pembacaan yang tidak dioptimalkan, ubah kelas instans DB instance Aurora Anda ke kelas instance serupa tanpa penyimpanan sementara NVMe untuk beban kerja database Anda. Misalnya, jika kelas instans DB saat ini adalah db.r6gd.4xlarge, pilih db.r6g.4xlarge untuk beralih kembali. Untuk informasi selengkapnya, lihat Memodifikasi instans Aurora DB.

Kasus penggunaan untuk Aurora Optimized Reads

Cache berjenjang yang didukung Optimized Reads

Berikut ini adalah beberapa kasus penggunaan yang dapat memperoleh manfaat dari Optimized Reads dengan cache berjenjang:

  • Aplikasi skala internet seperti pemrosesan pembayaran, penagihan, e-commerce dengan SLA performa yang ketat.

  • Dasbor pelaporan waktu nyata yang menjalankan ratusan kueri titik untuk pengumpulan metrik/data.

  • Aplikasi AI generatif dengan ekstensi pgvector untuk mencari neighbor yang tepat atau terdekat dalam jutaan penyematan vektor.

Objek sementara yang didukung Optimized Reads

Berikut ini adalah beberapa kasus penggunaan yang dapat memperoleh manfaat dari Optimized Reads dengan objek sementara:

  • Kueri analitis yang mencakup Ekspresi Tabel Umum (CTE), tabel turunan, dan operasi pengelompokan.

  • Replika baca yang menangani kueri yang tidak dioptimalkan untuk aplikasi.

  • Kueri pelaporan sesuai permintaan atau dinamis dengan operasi kompleks seperti GROUP BY dan ORDER BY yang tidak selalu dapat menggunakan indeks yang sesuai.

  • CREATE INDEXatau REINDEX operasi untuk menyortir.

  • Beban kerja lain yang menggunakan tabel sementara internal.

Memantau instans DB yang menggunakan Aurora Optimized Reads

Anda dapat memantau kueri yang menggunakan cache berjenjang yang didukung Optimized Reads dengan perintah EXPLAIN seperti yang ditunjukkan pada contoh berikut:

Postgres=> EXPLAIN (ANALYZE, BUFFERS) SELECT c FROM sbtest15 WHERE id=100000000                   

QUERY PLAN
--------------------------------------------------------------------------------------
 Index Scan using sbtest15_pkey on sbtest15  (cost=0.57..8.59 rows=1 width=121) (actual time=0.287..0.288 rows=1 loops=1)
   Index Cond: (id = 100000000)
   Buffers: shared hit=3 read=2 aurora_orcache_hit=2
   I/O Timings: shared/local read=0.264
 Planning:
   Buffers: shared hit=33 read=6 aurora_orcache_hit=6
   I/O Timings: shared/local read=0.607
 Planning Time: 0.929 ms
 Execution Time: 0.303 ms
(9 rows)
Time: 2.028 ms
catatan

aurora_orcache_hitdan aurora_storage_read bidang di Buffers bagian rencana penjelasan hanya ditampilkan ketika Pembacaan yang Dioptimalkan diaktifkan dan nilainya lebih besar dari nol. Bidang baca adalah total aurora_storage_read bidang aurora_orcache_hit dan.

Anda dapat memantau instans DB yang menggunakan Bacaan yang Dioptimalkan Aurora menggunakan metrik berikut CloudWatch:

  • AuroraOptimizedReadsCacheHitRatio

  • FreeEphemeralStorage

  • ReadIOPSEphemeralStorage

  • ReadLatencyEphemeralStorage

  • ReadThroughputEphemeralStorage

  • WriteIOPSEphemeralStorage

  • WriteLatencyEphemeralStorage

  • WriteThroughputEphemeralStorage

Metrik ini menyediakan data tentang penyimpanan instans, IOPS, dan throughput yang tersedia. Untuk informasi selengkapnya tentang metrik ini, lihat Metrik tingkat instans untuk Amazon Aurora.

Anda juga dapat menggunakan ekstensi pg_proctab untuk memantau penyimpanan NVMe. 

postgres=>select * from pg_diskusage();

major | minor |       devname       | reads_completed | reads_merged | sectors_read | readtime | writes_completed | writes_merged | sectors_written | writetime | current_io | iotime  | totaliotime
------+-------+---------------------+-----------------+--------------+--------------+----------+------------------+---------------+-----------------+-----------+------------+---------+-------------
      |       | rdstemp             |           23264 |            0 |       191450 |    11670 |          1750892 |             0 |        24540576 |    819350 |          0 | 3847580 |      831020
      |       | rdsephemeralstorage |           23271 |            0 |       193098 |     2620 |           114961 |             0 |        13845120 |    130770 |          0 |  215010 |      133410
(2 rows)

Praktik terbaik untuk Aurora Optimized Reads

Gunakan praktik terbaik berikut untuk Aurora Optimized Reads:

  • Pantau ruang penyimpanan yang tersedia di penyimpanan instans dengan CloudWatch metrikFreeEphemeralStorage. Jika penyimpanan instance mencapai batasnya karena beban kerja pada instans DB, atur konkurensi dan kueri yang banyak menggunakan objek sementara atau memodifikasinya untuk menggunakan kelas instans DB yang lebih besar.

  • Pantau CloudWatch metrik untuk hit rate cache Optimized Reads. Operasi seperti VACUUM akan memodifikasi sejumlah besar blok dengan sangat cepat. Hal ini dapat menyebabkan penurunan sementara dalam rasio hit. Ekstensi pg_prewarm dapat digunakan untuk memuat data ke dalam cache buffer yang memungkinkan Aurora secara proaktif menulis beberapa blok tersebut ke cache Optimized Reads.

  • Anda dapat mengaktifkan manajemen cache klaster (CCM) untuk melakukan "warm up" cache buffer dan cache berjenjang pada pembaca tingkat 0, yang akan digunakan sebagai target failover. Ketika CCM diaktifkan, cache buffer dipindai secara berkala untuk menulis halaman yang memenuhi syarat untuk pengosongan dalam cache berjenjang. Untuk informasi selengkapnya tentang CCM, lihat Pemulihan cepat setelah failover dengan manajemen cache klaster untuk Aurora PostgreSQL.