Présentation d'AlloyDB Omni

AlloyDB Omni est un package logiciel de base de données téléchargeable qui vous permet de déployer une version simplifiée d'AlloyDB pour PostgreSQL dans les environnements de calcul que vous gérez. AlloyDB Omni et le service AlloyDB entièrement géré sur Google Cloudpartagent les mêmes composants de base. AlloyDB utilise une couche de stockage dissociée native du cloud, tandis qu'AlloyDB Omni est déployé sur le stockage de votre choix.

La portabilité d'AlloyDB Omni vous permet de l'exécuter dans de nombreux environnements, y compris les suivants :

  • Vos centres de données privés
  • N'importe quel cloud public
  • Votre ordinateur portable
  • Instances de VM dans le cloud

AlloyDB Omni offre plusieurs améliorations par rapport à PostgreSQL standard. Elles permettent d'améliorer l'évolutivité, la disponibilité, la fiabilité, les performances, l'IA et le langage naturel. Pour en savoir plus, consultez Ajouts d'AlloyDB Omni à PostgreSQL standard.

Cas d'utilisation d'AlloyDB Omni

AlloyDB Omni est particulièrement adapté aux scénarios suivants :

  • Vous avez besoin d'une version évolutive et performante de PostgreSQL que vous devez exécuter sur site en raison d'exigences réglementaires ou de souveraineté des données.
  • Vous avez besoin d'une base de données qui continue de fonctionner même lorsqu'elle est déconnectée d'Internet.
  • Vous souhaitez migrer depuis une ancienne base de données sans vous engager dans un service cloud entièrement géré comme AlloyDB pour PostgreSQL.

Principales fonctionnalités

  • Un serveur de base de données 100 % compatible avec PostgreSQL.
  • Prise en charge d'AlloyDB AI, qui vous aide à créer des applications d'IA générative de niveau entreprise à l'aide de vos données opérationnelles.
  • Intégrations avec l'écosystème d'IA Google Cloud , y compris Vertex AI Model Garden et les outils d'IA générative Open Source.

  • Prise en charge des fonctionnalités autopilot d'AlloyDB pour PostgreSQL dansGoogle Cloud . Cela permet à AlloyDB Omni de s'autogérer et de s'autorégler.

    Par exemple, AlloyDB Omni est compatible avec la gestion automatique de la mémoire et l'autovacuum adaptatif des données obsolètes.

  • Le moteur de données en colonnes AlloyDB Omni, qui stocke les données pertinentes dans un format en colonnes en mémoire pour accélérer les requêtes analytiques, les rapports et les charges de travail de traitement transactionnel et analytique hybride (HTAP).

Nos tests de performances ont permis de démontrer que les charges de travail transactionnelles dans AlloyDB Omni sont plus de deux fois plus rapides et que les requêtes analytiques sont jusqu'à 100 fois plus rapides que dans PostgreSQL standard.

Fonctionnement d'AlloyDB Omni

Vous pouvez installer AlloyDB Omni de l'une des façons suivantes :

  • AlloyDB Omni pour les conteneurs : un conteneur de base de données autonome. Exécutez AlloyDB Omni sur un système Linux avec un stockage SSD et au moins 8 Go de mémoire par processeur.

  • AlloyDB Omni pour Kubernetes : partie d'un conteneur dans un environnement Kubernetes. L'opérateur Kubernetes AlloyDB Omni est une extension de l'API Kubernetes qui vous permet d'exécuter AlloyDB Omni dans la plupart des environnements Kubernetes conformes à la norme CNCF.

    L'opérateur AlloyDB Omni simplifie les opérations de base de données, ce qui vous permet d'automatiser les déploiements uniques ou à haute disponibilité (HA) et les opérations du deuxième jour, comme la sauvegarde, la restauration, le basculement et la configuration de la reprise après sinistre (DR) interrégionale.

  • AlloyDB Omni pour Linux (preview) : un gestionnaire de packages Red Hat (RPM) qui s'exécute directement dans une VM ou sur un serveur bare metal. AlloyDB Omni pour Linux s'exécute sous la forme d'un ensemble de composants logiciels intégrés directement sur le système d'exploitation hôte. Il utilise le système de fichiers Linux standard pour le stockage, ce qui vous permet d'utiliser votre infrastructure de stockage et vos pratiques de gestion existantes.

Vos applications se connectent à votre base de données AlloyDB Omni et communiquent avec elle, de la même façon qu'elles se connectent à un serveur de base de données PostgreSQL standard et communiquent avec lui. Le contrôle de l'accès des utilisateurs repose également sur les normes PostgreSQL.

