Panoramica di AlloyDB Omni

AlloyDB Omni è un pacchetto software di database scaricabile che ti consente di eseguire il deployment di una versione semplificata di AlloyDB per PostgreSQL negli ambienti di computing che gestisci. AlloyDB Omni e il servizio AlloyDB completamente gestito su Google Cloud condividono gli stessi componenti di base. AlloyDB utilizza un livello di archiviazione disaggregato nativo per il cloud, mentre AlloyDB Omni viene implementato nello spazio di archiviazione di tua scelta.

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

  • I tuoi data center privati
  • Qualsiasi cloud pubblico
  • Il tuo laptop
  • Istanze VM basate su cloud

AlloyDB Omni offre diversi miglioramenti, oltre a PostgreSQL standard, che supportano scalabilità, disponibilità, affidabilità, prestazioni, AI e linguaggio naturale. Per saperne di più, consulta Aggiunte di AlloyDB Omni a PostgreSQL standard.

Casi d'uso di AlloyDB Omni

AlloyDB Omni è adatto ai seguenti scenari:

  • Hai bisogno di una versione scalabile e ad alte prestazioni di PostgreSQL da eseguire on-premise a causa di requisiti normativi o di sovranità dei dati.
  • Hai bisogno di un database che continui a funzionare anche quando è disconnesso da internet.
  • Vuoi eseguire la migrazione da un database legacy senza impegnarti a utilizzare un servizio cloud completamente gestito come AlloyDB per PostgreSQL.

Funzionalità principali

  • Un server di database compatibile al 100% con PostgreSQL.
  • Supporto di 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 delle funzionalità di pilota automatico di AlloyDB per PostgreSQL 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.

  • Il motore colonnare AlloyDB Omni, che conserva i dati pertinenti in un formato colonnare in memoria per query analitiche, report e carichi di lavoro di elaborazione transazionale ibrida e analitica (HTAP) più veloci.

Nei test delle prestazioni, i workload transazionali in AlloyDB Omni sono oltre 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 in uno dei seguenti modi:

  • AlloyDB Omni per i container: un container di database autonomo. Esegui AlloyDB Omni su un sistema Linux con spazio di archiviazione SSD e almeno 8 GB di memoria per CPU.

  • AlloyDB Omni per Kubernetes: parte di un container in un ambiente Kubernetes. L'operatore AlloyDB Omni Kubernetes è un'estensione dell'API Kubernetes che consente di eseguire AlloyDB Omni nella maggior parte degli ambienti Kubernetes conformi a CNCF.

    L'operatore AlloyDB Omni semplifica le operazioni di base del database, consentendoti di automatizzare i deployment singoli o ad alta disponibilità (HA) e le operazioni del secondo giorno come backup, ripristino, failover e configurazione del ripristino di emergenza (RE) tra regioni.

  • AlloyDB Omni per Linux (anteprima): un Red Hat Package Manager (RPM) che viene eseguito direttamente in una VM o su bare metal. AlloyDB Omni per Linux viene eseguito come un insieme di componenti software integrati direttamente sul sistema operativo host. Utilizza il file system Linux standard per l'archiviazione, consentendoti di utilizzare l'infrastruttura di archiviazione e le pratiche di gestione esistenti.

Le tue applicazioni si connettono e comunicano con il tuo database AlloyDB Omni, proprio come 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 alla pulizia al motore colonnare, puoi configurare il comportamento del database AlloyDB Omni utilizzando i flag del database.

Vantaggi dell'esecuzione di AlloyDB Omni come container

Google distribuisce AlloyDB Omni come container che puoi eseguire con runtime del container come Docker e Podman. Puoi anche eseguire il deployment dei container AlloyDB Omni in un ambiente Kubernetes con molte operazioni di base automatizzate.

A livello operativo, i container offrono 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 ha accesso 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.
  • Patch e upgrade senza interruzioni: per applicare una patch a un container, sostituisci l'immagine esistente con una nuova.

Vantaggi dell'esecuzione di AlloyDB Omni in un ambiente RHEL

