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 calcolo. AlloyDB Omni e il servizio AlloyDB per PostgreSQL completamente gestito su Google Cloud condividono gli stessi componenti di base. AlloyDB per PostgreSQL utilizza un livello di archiviazione nativo del cloud che ottimizza le prestazioni di 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 su 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.
- Devi avere un database che continui a funzionare anche quando è disconnesso da internet.
- Per ridurre al minimo la latenza, devi posizionare il database il più possibile vicino ai tuoi utenti.
- Vorresti un modo per eseguire la migrazione da un database legacy, ma senza dover eseguire una migrazione completa al cloud.
AlloyDB Omni non include le funzionalità di AlloyDB per PostgreSQL che si basano sull'operazione in Google Cloud. Se vuoi eseguire l'upgrade del tuo progetto alle funzionalità di scalabilità, sicurezza e disponibilità completamente gestite di AlloyDB per PostgreSQL, puoi eseguire la migrazione dei dati di AlloyDB Omni in un cluster AlloyDB per PostgreSQL come faresti con qualsiasi altra importazione iniziale dei dati.
Funzionalità principali
- Un server di database compatibile con PostgreSQL.
- Supporto di AlloyDB AI, che ti aiuta a creare applicazioni di IA generativa di livello enterprise utilizzando i tuoi dati operativi.
- Integrazioni con l' Google Cloud ecosistema dell'IA, tra cui Vertex AI Model Garden e strumenti di IA generativa open source.
Supporto delle funzionalità di autopilot di AlloyDB per PostgreSQL in Google Cloud che consente ad AlloyDB Omni di gestire e ottimizzare autonomamente.
Ad esempio, AlloyDB Omni supporta la gestione automatica della memoria e l'autovacuum adattivo dei dati inutilizzati.
Un suggerimento sull'indicizzazione che analizza le query eseguite di frequente e consiglia nuovi indici per migliorare le prestazioni delle query.
L'archivio a colonne AlloyDB Omni, che conserva i dati sottoposti a query di frequente in un formato a colonne in memoria per prestazioni più rapide su carichi di lavoro per business intelligence, generazione di report ed elaborazione transazionale ibrida e analitica (HTAP).
Nei nostri test delle prestazioni, i workload transazionali in AlloyDB Omni sono più di due 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 contenitore Docker che installi nel tuo ambiente. Ti consigliamo di eseguire AlloyDB Omni su un sistema Linux con 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 ulteriori informazioni, consulta Installare AlloyDB Omni su Kubernetes.
Le applicazioni si connettono e comunicano con la tua installazione di AlloyDB Omni, proprio come si connettono e comunicano con uno standard con un server di database PostgreSQL. Anche il controllo dell'accesso degli utenti si basa sugli standard PostgreSQL.
Dai log all'evacuazione al motore colonnare, puoi configurare il comportamento del database di AlloyDB Omni utilizzando flag di database.
Vantaggi dell'esecuzione di AlloyDB Omni come contenitore
Google distribuisce AlloyDB Omni come container che puoi eseguire con runtime del 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 contenuto del container e testate da Google per garantire che siano pienamente compatibili con AlloyDB Omni.
- Portabilità: puoi aspettarti che AlloyDB Omni funzioni in modo coerente in tutti gli ambienti.
- Isolamento di sicurezza: scegli a cosa ha accesso il contenitore AlloyDB Omni sulla macchina host.
- Gestione delle risorse: puoi definire la quantità di risorse di calcolo che vuoi che il contenitore AlloyDB Omni utilizzi.
- Patch e upgrade senza problemi: per applicare una patch a un container, devi solo sostituire l'immagine esistente con una nuova.
Backup dati e disaster recovery
AlloyDB Omni dispone di un sistema di backup e recupero continuo che consente di creare un nuovo cluster di database in base a un punto in tempo qualsiasi all'interno di un periodo di conservazione regolabile. In questo modo puoi recuperare rapidamente da incidenti di perdita di dati.
Inoltre, AlloyDB Omni può creare e archiviare backup completi dei dati del tuo cluster di database, on demand o con una pianificazione regolare. In qualsiasi momento, puoi eseguire il ripristino da un backup a un cluster di database AlloyDB Omni contenente tutti i dati del cluster di database originale al momento della creazione del backup.
Per ulteriori informazioni, consulta Eseguire il backup e il ripristino di AlloyDB Omni.
Come ulteriore metodo di disaster recovery, puoi eseguire la replica tra data center creando cluster di database secondari in data center separati. AlloyDB Omni trasmette in streaming i dati in modo asincrono da un cluster di database principale designato a ciascuno dei suoi cluster secondari. Se necessario, puoi promuovere un cluster di database secondario in un cluster di database AlloyDB Omni principale.
Per ulteriori informazioni, consulta Informazioni sulla replica tra data center.
Componenti della VM AlloyDB Omni
AlloyDB Omni su VM è costituito da due insiemi di componenti dell'architettura: componenti PostgreSQL con i miglioramenti di AlloyDB per PostgreSQL e componenti AlloyDB per PostgreSQL. Il seguente diagramma illustra entrambi gli insiemi di componenti, il livello di infrastruttura in cui si trovano su una VM o un server e le funzionalità correlate che puoi aspettarti per ogni componente.
Figura 1. Architettura di AlloyDB Omni
Motore del database
Questo documento descrive l'architettura del database in AlloyDB Omni in un contenutore. Questo documento presuppone che tu abbia familiarità con PostgreSQL.
Un motore del database esegue le seguenti attività:
- Tradisce una query da un client in un piano eseguibile
- Trova i dati necessari per soddisfare la query
- Esegue eventuali filtri, ordini e aggregazioni necessari
- Restituisce i risultati al client

