Hubungan Tabel sementara Tabel yang tidak tersumbat Partisi File sementara Urutan Benda besar Perkiraan ambang batas

Mengelola jumlah objek tinggi di Amazon RDS untuk PostgreSQL Amazon Aurora

Sementara keterbatasan PostgreSQL bersifat teoritis, memiliki jumlah objek yang sangat tinggi dalam database akan menyebabkan dampak kinerja yang nyata pada berbagai operasi. Dokumentasi ini mencakup beberapa jenis objek umum yang, ketika memiliki jumlah total yang tinggi dapat menyebabkan beberapa kemungkinan dampak.

Tabel berikut memberikan ringkasan jenis objek dan potensi dampaknya:

Jenis objek dan dampak potensial
Jenis Objek	Autovacuum	Replikasi Logis	Upgrade Versi Utama	pg_dump/pg_restore	Kinerja Umum	Instans Mulai Ulang
Hubungan	x		x	x	x
Tabel sementara	x				x
Tabel yang tidak tersumbat		x				x
Partisi					x
File sementara					x
Urutan		x
Benda besar		x	x

Hubungan

Tidak ada batasan keras khusus mengenai jumlah tabel dalam database PostgreSQL. Batas teoritis sangat tinggi, tetapi ada batasan praktis lain yang perlu diingat selama desain database.

Dampak: Autovacuum tertinggal

Autovacuum dapat berjuang untuk mengikuti pertumbuhan ID transaksi atau kembung meja karena kurangnya pekerja dibandingkan dengan jumlah pekerjaan.

Tindakan yang disarankan: Ada beberapa faktor untuk menyetel autovacuum agar sesuai dengan jumlah tabel tertentu dan beban kerja yang diberikan. Lihat Praktik terbaik untuk bekerja dengan PostgreSQL autovacuum Praktik terbaik untuk bekerja dengan PostgreSQL yang sesuai. Gunakan utilitas postgres_get_av_diag utilitas untuk memantau masalah dengan pertumbuhan ID transaksi.

Dampak: Peningkatan versi utama/pg_dump dan pulihkan

Amazon RDS menggunakan opsi “--link” selama eksekusi pg_upgrade untuk menghindari keharusan membuat salinan file data, metadata skema masih diperlukan untuk dikembalikan ke versi baru database. Bahkan dengan parallel pg_restore, jika ada sejumlah besar hubungan ini akan meningkatkan jumlah downtime.

Dampak: Degradasi kinerja umum

Degradasi kinerja umum karena ukuran katalog. Setiap tabel dan kolom terkait akan menambahpg_attribute, pg_class dan pg_depend tabel yang sering digunakan dalam operasi database normal. Tidak akan ada acara tunggu tertentu yang terlihat, tetapi efisiensi buffer bersama akan terpengaruh.

Tindakan yang disarankan: Periksa tabel kembung secara teratur untuk tabel spesifik ini dan sesekali lakukan a VACUUM FULL pada tabel tertentu ini. Ketahuilah bahwa VACUUM FULL pada tabel katalog memerlukan ACCESS EXCLUSIVE kunci yang berarti tidak ada kueri lain yang dapat mengaksesnya sampai operasi selesai.

Dampak: Kelelahan deskriptor file

Kesalahan: “keluar dari deskriptor file: Terlalu banyak file terbuka di sistem; lepaskan dan coba lagi”. max_files_per_processParameter PostgreSQL menentukan berapa banyak file yang dapat dibuka setiap proses. Jika ada sejumlah besar koneksi yang bergabung dengan sejumlah besar tabel, dimungkinkan untuk mencapai batas ini.

Tindakan yang disarankan:

Menurunkan nilai parameter max_files_per_process dapat membantu meringankan kesalahan ini. Setiap proses dan subproses (misalnya, query paralel) dapat membuka jumlah file ini, dan jika kueri bergabung dengan beberapa tabel, batas ini dapat habis.
Kurangi jumlah keseluruhan koneksi dan gunakan kumpulan koneksi seperti Amazon RDS Proxy atau solusi lain seperti. PgBouncer Untuk mempelajari lebih lanjut, lihat situs PgBouncer web.

Dampak: Kelelahan Inode