De la journalisation au nettoyage en passant par le moteur de données en colonnes, vous pouvez configurer le comportement de la base de données AlloyDB Omni à l'aide des options de base de données.

Avantages de l'exécution d'AlloyDB Omni en tant que conteneur

Google distribue AlloyDB Omni sous la forme d'un conteneur que vous pouvez exécuter avec des environnements d'exécution de conteneur tels que Docker et Podman. Vous pouvez également déployer des conteneurs AlloyDB Omni dans un environnement Kubernetes, où de nombreuses opérations de base sont automatisées.

D'un point de vue opérationnel, les conteneurs présentent les avantages suivants :

  • Gestion transparente des dépendances : toutes les dépendances nécessaires sont regroupées dans le conteneur et testées par Google afin de garantir qu'elles sont entièrement compatibles avec AlloyDB Omni.
  • Portabilité : vous pouvez vous attendre à ce qu'AlloyDB Omni fonctionne de manière cohérente dans tous les environnements.
  • Isolation de sécurité : vous choisissez ce à quoi le conteneur AlloyDB Omni a accès sur la machine hôte.
  • Gestion des ressources : vous pouvez définir la quantité de ressources de calcul que vous souhaitez rendre disponible pour le conteneur AlloyDB Omni.
  • Mises à niveau et ajouts de correctifs simplifiés : pour appliquer un correctif à un conteneur, remplacez l'image existante par une nouvelle.

Avantages de l'exécution d'AlloyDB Omni dans un environnement RHEL

AlloyDB Omni pour Linux (Preview) est conçu pour les environnements dans lesquels un déploiement de base de données non conteneurisé est préféré. Ce modèle de déploiement est compatible avec les serveurs Bare Metal et les machines virtuelles.

Vous pouvez installer AlloyDB Omni pour Linux directement dans un environnement Red Hat Enterprise Linux (RHEL) ou compatible avec Red Hat à l'aide des gestionnaires de packages standards du système d'exploitation.

AlloyDB Omni pour Linux est compatible avec RHEL 9 et Rocky Linux 9.

Sauvegarde des données et reprise après sinistre

AlloyDB Omni dispose d'un système de sauvegarde et de récupération continues qui vous permet de créer un cluster de bases de données basé sur n'importe quel moment précis d'une période de conservation ajustable. Cela vous permet de récupérer vos données en cas de perte accidentelle.

De plus, AlloyDB Omni peut créer et stocker des sauvegardes complètes des données de votre cluster de bases de données, à la demande ou selon un calendrier régulier. À tout moment, vous pouvez restaurer dans un cluster de bases de données AlloyDB Omni une sauvegarde contenant toutes les données du cluster de bases de données d'origine (tel qu'il était au moment de la création de la sauvegarde).

Autre méthode de reprise après sinistre : vous pouvez obtenir une réplication entre centres de données en créant des clusters de bases de données secondaires dans des centres de données distincts. AlloyDB Omni diffuse de manière asynchrone les données d'un cluster de bases de données principal désigné vers chacun de ses clusters secondaires. Si nécessaire, vous pouvez promouvoir un cluster de bases de données secondaire en cluster de bases de données AlloyDB Omni principal.

Composants AlloyDB Omni

AlloyDB Omni se compose de deux ensembles de composants d'architecture : les composants PostgreSQL avec les améliorations AlloyDB et les composants spécifiques à AlloyDB.

Le schéma suivant montre les deux ensembles de composants, y compris la couche d'infrastructure dans laquelle résident les composants et les fonctionnalités de chaque composant.

Architecture des composants AlloyDB Omni montrant les composants spécifiques à AlloyDB pour PostgreSQL et les composants PostgreSQL.

Figure 1 : Architecture d'AlloyDB Omni

Stockage de données

AlloyDB Omni stocke les données dans des pages de taille fixe qui sont stockées dans le système de fichiers sous-jacent. Lorsqu'une requête doit accéder à des données, AlloyDB Omni vérifie d'abord le pool de mémoire tampon. Si les pages contenant les données requises ne sont pas trouvées dans le pool de mémoire tampon, AlloyDB Omni lit les pages requises à partir du système de fichiers.

L'accès aux données du pool de mémoire tampon est beaucoup plus rapide que la lecture à partir du système de fichiers. Il est important de maximiser la taille du pool de mémoire tampon pour les données auxquelles une application accède. Vous pouvez éventuellement ajouter une couche de cache ultra-rapide pour améliorer davantage les performances des requêtes.

Gestion des ressources