Quando l'applicazione client invia una query ad AlloyDB Omni, si verificano le seguenti azioni:
- Il livello di elaborazione delle query trasforma la query in un piano di esecuzione che viene inviato al livello di esecuzione delle query.
- Il livello di esecuzione delle query esegue le operazioni necessarie per calcolare la risposta alla query.
- Durante l'esecuzione, i dati possono 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 del database. L'ottimizzazione del rendimento aims to optimize resource utilization during each of the steps in query execution.
L'obiettivo di un motore del database ad alte prestazioni è rispondere a una query utilizzando il minor numero di risorse richieste. Per raggiungere questo obiettivo, è necessario un buon modello di dati e un buon design delle query.
- In che modo è 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, accesso al disco per set di dati di grandi dimensioni, quindi come si possono evitare di ordinare i dati?
Archiviazione dei dati
AlloyDB Omni archivia i dati in pagine di dimensioni fisse memorizzate 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 le legge dal file system. L'accesso ai dati dal pool di buffer è molto più veloce della lettura dal file system e, pertanto, la massimizzazione della dimensione 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 in base alle richieste di memoria del sistema. Pertanto, non è necessario ottimizzare la dimensione del pool di buffer. Quando diagnostichi problemi di prestazioni, le prime metriche da considerare sono la percentuale di hit del pool di buffer e la frequenza di lettura per capire se la tua applicazione sta sfruttando il vantaggio del pool di buffer. In caso contrario, significa che il set di dati dell'applicazione non è compatibile con il pool di buffer e potresti prendere in considerazione la possibilità di ridimensionare la macchina a una più grande con più memoria.
Il processo di recupero, filtro, aggregazione, ordinamento e proiezione dei dati richiede tutte le risorse della CPU sul server del database. Per ridurre la quantità di risorse della CPU richieste per questa procedura, 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 stabile sia pari al 70% circa. Questo valore lascia un margine sufficiente sul server per picchi di utilizzo o variazioni dei 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 per prendere decisioni sulle specifiche della macchina.
Le operazioni di I/O al secondo (IOPS) sono un fattore importante per il rendimento delle applicazioni di database: il numero di operazioni di input o output al secondo che il dispositivo di archiviazione sottostante può fornire al database. Per evitare di raggiungere i limiti di operazioni IOPS dell'archiviazione del database, riduci al minimo le letture e le scritture nello spazio di archiviazione massimizzando la quantità di dati che possono essere inseriti nel pool del buffer.
Motore colonnare
Il motore colonnare accelera l'elaborazione delle query SQL di scansioni, join e aggregati fornendo i seguenti componenti:
In-memory column store: contiene i dati delle tabelle e delle visualizzazioni materializzate per le colonne selezionate in un formato orientato alle colonne. Per impostazione predefinita, il collezionista di colonne consuma 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
inpostgresql.conf
utilizzato dall'istanza AlloyDB Omni.Per ulteriori informazioni su come modificare il parametro, consulta Modificare i parametri di configurazione.
Motore di pianificazione ed esecuzione delle query a colonne: supporta l'utilizzo del colonnaio nelle query.
Gestione automatica della memoria
Il gestore della memoria automatico monitora e ottimizza continuamente il consumo di memoria in un'intera istanza AlloyDB Omni. Quando esegui i tuoi carichi di lavoro, questo modulo regola le dimensioni della cache del buffer condiviso in base alla pressione della memoria. Per impostazione predefinita, il gestore della memoria automatico 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
in postgresql.conf
utilizzato dall'istanza AlloyDB Omni.
Per saperne di più, consulta Gestione automatica della memoria.
Autopulizia adattiva
L'autovacuum adattivo analizza le operazioni in base al carico di lavoro del database e regola automaticamente la frequenza di pulizia. Questo aggiustamento automatico consente al database di funzionare al massimo delle prestazioni, anche quando il carico di lavoro cambia, senza interferenze dal processo di eliminazione sottovuoto.
L'aspirapolvere automatico adattivo utilizza i seguenti fattori per determinare la frequenza e l'intensità delle operazioni di aspirazione:
- Dimensioni del database
- Numero di tuple non attive nel database
- Data di creazione dei dati nel database
- Numero di transazioni al secondo rispetto alla velocità di svuotamento stimata
L'autopulizia adattiva offre i seguenti vantaggi:
- Gestione dinamica delle risorse di eliminazione: anziché utilizzare un limite di costo fisso, AlloyDB Omni utilizza le statistiche sulle risorse in tempo reale per regolare i worker di eliminazione. Quando il sistema è occupato, il processo di svuotamento e l'utilizzo delle risorse associato vengono limitati. Se è disponibile memoria sufficiente, viene allocata memoria aggiuntiva per
maintenance_work_mem
per ridurre il tempo di svuotamento end-to-end. - Ritardo XID dinamico: monitora automaticamente e continuamente l'avanzamento del processo di eliminazione dei dati non necessari e la velocità di consumo degli ID transazioni. Se viene rilevato un rischio di wraparound degli ID transazione, AlloyDB Omni rallenta le transazioni per limitare il consumo di ID. Inoltre,
AlloyDB Omni alloca più risorse ai worker di aspirazione
per elaborare le tabelle che bloccano l'avanzamento e il rilascio dello spazio ID transaction. Durante questa procedura, le transazioni complessive al secondo vengono ridotte fino a quando gli ID transazione non si trovano in una zona sicura (osservabile come sessioni in attesa su
AdaptiveVacuumNewXidDelay
). Quando l'età dell'ID transazione aumenta, i worker di aspirazione vengono aumentati in modo dinamico. - Svuoto efficiente per tabelle più grandi: la logica predefinita di PostgreSQL impiegata per decidere quando eseguire il vuoto di una tabella si basa su statistiche specifiche della tabella memorizzate in
pg_stat_all_tables
, che contiene il rapporto tra tuple non valide. Questa logica funziona per tabelle di piccole dimensioni, ma potrebbe non funzionare in modo efficiente per tabelle più grandi aggiornate di frequente. AlloyDB Omni fornisce un meccanismo di scansione aggiornato che consente di attivare più spesso l'autovacuum. Questo meccanismo di scansione analizza blocchi di tabelle di grandi dimensioni e rimuove le tuple non valide in modo più efficiente rispetto alla logica predefinita di PostgreSQL. - Registra messaggi di avviso: in AlloyDB Omni, gli elementi che bloccano il sottovuoto, come le transazioni a lungo termine o le transazioni preparate o gli slot di replica che hanno perso i relativi target, vengono rilevati e gli avvisi vengono registrati nei log di PostgreSQL in modo da risolvere i problemi in modo tempestivo.
Operatore AI/ML
In AlloyDB Omni, il worker in background di IA/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 ulteriori informazioni, consulta Creare applicazioni di AI generativa utilizzando AlloyDB AI.