Kesalahan: “Tidak ada ruang tersisa di perangkat”. Jika ini diamati ketika ada banyak ruang kosong penyimpanan, ini disebabkan oleh kehabisan inode. Amazon RDS Enhanced Monitoring memberikan visibilitas untuk inode yang digunakan dan jumlah maksimum yang tersedia untuk host Anda.

Ambang batas perkiraan: Jutaan

Tabel sementara

Menggunakan tabel sementara berguna untuk data uji atau hasil antara dan merupakan pola umum yang terlihat di banyak mesin database. Implikasi penggunaan berat di PostgreSQL harus dipahami untuk menghindari beberapa jebakan. Setiap tabel sementara yang dibuat dan dijatuhkan akan menambahkan baris ke tabel katalog sistem, yang ketika menjadi kembung, akan menyebabkan masalah kinerja umum.

Dampak: Autovacuum tertinggal

Tabel sementara tidak disedot oleh autovacuum tetapi akan mempertahankan transaksi IDs selama keberadaannya dan dapat menyebabkan sampul jika tidak dihapus.

Tindakan yang disarankan: Tabel sementara akan hidup selama sesi yang membuatnya atau dapat dijatuhkan secara manual. Praktik terbaik untuk menghindari transaksi jangka panjang dengan tabel sementara akan mencegah tabel ini berkontribusi pada pertumbuhan ID transaksi maksimum yang digunakan.

Dampak: Degradasi kinerja umum

Degradasi kinerja umum karena ukuran katalog. Ketika sesi terus membuat dan menjatuhkan tabel sementara, itu akan menambahpg_attribute, pg_class dan pg_depend tabel yang sering digunakan dalam operasi database normal. Tidak akan ada acara tunggu tertentu yang terlihat, tetapi efisiensi buffer bersama akan terpengaruh.

Tindakan yang disarankan:

Periksa tabel kembung secara teratur untuk tabel khusus ini dan sesekali lakukan VACUUM FULL pada tabel tertentu ini. Ketahuilah bahwa VACUUM FULL pada tabel katalog memerlukan ACCESS EXCLUSIVE kunci yang berarti tidak ada kueri lain yang dapat mengaksesnya sampai operasi selesai.
Jika tabel sementara banyak digunakan, sebelum peningkatan versi utama, tabel katalog khusus ini sangat disarankan untuk mengurangi waktu henti. VACUUM FULL

Praktik terbaik umum:

Kurangi penggunaan tabel sementara dengan menggunakan ekspresi tabel umum untuk menghasilkan hasil antara. Ini kadang-kadang dapat mempersulit pertanyaan yang diperlukan, tetapi akan menghilangkan dampak yang tercantum di atas.
Gunakan kembali tabel sementara dengan menggunakan TRUNCATE perintah untuk menghapus konten alih-alih melakukan drop/create langkah-langkah. Ini juga akan menghilangkan masalah pertumbuhan ID transaksi yang disebabkan oleh tabel sementara.

Ambang perkiraan: Puluhan ribu

Tabel yang tidak tersumbat

Tabel yang tidak tercatat dapat menawarkan peningkatan kinerja karena tidak akan menghasilkan informasi WAL apa pun. Mereka harus digunakan dengan hati-hati karena mereka tidak menawarkan daya tahan selama pemulihan kerusakan database karena mereka akan terpotong. Ini adalah operasi yang mahal di PostgreSQL karena setiap tabel yang tidak tersumbat dipotong secara serial. Meskipun operasi ini cepat untuk sejumlah kecil tabel yang tidak tercatat, ketika jumlahnya ribuan, itu dapat mulai menambahkan penundaan penting selama startup.

Dampak: Replikasi logis: Tabel yang tidak tercatat umumnya tidak termasuk dalam replikasi logis, termasuk Penerapan Biru/Hijau Penerapan Biru/Hijau .

Dampak: Waktu henti yang diperpanjang selama pemulihan

Selama status database apa pun yang melibatkan pemulihan kerusakan basis data seperti reboot Multi-AZ dengan failover, point-in-time pemulihan Amazon RDS, dan peningkatan versi utama Amazon RDS, operasi serial pemotongan tabel yang tidak tercatat akan terjadi. Hal ini dapat menyebabkan pengalaman downtime yang jauh lebih tinggi dari yang diharapkan.

