Panoramica di AlloyDB Omni

Seleziona una versione della documentazione:

AlloyDB Omni è un pacchetto software di database scaricabile che ti consente di eseguire il deployment di una versione semplificata di AlloyDB per PostgreSQL nel tuo ambiente di computing. AlloyDB Omni e il servizio AlloyDB completamente gestito su Google Cloud condividono gli stessi componenti principali. AlloyDB utilizza un livello di archiviazione cloud-native che ottimizza le prestazioni WAL, mentre AlloyDB Omni utilizza la stessa interfaccia del file system standard utilizzata da PostgreSQL.

La portabilità di AlloyDB Omni ti consente di eseguirlo in molti ambienti, tra cui:

  • Data center
  • Laptop
  • Istanze VM basate sul cloud

Casi d'uso di AlloyDB Omni

AlloyDB Omni è adatto ai seguenti scenari:

  • Hai bisogno di una versione scalabile e performante di PostgreSQL, ma non puoi eseguire un database nel cloud a causa di requisiti normativi o di sovranità dei dati.
  • Hai bisogno di un database che continui a essere eseguito anche quando è disconnesso da internet.
  • Per ridurre al minimo la latenza, vuoi posizionare il database il più vicino possibile ai tuoi utenti dal punto di vista geografico.
  • Vorresti un modo per eseguire la migrazione da un database legacy, ma senza impegnarti in una migrazione completa al cloud.

AlloyDB Omni non include le funzionalità di AlloyDB che si basano sull'operazione in Google Cloud. Se vuoi eseguire l'upgrade del progetto alle funzionalità di scalabilità, sicurezza e disponibilità completamente gestite di AlloyDB, puoi eseguire la migrazione dei dati di AlloyDB Omni in un cluster AlloyDB proprio come puoi fare con qualsiasi altro importazione iniziale di dati.

Funzionalità principali

  • Un server di database compatibile con PostgreSQL.
  • Supporto per AlloyDB AI, che ti aiuta a creare applicazioni di AI generativa di livello aziendale utilizzando i tuoi dati operativi.
  • Integrazioni con l'ecosistema Google Cloud AI, tra cui Vertex AI Model Garden e strumenti di AI generativa open source.

  • Supporto per le funzionalità di Autopilot di AlloyDB in Google Cloud che consente ad AlloyDB Omni di autogestirsi e autoregolarsi.

    Ad esempio, AlloyDB Omni supporta la gestione automatica della memoria e l'autovacuum adattivo dei dati obsoleti.

  • Un suggeritore di indici che analizza le query eseguite di frequente e consiglia nuovi indici per migliorare le prestazioni delle query.

  • Il motore colonnare AlloyDB Omni , che conserva spesso i dati soggetti più spesso a query in un formato a colonne in memoria per prestazioni più veloci su carichi di lavoro per business intelligence, generazione di report ed elaborazione transazionale ibrida e analitica (HTAP).

Nei nostri test delle prestazioni, i carichi di lavoro transazionali in AlloyDB Omni sono oltre 2 volte più veloci e le query analitiche sono fino a 100 volte più veloci rispetto a PostgreSQL standard.

Come funziona AlloyDB Omni

Puoi installare AlloyDB Omni come server autonomo o come parte di un ambiente Kubernetes.

AlloyDB Omni viene eseguito in un container Docker che tu installi nel tuo ambiente. Ti consigliamo di eseguire AlloyDB Omni su un sistema Linux con spazio di archiviazione SSD e almeno 8 GB di memoria per CPU.

L'operatore AlloyDB Omni Kubernetes è un'estensione dell'API Kubernetes che ti consente di eseguire AlloyDB Omni nella maggior parte degli ambienti Kubernetes conformi a CNCF. Per saperne di più, consulta Installare AlloyDB Omni su Kubernetes.

Le tue applicazioni si connettono e comunicano con l'installazione di AlloyDB Omni, proprio come le applicazioni si connettono e comunicano con un server di database PostgreSQL standard. Anche il controllo dell'accesso degli utenti si basa sugli standard PostgreSQL.

Dalla registrazione all'operazione VACUUM al motore colonnare, puoi configurare il comportamento del database di AlloyDB Omni utilizzando flag del database.