AlloyDB Omni utilise la gestion automatique et dynamique de la mémoire pour permettre l'accroissement et la réduction dynamiques du pool de mémoire tampon dans le respect des limites configurées, en fonction des besoins en mémoire du système. Par conséquent, il n'est pas nécessaire d'ajuster la taille du pool de mémoire tampon. Lorsque vous diagnostiquez des problèmes de performances, commencez par examiner des métriques telles que le taux de succès du pool de mémoire tampon et le taux de lecture pour déterminer si votre application bénéficie du pool de mémoire tampon. Si ce n'est pas le cas, cela signifie que l'ensemble de données de l'application ne tient pas dans le pool de mémoire tampon. Vous pouvez alors envisager un redimensionnement sur une machine de taille plus importante et offrant plus de mémoire.

Le processus de récupération, de filtrage, d'agrégation, de tri et de projection des données nécessite des ressources de processeur sur le serveur de base de données. Pour réduire la quantité de ressources de processeur requises pour ce processus, minimisez la quantité de données à manipuler. Surveillez l'utilisation du processeur sur le serveur de base de données pour vous assurer que l'utilisation à l'état stable est d'environ 70 %. Ce taux laisse suffisamment de marge sur le serveur pour les pics d'utilisation ou les changements dans les modèles d'accès dans le temps. Une utilisation proche de 100 % introduit une surcharge due à la planification des processus et au changement de contexte, ce qui peut créer des goulots d'étranglement dans d'autres parties du système. Une utilisation élevée du processeur est une autre métrique clé à utiliser pour prendre des décisions concernant les spécifications des machines.

Les opérations d'entrée/sortie par seconde (IOPS, Input/Output Operations Per Second) sont un facteur important des performances des applications de base de données. Elles correspondent au nombre d'opérations d'entrée ou de sortie par seconde que le dispositif de stockage sous-jacent peut fournir à la base de données. Pour éviter de dépasser les limites d'IOPS du stockage de base de données, limitez le plus possible les lectures et les écritures dans le stockage en maximisant la quantité de données pouvant tenir dans le pool de mémoire tampon ou dans le niveau de cache.

Moteur de données en colonnes

Le moteur de données en colonnes intégré accélère le traitement des requêtes analytiques qui impliquent généralement des analyses complètes des tables, des jointures complexes et des agrégations.

  • Store orienté colonnes en mémoire : contient les données des tables et des vues matérialisées pour les colonnes sélectionnées dans un format orienté colonnes. Par défaut, le store orienté colonnes consomme 30 % de la mémoire disponible. Pour modifier la quantité de mémoire utilisable par le store orienté colonnes, définissez le paramètre google_columnar_engine.memory_size_in_mb dans le postgresql.conf utilisé par votre instance AlloyDB Omni.

  • Planificateur de requêtes et moteur d'exécution en colonnes : permettent d'utiliser le store orienté colonnes dans les requêtes.

Gestion automatique de la mémoire

Le module de gestion automatique de la mémoire surveille et optimise en continu la consommation de mémoire sur l'ensemble d'une instance AlloyDB Omni. Lorsque vous exécutez vos charges de travail, ce module ajuste la taille du cache de mémoire tampon partagé en fonction de la pression exercée sur la mémoire.

Par défaut, le module de gestion automatique de la mémoire définit la limite supérieure à 80 % de la mémoire système et alloue 10 % de la mémoire système au cache de mémoire tampon partagé. Pour modifier la limite supérieure de la taille du cache de mémoire tampon partagé, définissez le paramètre shared_buffers dans le postgresql.conf utilisé par votre instance AlloyDB Omni.

Autovacuum adaptatif

L'autovacuum adaptatif analyse les opérations en fonction de la charge de travail de la base de données et ajuste automatiquement la fréquence de nettoyage. Cet ajustement automatique permet à la base de données de maintenir des performances optimales, même lorsque la charge de travail change, sans interférence du processus de nettoyage.

L'autovacuum adaptatif utilise les facteurs suivants pour déterminer la fréquence et l'intensité des opérations de nettoyage :

  • Taille de la base de données
  • Nombre de tuples morts dans la base de données
  • Ancienneté des données dans la base de données
  • Nombre de transactions par seconde par rapport à la vitesse de nettoyage estimée
  • Utilisation des ressources

Nœud de calcul d'IA/de ML

Dans AlloyDB Omni, le nœud de calcul d'IA/de ML fonctionnant en arrière-plan fournit les fonctionnalités nécessaires pour appeler les modèles Vertex AI directement depuis la base de données. Le nœud de calcul d'IA/de ML s'exécute sous la forme d'un processus appelé omni ml worker.

Étapes suivantes