Tindakan yang disarankan:

Minimalkan penggunaan tabel yang tidak tercatat hanya untuk data yang dapat diterima untuk hilang selama operasi pemulihan kerusakan database.
Minimalkan penggunaan tabel yang tidak tercatat karena perilaku pemotongan serial saat ini dapat menyebabkan startup database memakan banyak waktu.

Praktik terbaik umum:

Tabel yang tidak tersumbat tidak aman untuk crash. Memulai point-in-time pemulihan, yang melibatkan pemulihan crash, membutuhkan waktu yang signifikan di PostgreSQL karena ini adalah proses serial yang memotong setiap tabel.

Ambang perkiraan: Ribuan

Partisi

Partisi dapat meningkatkan kinerja kueri dan menyediakan organisasi data yang logis. Dalam skenario ideal, partisi diatur sehingga pemangkasan partisi dapat digunakan selama perencanaan dan pelaksanaan kueri. Menggunakan terlalu banyak partisi dapat berdampak negatif pada kinerja kueri dan pemeliharaan basis data. Pilihan cara mempartisi tabel harus dibuat dengan hati-hati, karena kinerja perencanaan dan pelaksanaan kueri dapat dipengaruhi secara negatif oleh desain yang buruk. Lihat dokumentasi PostgreSQL untuk detail tentang partisi.

Dampak: Degradasi kinerja umum

Terkadang perencanaan overhead waktu akan meningkat dan menjelaskan rencana untuk pertanyaan Anda akan menjadi lebih rumit, sehingga sulit untuk mengidentifikasi peluang penyetelan. Untuk versi PostgreSQL lebih awal dari 18, banyak partisi dengan beban kerja tinggi dapat menyebabkan menunggu. LWLock:LockManager

Tindakan yang disarankan: Tentukan jumlah minimum partisi yang akan memungkinkan Anda untuk menyelesaikan kedua organisasi data Anda sementara pada saat yang sama menyediakan eksekusi kueri kinerja.

Dampak: Kompleksitas pemeliharaan

Jumlah partisi yang sangat tinggi akan menimbulkan kesulitan pemeliharaan seperti pra-pembuatan dan penghapusan. Autovacuum akan memperlakukan partisi sebagai hubungan normal dan harus melakukan pembersihan rutin, oleh karena itu membutuhkan cukup banyak pekerja untuk menyelesaikan tugas.

Tindakan yang disarankan:

Pastikan Anda membuat partisi sehingga beban kerja tidak diblokir saat partisi baru diperlukan (misalnya, partisi berbasis bulanan) dan partisi lama diluncurkan.
Pastikan Anda memiliki cukup pekerja autovacuum untuk melakukan pemeliharaan pembersihan normal semua partisi.

Ambang perkiraan: Ratusan

File sementara

Berbeda dari tabel sementara yang disebutkan di atas, file sementara dibuat oleh PostgreSQL ketika kueri kompleks mungkin melakukan beberapa operasi pengurutan atau hash pada saat yang sama, dengan setiap operasi menggunakan memori instance untuk menyimpan hasil hingga nilai yang ditentukan dalam parameter. work_mem Jika memori instans tidak cukup, file sementara akan dibuat untuk menyimpan hasil. Lihat Mengelola file sementara untuk detail selengkapnya tentang file sementara. Jika beban kerja Anda menghasilkan sejumlah besar file-file ini, mungkin ada beberapa dampak.

Dampak: Kelelahan deskriptor file

Tindakan yang disarankan:

Menurunkan nilai parameter max_files_per_process dapat membantu meringankan kesalahan ini. Setiap proses dan subproses (misalnya, query paralel) dapat membuka jumlah file ini, dan jika kueri bergabung dengan beberapa tabel, batas ini dapat habis.
Kurangi jumlah keseluruhan koneksi dan gunakan kumpulan koneksi seperti Amazon RDS Proxy atau solusi lain seperti. PgBouncer Untuk mempelajari lebih lanjut, lihat situs PgBouncer web.

Dampak: Kelelahan Inode