Vantaggi dell'esecuzione di AlloyDB Omni come container

Google distribuisce AlloyDB Omni come container che puoi eseguire con runtime di container come Docker e Podman. Dal punto di vista operativo, i container presentano i seguenti vantaggi:

  • Gestione trasparente delle dipendenze: tutte le dipendenze necessarie sono raggruppate nel container e testate da Google per garantire la piena compatibilità con AlloyDB Omni.
  • Portabilità: puoi aspettarti che AlloyDB Omni funzioni in modo coerente in tutti gli ambienti.
  • Isolamento della sicurezza: scegli a cosa può accedere il container AlloyDB Omni sulla macchina host.
  • Gestione delle risorse: puoi definire la quantità di risorse di calcolo che vuoi che il container AlloyDB Omni utilizzi.
  • Applicazione di patch e upgrade senza interruzioni: per applicare una patch a un container, devi solo sostituire l'immagine esistente con una nuova.

Backup dati e ripristino di emergenza

AlloyDB Omni include un sistema di backup e recupero continui che ti consente di creare un nuovo cluster di database basato su qualsiasi punto nel tempo all'interno di un periodo di conservazione regolabile. In questo modo puoi eseguire rapidamente il recupero da incidenti di perdita di dati.

Inoltre, AlloyDB Omni può creare e archiviare backup completi dei dati del cluster di database, on demand o in base a una pianificazione regolare. In qualsiasi momento, puoi eseguire il ripristino da un backup a un cluster di database AlloyDB Omni che contiene tutti i dati del cluster di database originale al momento della creazione del backup.

Per saperne di più, consulta Eseguire il backup e il ripristino di AlloyDB Omni.

Come ulteriore metodo di ripristino di emergenza, puoi ottenere la replica tra data center creando cluster di database secondari in data center separati. AlloyDB Omni esegue lo streaming asincrono dei dati da un cluster di database primario designato a ciascuno dei suoi cluster secondari. Se necessario, puoi promuovere un cluster di database secondario a cluster di database AlloyDB Omni primario.

Per saperne di più, consulta Informazioni sulla replica tra data center.

Componenti VM di AlloyDB Omni

AlloyDB Omni su VM è costituito da due set di componenti dell'architettura: componenti PostgreSQL con miglioramenti di AlloyDB per PostgreSQL e componenti di AlloyDB per PostgreSQL. Il seguente diagramma illustra entrambi i set di componenti, il livello di infrastruttura in cui risiedono su una VM o un server e le funzionalità correlate che puoi aspettarti per ogni componente.

Diagramma dell'architettura dei componenti di AlloyDB Omni che separa i componenti specifici di AlloyDB per PostgreSQL dai componenti di PostgreSQL.

Figura 1. Architettura di AlloyDB Omni

Motore del database

Questo documento descrive l'architettura del database in AlloyDB Omni in un container. Questo documento presuppone che tu abbia familiarità con PostgreSQL.

Un motore del database esegue le seguenti attività:

  1. Traduce una query da un client in un piano eseguibile
  2. Trova i dati necessari per soddisfare la query
  3. Esegue qualsiasi filtro, ordinamento e aggregazione necessari
  4. Restituisce i risultati al client
Diagramma che mostra come le applicazioni client interagiscono con i livelli del database.
Figura 1. Mostra i livelli di database che funzionano insieme per rispondere a query delle applicazioni client.

Quando l'applicazione client invia una query ad AlloyDB Omni, si verificano le seguenti azioni:

  1. Il livello di elaborazione delle query trasforma la query in un piano di esecuzione che passa al livello di esecuzione delle query.
  2. Il livello di esecuzione delle query esegue le operazioni necessarie per calcolare la risposta alla query.
  3. Durante l'esecuzione, i dati potrebbero essere caricati dalla cache del buffer o direttamente dallo spazio di archiviazione. Se i dati vengono caricati dallo spazio di archiviazione, vengono memorizzati nella cache per usi futuri.

