Mengelola jumlah objek tinggi di - Amazon Aurora
HubunganTabel sementaraTabel yang tidak tersumbatPartisiFile sementaraUrutanBenda besarPerkiraan ambang batas

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

Mengelola jumlah objek tinggi di

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 autovacuum untuk saran tentang cara menentukan pengaturan autovacuum yang sesuai. Gunakan 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.

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 , karena replikasi logis bergantung pada WAL untuk menangkap dan mentransfer perubahan. Baca lebih lanjut tentang cara mengkonfigurasi Aurora PostgreSQL untuk mereplikasi tabel yang tidak tercatat.

Dampak: Node Pembaca

Anda dapat mengakses tabel yang tidak tercatat hanya dari node penulis di cluster Aurora DB. Lihat Bekerja dengan tabel yang tidak tercatat di Aurora PostgreSQL untuk detail selengkapnya.

Praktik terbaik umum:

  • Tabel yang tidak tersumbat memberikan manfaat kinerja terbatas di Aurora PostgreSQL dibandingkan dengan PostgreSQL standar, jadi evaluasi apakah tabel normal lebih tepat.

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: FreeLocalStorage konsumsi

File sementara adalah bagian penting dari PostgreSQL ketika hasil kueri tidak dapat masuk ke work_mem. Umumnya ini baik-baik saja. Namun, ketika beban kerja menggunakan ini secara ekstensif, itu berarti kueri besar terus berjalan dan Anda akan melihat penurunan. FreeLocalStorage Lihat Mengelola file sementara untuk detail selengkapnya.

Praktik terbaik umum:

  • Pantau penggunaan file temp Anda dengan Insights.

  • 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 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.