Kesalahan: “Tidak ada ruang tersisa di perangkat”. Jika ini diamati ketika ada banyak ruang kosong penyimpanan, ini disebabkan oleh kehabisan inode. Amazon RDS Enhanced Monitoring menyediakan visibilitas untuk inode yang digunakan dan jumlah maksimum yang tersedia untuk host Anda.

Praktik terbaik umum:

Pantau penggunaan file temp Anda dengan Performance Insights Performance .
Sesuaikan kueri yang menghasilkan file sementara yang signifikan untuk melihat apakah mungkin untuk mengurangi jumlah total file temp.

Ambang perkiraan: Ribuan

Urutan

Urutan adalah objek yang mendasari yang digunakan untuk penambahan kolom otomatis di PostgreSQL dan mereka memberikan keunikan dan kunci untuk data. Ini dapat digunakan pada tabel individu tanpa konsekuensi selama operasi normal dengan satu pengecualian replikasi logis.

Di PostgreSQL, replikasi logis saat ini tidak mereplikasi nilai urutan saat ini ke pelanggan mana pun. Untuk mempelajari selengkapnya, lihat halaman Pembatasan dalam dokumentasi PostgreSQL.

Dampak: Waktu peralihan yang diperpanjang

Jika Anda berencana untuk menggunakan Amazon RDS Blue/Green Deployment untuk semua jenis perubahan konfigurasi atau upgrade, penting untuk memahami dampak dari sejumlah besar urutan pada switchover. Salah satu fase terakhir dari peralihan akan menyinkronkan nilai urutan saat ini, dan jika ada beberapa ribu, ini akan meningkatkan waktu peralihan keseluruhan.

Tindakan yang disarankan: Jika beban kerja database Anda memungkinkan penggunaan UUID bersama alih-alih sequence-per-table pendekatan, ini akan mengurangi langkah sinkronisasi selama peralihan.

Ambang perkiraan: Ribuan

Benda besar

Objek besar disimpan dalam tabel sistem tunggal bernama pg_largeobject. Setiap objek besar juga memiliki entri dalam tabel sistem pg_largeobject_metadata. Objek-objek ini dibuat, dimodifikasi dan dibersihkan jauh berbeda dari hubungan standar. Benda besar tidak ditangani oleh autovacuum dan harus dibersihkan secara berkala melalui proses terpisah yang disebut vacuumlo. Lihat mengelola objek besar dengan modul lo untuk contoh mengelola objek besar.

Dampak: Replikasi logis: Objek besar saat ini tidak direplikasi di PostgreSQL selama replikasi logis. Untuk mempelajari selengkapnya, lihat halaman Pembatasan dalam dokumentasi PostgreSQL. Dalam konfigurasi Biru/Hijau , ini berarti objek besar di lingkungan biru tidak direplikasi ke lingkungan hijau.
Dampak: Peningkatan versi utama: Upgrade dapat kehabisan memori dan gagal jika ada jutaan objek besar dan instance tidak dapat menanganinya selama peningkatan. Proses upgrade versi utama PostgreSQL terdiri dari dua fase luas: membuang skema melalui pg_dump dan memulihkannya melalui pg_restore. Jika database Anda memiliki jutaan objek besar, Anda perlu memastikan instance Anda memiliki memori yang cukup untuk menangani pg_dump dan pg_restore selama peningkatan dan menskalakannya ke jenis instance yang lebih besar.

Praktik terbaik umum:

Gunakan utilitas vacuumlo secara teratur untuk menghapus benda besar yatim piatu yang mungkin Anda miliki.
Pertimbangkan untuk menggunakan tipe data BYTEA untuk menyimpan objek besar Anda dalam database.

Ambang batas perkiraan: Jutaan

Perkiraan ambang batas

Ambang batas perkiraan yang disebutkan dalam topik ini hanya digunakan untuk memberikan perkiraan seberapa jauh skala sumber daya tertentu. Mereka mewakili rentang umum di mana dampak yang dijelaskan menjadi lebih mungkin, tetapi perilaku aktual tergantung pada beban kerja, ukuran instance, dan konfigurasi spesifik Anda. Meskipun dimungkinkan untuk melampaui perkiraan ini, perawatan dan pemeliharaan harus dipatuhi untuk menghindari dampak yang tercantum.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Penjelasan pesan PEMBERITAHUAN

Mengelola pertentangan TOAST OID