Le risorse utilizzate durante l'elaborazione della query del client includono CPU, memoria, I/O, rete e primitive di sincronizzazione come i blocchi di database. L'ottimizzazione delle prestazioni mira a ottimizzare l'utilizzo delle risorse durante ogni passaggio dell'esecuzione delle query.

L'obiettivo di un motore del database performante è rispondere a una query utilizzando il minor numero di risorse necessarie. Questo obiettivo inizia con un buon modello dei dati e una buona progettazione delle query.

  • Come è possibile rispondere alle query esaminando la quantità minima di dati?
  • Quali indici sono necessari per ridurre lo spazio di ricerca e l'I/O?
  • L'ordinamento dei dati richiede CPU e, spesso, l'accesso al disco per i set di dati di grandi dimensioni, quindi come è possibile evitare l'ordinamento dei dati?

Archiviazione dei dati

AlloyDB Omni archivia i dati in pagine di dimensioni fisse archiviate nel file system sottostante. Quando una query deve accedere ai dati, AlloyDB Omni controlla prima il pool di buffer. Se le pagine che contengono i dati richiesti non vengono trovate nel pool di buffer, AlloyDB Omni legge le pagine richieste dal file system. L'accesso ai dati dal pool di buffer è notevolmente più veloce della lettura dal file system e, pertanto, massimizzare le dimensioni del pool di buffer per la quantità di dati a cui accederà un'applicazione è un fattore importante.

Gestione delle risorse

AlloyDB Omni utilizza la gestione dinamica della memoria per consentire al pool di buffer di aumentare e diminuire dinamicamente entro i limiti configurati, a seconda delle richieste di memoria del sistema. Pertanto, non è necessario ottimizzare le dimensioni del pool di buffer. Quando diagnostichi i problemi di prestazioni, le prime metriche da considerare sono la frequenza di riscontri del pool di buffer e la frequenza di lettura per verificare se la tua applicazione sta sfruttando il pool di buffer. In caso contrario, significa che il set di dati dell'applicazione non rientra nel pool di buffer e potresti prendere in considerazione la possibilità di ridimensionare a una macchina più grande con più memoria.

Il processo di recupero, filtraggio, aggregazione, ordinamento e proiezione dei dati richiede risorse CPU sul server di database. Per ridurre la quantità di risorse CPU richieste per questo processo, riduci al minimo la quantità di dati da manipolare. Monitora l'utilizzo della CPU sul server di database per assicurarti che l'utilizzo in stato stazionario sia intorno al 70%. Questa quantità lascia spazio sufficiente sul server per picchi di utilizzo o modifiche ai pattern di accesso nel tempo. L'esecuzione con un utilizzo più vicino al 100% introduce un overhead dovuto alla pianificazione dei processi e al cambio di contesto e potrebbe creare colli di bottiglia in altre parti del sistema. L'utilizzo elevato della CPU è un'altra metrica chiave da utilizzare quando prendi decisioni sulle specifiche della macchina.

Le operazioni di input/output al secondo (IOPS) sono un fattore importante per le prestazioni delle applicazioni di database: quante operazioni di input o output al secondo può fornire il dispositivo di archiviazione sottostante al database. Per evitare di raggiungere i limiti IOPS dello spazio di archiviazione del database, riduci al minimo le letture e le scritture nello spazio di archiviazione massimizzando la quantità di dati che possono essere contenuti nel pool di buffer.

Motore colonnare

Il motore colonnare accelera l'elaborazione delle query SQL di scansioni, join e aggregazioni fornendo i seguenti componenti:

  • Spazio di archiviazione a colonne in memoria: contiene i dati di tabelle e viste materializzate per le colonne selezionate in un formato orientato alle colonne. Per impostazione predefinita, lo spazio di archiviazione a colonne utilizza 1 GB di memoria disponibile. Per modificare la quantità di memoria utilizzabile dallo spazio di archiviazione a colonne, imposta il parametro google_columnar_engine.memory_size_in_mb nel file postgresql.conf utilizzato dall'istanza AlloyDB Omni.

    Per saperne di più su come modificare il parametro, consulta Modificare i parametri di configurazione.

  • Pianificatore di query colonnari e motore di esecuzione: supporta l'utilizzo dello spazio di archiviazione a colonne nelle query.