AlloyDB Omni per Linux (anteprima) è progettato per gli ambienti in cui è preferibile un deployment di database non containerizzato. Questo modello di deployment supporta server bare metal e macchine virtuali.

Puoi installare AlloyDB Omni per Linux direttamente in un ambiente Red Hat Enterprise Linux (RHEL) o compatibile con Red Hat utilizzando i gestori di pacchetti del sistema operativo standard.

AlloyDB Omni per Linux supporta RHEL 9 e Rocky Linux 9.

Backup dati e disaster recovery

AlloyDB Omni è dotato di un sistema di backup e recupero continui che ti consente di creare un nuovo cluster di database in base a qualsiasi momento all'interno di un periodo di conservazione regolabile. In questo modo puoi recuperare i dati in caso di perdita accidentale.

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.

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 trasmette in streaming in modo asincrono i 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.

Componenti di AlloyDB Omni

AlloyDB Omni è costituito da due insiemi di componenti dell'architettura: componenti PostgreSQL con miglioramenti di AlloyDB e componenti specifici di AlloyDB.

Il seguente diagramma mostra entrambi i set di componenti, incluso il livello di infrastruttura in cui risiedono i componenti e le funzionalità per ciascun componente.

Architettura dei componenti di AlloyDB Omni che mostra i componenti specifici di AlloyDB per PostgreSQL e i componenti di PostgreSQL.

Figura 1. Architettura di AlloyDB Omni

Archiviazione dei dati

AlloyDB Omni archivia i dati in pagine di dimensioni fisse che vengono archiviate nel file system sottostante. Quando una query deve accedere ai dati, AlloyDB Omni controlla prima il buffer pool. Se le pagine che contengono i dati richiesti non vengono trovate nel buffer pool, AlloyDB Omni legge le pagine richieste dal file system.

L'accesso ai dati dal buffer pool è molto più rapido della lettura dal file system. Massimizzare le dimensioni del pool di buffer per i dati a cui accede un'applicazione è un fattore importante. Se vuoi, puoi aggiungere un livello di cache ultraveloce per migliorare ulteriormente le prestazioni delle query.

Gestione delle risorse

AlloyDB Omni utilizza la gestione dinamica automatica della memoria per consentire al buffer pool di aumentare e diminuire dinamicamente entro i limiti configurati a seconda delle esigenze di memoria del sistema. Pertanto, non è necessario ottimizzare le dimensioni del buffer pool. Quando diagnostichi problemi di prestazioni, considera innanzitutto metriche come il tasso di hit del pool di buffer e il tasso di lettura per determinare se la tua applicazione trae vantaggio dal pool di buffer. In caso contrario, significa che il set di dati dell'applicazione non rientra nel buffer pool e potresti prendere in considerazione la possibilità di ridimensionarlo su 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 della CPU necessarie 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%. Questo importo lascia un margine sufficiente sul server per picchi di utilizzo o modifiche ai pattern di accesso nel tempo. L'esecuzione a un utilizzo più vicino al 100% introduce un sovraccarico 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 si prendono decisioni sulle specifiche della macchina.

Le operazioni di input/output al secondo (IOPS) sono un fattore importante per le prestazioni delle applicazioni di database, in quanto misurano il numero di operazioni di input o output al secondo che il dispositivo di archiviazione sottostante può fornire al database. Per evitare di superare i limiti di IOPS dell'archiviazione del database, riduci al minimo le letture e le scritture nell'archiviazione massimizzando la quantità di dati che rientrano nel buffer pool o nel livello di cache.

Motore colonnare

Il motore colonnare integrato accelera l'elaborazione delle query analitiche che in genere comportano scansioni complete delle tabelle, join complessi e aggregazioni.

  • Archivio 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 column store utilizza il 30% della 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.

  • Motore di esecuzione e pianificazione delle query colonnari: supporta l'utilizzo dello store di 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 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 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 condivisa. 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.

Aspirazione automatica 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 aiuta il database a mantenere prestazioni ottimali, anche quando il carico di lavoro cambia, senza interferenze del processo di vacuum.

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

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

Worker AI/ML

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

Passaggi successivi