Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Gestione di un numero elevato di oggetti in Amazon RDS for PostgreSQL Amazon Aurora
Sebbene le limitazioni di PostgreSQL siano teoriche, avere un numero di oggetti estremamente elevato in un database causerà un notevole impatto sulle prestazioni di varie operazioni. Questa documentazione copre diversi tipi di oggetti comuni che, quando hanno un numero totale elevato, possono portare a diversi possibili impatti.
La tabella seguente fornisce un riepilogo dei tipi di oggetti e dei loro potenziali impatti:
| Tipo di oggetto | Autovacuum | Replica logica | Aggiornamento della versione principale | pg_dump/pg_restore | Prestazioni generali | Riavvio dell'istanza |
|---|---|---|---|---|---|---|
| Relazioni | x | x | x | x | ||
| Tabelle temporanee | x | x | ||||
| Tabelle non registrate | x | x | ||||
| Partizioni | x | |||||
| File temporanei | x | |||||
| Sequenze | x | |||||
| Oggetti di grandi dimensioni | x | x |
Relazioni
Non esiste un limite rigido specifico per quanto riguarda il numero di tabelle in un database PostgreSQL. Il limite teorico è estremamente elevato, ma ci sono altri limiti pratici che devono essere tenuti a mente durante la progettazione del database.
- Impatto: l'aspirapolvere automatico rimane indietro
-
Autovacuum può avere difficoltà a tenere il passo con la crescita degli ID delle transazioni o l'aumento dei tavoli a causa della mancanza di lavoratori rispetto alla quantità di lavoro.
Azione consigliata: Esistono diversi fattori per ottimizzare l'autovacuum in modo che stia al passo con un determinato numero di tabelle e un determinato carico di lavoro. Vedi Best practice per lavorare con PostgreSQL autovacuum Best practice per lavorare con PostgreSQL .
- Impatto: aggiornamento della versione principale /pg_dump e ripristino
-
Amazon RDS utilizza l'opzione «--link» durante l'esecuzione di pg_upgrade per evitare di dover fare copie dei file di dati, i metadati dello schema devono comunque essere ripristinati nella nuova versione del database. Anche con parallel pg_restore, se esiste un numero significativo di relazioni, ciò aumenterà la quantità di tempi di inattività.
- Impatto: degrado generale delle prestazioni
-
Degrado generale delle prestazioni dovuto alle dimensioni del catalogo. Ogni tabella e le colonne associate verranno aggiunte alle
pg_attributepg_dependtabelle utilizzate di frequente nelle normali operazioni del database.pg_classNon sarà visibile un evento di attesa specifico, ma l'efficienza del buffer condiviso ne risentirà.Azione consigliata: controlla regolarmente il gonfiamento della tabella per queste tabelle specifiche e occasionalmente esegui un errore
VACUUM FULLsu queste tabelle specifiche. Tieni presente cheVACUUM FULLsulle tabelle del catalogo è necessario unACCESS EXCLUSIVEblocco, il che significa che nessun'altra interrogazione potrà accedervi fino al completamento dell'operazione.
- Impatto: esaurimento del descrittore di file
-
Errore: «descrittori di file insufficienti: troppi file aperti nel sistema; rilascia e riprova». Il
max_files_per_processparametro PostgreSQL determina il numero di file che ogni processo può aprire. Se è presente un numero elevato di connessioni che uniscono un numero elevato di tabelle, è possibile raggiungere questo limite.Azione consigliata:
La riduzione del valore del parametro
max_files_per_processpuò contribuire a ridurre questo errore. Ogni processo e sottoprocesso (ad esempio, query parallela) può aprire questo numero di file e, se le query uniscono più tabelle, questo limite può essere esaurito.Riduci il numero complessivo di connessioni e utilizza un pool di connessioni come Amazon RDS Proxy Amazon o altre soluzioni come. PgBouncer Per ulteriori informazioni, consulta il sito Web. PgBouncer
- Impatto: esaurimento degli inodi
-
Errore: «Spazio insufficiente sul dispositivo». Se ciò si verifica quando c'è molto spazio libero di archiviazione, ciò è causato dall'esaurimento degli inode. Amazon RDS Enhanced Monitoring offre visibilità sugli inode in uso e sul numero massimo disponibile per l'host.
Soglia approssimativa: milioni
Tabelle temporanee
L'utilizzo di tabelle temporanee è utile per i dati di test o i risultati intermedi ed è uno schema comune utilizzato in molti motori di database. Le implicazioni dell'uso intensivo di PostgreSQL devono essere comprese per evitare alcune delle insidie. Ogni creazione e rilascio di tabelle temporanee aggiungerà righe alle tabelle del catalogo di sistema, che, una volta gonfiate, causeranno problemi generali di prestazioni.
- Impatto: Autovacuum è in ritardo
-
Le tabelle temporanee non vengono cancellate dall'autovacuum, ma rimarranno invariate per tutta la durata della loro esistenza e, se non vengono IDs rimosse, possono causare problemi.
Azione consigliata: le tabelle temporanee resteranno attive per tutta la durata della sessione che le ha create o possono essere eliminate manualmente. Una buona pratica per evitare transazioni di lunga durata con tabelle temporanee impedirà a queste tabelle di contribuire alla crescita massima degli ID di transazione utilizzati.
- Impatto: degrado generale delle prestazioni
-
Degrado generale delle prestazioni dovuto alle dimensioni del catalogo. Quando le sessioni creano ed eliminano continuamente tabelle temporanee, si aggiungono
pg_classallepg_attributepg_dependtabelle utilizzate di frequente nelle normali operazioni del database. Non sarà visibile un evento di attesa specifico, ma l'efficienza del buffer condiviso ne risentirà.Azione consigliata:
Controlla regolarmente table bloat per queste tabelle specifiche e occasionalmente esegui un a
VACUUM FULLsu queste tabelle specifiche. Tieni presente cheVACUUM FULLsulle tabelle del catalogo è necessario unACCESS EXCLUSIVEblocco, il che significa che nessun'altra interrogazione potrà accedervi fino al completamento dell'operazione.Se le tabelle temporanee vengono utilizzate intensamente, prima di un aggiornamento della versione principale, si consiglia vivamente di utilizzare una
VACUUM FULLdi queste tabelle di catalogo specifiche per ridurre i tempi di inattività.
Procedure consigliate generali:
Riduci l'uso di tabelle temporanee utilizzando espressioni di tabella comuni per produrre risultati intermedi. A volte possono complicare le interrogazioni necessarie, ma eliminano gli impatti sopra elencati.
Riutilizza le tabelle temporanee utilizzando il
TRUNCATEcomando per cancellare il contenuto anziché eseguire i passaggi. drop/create Ciò eliminerà anche il problema della crescita degli ID delle transazioni causata dalle tabelle temporanee.
Soglia approssimativa: decine di migliaia
Tabelle non registrate
Le tabelle non registrate possono offrire miglioramenti in termini di prestazioni in quanto non generano alcuna informazione WAL. Devono essere utilizzate con attenzione in quanto non offrono alcuna durabilità durante il ripristino da un crash del database poiché verranno troncate. Questa è un'operazione costosa in PostgreSQL poiché ogni tabella non registrata viene troncata in serie. Sebbene questa operazione sia rapida per un numero limitato di tabelle non registrate, quando si contano migliaia può iniziare ad aggiungere notevoli ritardi durante l'avvio.
- Impatto: replica logica
-
Le tabelle non registrate generalmente non sono incluse nella replica logica, incluse le implementazioni blue/verdi, poiché la replica logica si .
- Impatto: tempi di inattività prolungati durante il ripristino
-
Durante qualsiasi stato del database che comporti il ripristino da un arresto anomalo del database, ad esempio il riavvio Multi-AZ con failover, il ripristino di Amazon RDS point-in-time e l'aggiornamento della versione principale di Amazon RDS, si verificherà l'operazione serializzata di troncamento delle tabelle non registrate. Ciò può portare a tempi di inattività molto più lunghi del previsto.
Azione consigliata:
Riduci al minimo l'uso di tabelle non registrate solo per i dati la cui perdita è accettabile durante le operazioni di ripristino da crash del database.
Riduci al minimo l'uso di tabelle non registrate poiché l'attuale comportamento del troncamento seriale può causare una notevole quantità di tempo per l'avvio di un database.
Buone pratiche generali:
-
Le tabelle non registrate non sono a prova di crash. L'avvio di un point-in-time ripristino, che prevede il ripristino in caso di arresto anomalo, richiede molto tempo in PostgreSQL perché si tratta di un processo seriale che tronca ogni tabella.
Soglia approssimativa: migliaia
Partizioni
Il partizionamento può aumentare le prestazioni delle query e fornire un'organizzazione logica dei dati. In scenari ideali, il partizionamento è organizzato in modo da poter utilizzare l'eliminazione delle partizioni durante la pianificazione e l'esecuzione delle query. L'utilizzo di troppe partizioni può avere un impatto negativo sulle prestazioni delle query e sulla manutenzione del database. La scelta del modo in cui partizionare una tabella deve essere effettuata con attenzione, poiché le prestazioni della pianificazione e dell'esecuzione delle query possono essere influenzate negativamente da una progettazione scadente. Consulta la documentazione di PostgreSQL per i dettagli sul partizionamento
- Impatto: peggioramento generale delle prestazioni
-
A volte il sovraccarico di tempo di pianificazione aumenta e la spiegazione dei piani per le domande diventa più complicata, rendendo difficile l'identificazione delle opportunità di ottimizzazione. Per le versioni di PostgreSQL precedenti alla 18, molte partizioni con un carico di lavoro elevato possono causare attese.
LWLock:LockManagerAzione consigliata: Determina un numero minimo di partizioni che ti consenta di completare l'organizzazione dei dati e allo stesso tempo di fornire un'esecuzione delle query efficiente.
- Impatto: complessità della manutenzione
-
Un numero molto elevato di partizioni introdurrà difficoltà di manutenzione come la precreazione e la rimozione. Autovacuum tratterà le partizioni come normali relazioni e dovrà eseguire una pulizia regolare, richiedendo quindi un numero sufficiente di lavoratori per completare l'operazione.
Azione consigliata:
Assicurati di precreare le partizioni in modo che il carico di lavoro non venga bloccato quando è necessaria una nuova partizione (ad esempio, partizioni mensili) e le vecchie partizioni vengono eliminate.
Assicurati di disporre di un numero sufficiente di aspiratori automatici per eseguire la normale pulizia e manutenzione di tutte le partizioni.
Soglia approssimativa: centinaia
File temporanei
A differenza delle tabelle temporanee sopra menzionate, i file temporanei vengono creati da PostgreSQL quando una query complessa può eseguire diverse operazioni di ordinamento o hash contemporaneamente, con ogni operazione che utilizza la memoria dell'istanza per archiviare i risultati fino al valore specificato nel parametro. work_mem Quando la memoria dell'istanza non è sufficiente, vengono creati file temporanei per archiviare i risultati. Vedi Gestione dei file temporanei Gestione dei file . Se il carico di lavoro genera un numero elevato di questi file, gli impatti possono essere diversi.
- Impatto: esaurimento del descrittore di file
-
Errore: «descrittori di file insufficienti: troppi file aperti nel sistema; rilascia e riprova». Il
max_files_per_processparametro PostgreSQL determina il numero di file che ogni processo può aprire. Se è presente un numero elevato di connessioni che uniscono un numero elevato di tabelle, è possibile raggiungere questo limite.Azione consigliata:
La riduzione del valore del parametro
max_files_per_processpuò contribuire a ridurre questo errore. Ogni processo e sottoprocesso (ad esempio, query parallela) può aprire questo numero di file e, se le query uniscono più tabelle, questo limite può essere esaurito.Riduci il numero complessivo di connessioni e utilizza un pool di connessioni come Amazon RDS Proxy o altre soluzioni come. PgBouncer Per ulteriori informazioni, consulta il PgBouncer sito Web.
- Impatto: esaurimento degli inodi
-
Errore: «Spazio insufficiente sul dispositivo». Se ciò si verifica quando c'è molto spazio libero di archiviazione, ciò è causato dall'esaurimento degli inode. Amazon RDS Enhanced Monitoring offre la visibilità degli inode in uso e il numero massimo disponibile per l'host.
Best practice generali:
Monitora l'utilizzo dei file temporanei con Performance Insights Performance .
Ottimizza le query che generano file temporanei significativi per vedere se è possibile ridurre il numero totale di file temporanei.
Soglia approssimativa: migliaia
Sequenze
Le sequenze sono l'oggetto sottostante utilizzato per l'incremento automatico delle colonne in PostgreSQL e forniscono unicità e una chiave per i dati. Queste possono essere utilizzate su singole tabelle senza conseguenze durante le normali operazioni, ad eccezione della replica logica.
In PostgreSQL, la replica logica attualmente non replica il valore corrente di una sequenza su nessun sottoscrittore. Per saperne di più, consulta la pagina Restrizioni nella documentazione di PostgreSQL
- Impatto: tempo di commutazione prolungato
-
Se prevedi di utilizzare Amazon RDS Blue/Green Deployments per qualsiasi tipo di modifica o aggiornamento della configurazione, è importante comprendere l'impatto di un numero elevato di sequenze sullo switchover. Una delle ultime fasi di uno switchover sincronizzerà il valore corrente delle sequenze e, se ce ne sono diverse migliaia, ciò aumenterà il tempo complessivo di passaggio.
Azione consigliata: se il carico di lavoro del database consentisse l'uso di un UUID condiviso anziché di un sequence-per-table approccio, ciò ridurrebbe la fase di sincronizzazione durante lo switchover.
Soglia approssimativa: migliaia
Oggetti di grandi dimensioni
Gli oggetti di grandi dimensioni vengono memorizzati in un'unica tabella di sistema denominata pg_largeobject. Ogni oggetto di grandi dimensioni ha anche una voce nella tabella di sistema pg_largeobject_metadata. Questi oggetti vengono creati, modificati e ripuliti in modo molto diverso rispetto alle relazioni standard. Gli oggetti di grandi dimensioni non vengono gestiti dall'autovacuum e devono essere puliti periodicamente tramite un processo separato chiamato vacuumlo. Vedi Gestione di oggetti di grandi dimensioni con il modulo lo per esempi sulla gestione di oggetti di grandi dimensioni.
- Impatto: replica logica
-
Gli oggetti di grandi dimensioni non vengono attualmente replicati in PostgreSQL durante la replica logica. Per saperne di più, consulta la pagina Restrizioni nella documentazione di PostgreSQL
. In una configurazione blu/verde blu/verde . - Impatto: aggiornamento della versione principale
-
Un aggiornamento può esaurire la memoria e fallire se sono presenti milioni di oggetti di grandi dimensioni e l'istanza non è in grado di gestirli durante l'aggiornamento. Il processo di aggiornamento della versione principale di PostgreSQL comprende due ampie fasi: il dumping dello schema tramite pg_dump e il ripristino tramite pg_restore. Se il tuo database ha milioni di oggetti di grandi dimensioni, devi assicurarti che l'istanza abbia memoria sufficiente per gestire pg_dump e pg_restore durante un aggiornamento e ridimensionarla su un tipo di istanza più grande.
Migliori pratiche generali:
Utilizzate regolarmente l'utilità vacuumlo per rimuovere eventuali oggetti di grandi dimensioni rimasti orfani.
Prendi in considerazione l'utilizzo del tipo di dati BYTEA per archiviare i tuoi oggetti di grandi dimensioni nel database.
Soglia approssimativa: milioni
Soglie approssimative
Le soglie approssimative menzionate in questo argomento vengono utilizzate solo per fornire una stima della scalabilità di una determinata risorsa. Rappresentano l'intervallo generale in cui gli impatti descritti diventano più probabili, ma il comportamento effettivo dipende dal carico di lavoro specifico, dalla dimensione dell'istanza e dalla configurazione. Sebbene sia possibile superare queste stime, è necessario attenersi alla cura e alla manutenzione in modo da evitare gli impatti elencati.