Gestione automatica della memoria

Il gestore automatico della memoria monitora e ottimizza continuamente il consumo di memoria in un'intera istanza AlloyDB Omni. Quando esegui i carichi di lavoro, questo modulo regola le dimensioni della cache del buffer condiviso in base alla pressione della memoria. Per impostazione predefinita, il gestore automatico della memoria imposta il limite superiore all'80% della memoria di sistema e alloca il 10% della memoria di sistema per la cache del buffer condiviso. Per modificare il limite superiore per le dimensioni della cache del buffer condiviso, imposta il parametro shared_buffers nel file postgresql.conf utilizzato dall'istanza AlloyDB Omni.

Per saperne di più, consulta Gestione automatica della memoria.

Autovacuum adattivo

L'autovacuum adattivo analizza le operazioni in base al carico di lavoro del database e regola automaticamente la frequenza dell'operazione VACUUM. Questa regolazione automatica aiuta il database a funzionare con prestazioni ottimali, anche quando il carico di lavoro cambia, senza interferenze con il processo VACUUM.

L'autovacuum adattivo utilizza i seguenti fattori per determinare la frequenza e l'intensità delle operazioni VACUUM:

  • Dimensioni del database
  • Numero di tuple non attive nel database
  • Età dei dati nel database
  • Numero di transazioni al secondo rispetto alla velocità stimata di VACUUM

L'autovacuum adattivo offre i seguenti vantaggi:

  • Gestione dinamica delle risorse VACUUM: anziché utilizzare un limite di costo fisso, AlloyDB Omni utilizza statistiche sulle risorse in tempo reale per regolare i worker VACUUM. Quando il sistema è occupato, il processo VACUUM e l'utilizzo delle risorse associate vengono limitati. Se è disponibile memoria sufficiente, viene allocata memoria aggiuntiva per maintenance_work_mem per ridurre il tempo di VACUUM end-to-end.
  • Limitazione dinamica degli XID: monitora automaticamente e continuamente l' avanzamento dell'operazione VACUUM e la velocità di consumo degli ID transazione. Se viene rilevato un rischio di wraparound dell'ID transazione, AlloyDB Omni rallenta le transazioni per limitare il consumo di ID. Inoltre, AlloyDB Omni alloca più risorse ai worker VACUUM per elaborare le tabelle che bloccano l'avanzamento e il rilascio dello spazio ID transazione. Durante questo processo, le transazioni complessive al secondo vengono ridotte finché gli ID transazione non si trovano in una zona sicura (osservabile come sessioni in attesa di AdaptiveVacuumNewXidDelay). Quando l'età dell'ID transazione aumenta, i worker VACUUM vengono aumentati dinamicamente.
  • Operazione VACUUM efficiente per le tabelle più grandi: la logica PostgreSQL predefinita utilizzata per decidere quando eseguire l'operazione VACUUM su una tabella si basa su statistiche specifiche della tabella archiviate in pg_stat_all_tables, che contiene il rapporto tra le tuple non attive. Questa logica funziona per le tabelle di piccole dimensioni, ma potrebbe non funzionare in modo efficiente per le tabelle più grandi e aggiornate di frequente. AlloyDB Omni fornisce un meccanismo di scansione aggiornato che aiuta a attivare l'autovacuum più spesso. Questo meccanismo di scansione esamina i blocchi di tabelle di grandi dimensioni e rimuove le tuple non attive in modo più efficiente rispetto alla logica PostgreSQL predefinita.
  • Messaggi di avviso nei log: in AlloyDB Omni, i blocchi VACUUM, come le transazioni a lunga esecuzione o le transazioni preparate o gli slot di replica che hanno perso le destinazioni, vengono rilevati e gli avvisi vengono registrati nei log di PostgreSQL in modo che tu possa risolvere i problemi in modo tempestivo.

Worker AI/ML

In AlloyDB Omni, il worker in background AI/ML fornisce tutte le funzionalità necessarie per chiamare i modelli Vertex AI direttamente dal database. Il worker AI/ML viene eseguito come processo denominato omni ml worker.

Per saperne di più, consulta Creare applicazioni di AI generativa utilizzando AlloyDB AI.