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 des 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 la scalabilité, 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.
Choix de déploiement AlloyDB Omni
Vous pouvez installer AlloyDB Omni à l'aide de l'une des options de déploiement suivantes :
AlloyDB Omni utilisant des 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 à l'aide de l'orchestrateur de conteneurs : 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.
L'orchestrateur RPM (aperçu) : déploiement Red Hat Package Manager (RPM) pour les VM ou les serveurs Bare Metal. Cette option inclut une plate-forme d'orchestration qui automatise le déploiement et la gestion dans les environnements non Kubernetes. Il étend la flexibilité du cloud à l'infrastructure de votre choix, sans nécessiter de couches de conteneurisation comme Docker.
AlloyDB Omni avec RPM (preview) : package autonome 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.
Vous pouvez configurer le comportement de la base de données AlloyDB Omni à l'aide des options de base de données, y compris la journalisation, le nettoyage et le moteur de données en colonnes. Pour en savoir plus, consultez Options de téléchargement et d'installation d'AlloyDB Omni disponibles.
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.
AlloyDB Omni dans un environnement RHEL
AlloyDB Omni propose deux options de déploiement pour un environnement RHEL, qui dépendent de vos besoins en matière d'automatisation et de scaling.
AlloyDB Omni avec RPM
L'option de déploiement RPM (Preview) est une installation autonome Red Hat Package Manager (RPM) conçue pour les environnements dans lesquels vous souhaitez une base de données AlloyDB Omni non conteneurisée. Cette option est compatible avec RHEL 9 et Rocky Linux 9.
- Intégration directe à l'OS : s'exécute en tant qu'ensemble de composants logiciels intégrés directement sur l'OS hôte.
- Stockage existant : utilise le système de fichiers Linux standard (ext4 et xfs), qui est compatible avec l'infrastructure de stockage et les pratiques de gestion existantes.
- Simplicité : convient aux configurations à instance unique où une intégration profonde avec l'OS hôte est requise, sans couches d'orchestration supplémentaires.
L'outil d'orchestration RPM
L'option de déploiement de l'orchestrateur RPM (Preview) utilise les mêmes packages RPM qu'AlloyDB Omni avec RPM, mais ajoute une plate-forme d'orchestration pour automatiser la gestion dans les environnements non Kubernetes.
- Flexibilité semblable au cloud : étend l'automatisation à l'infrastructure sur site, en gérant l'amorçage, le basculement et la gestion du cycle de vie.
- Frameworks d'automatisation : s'intègrent à des outils populaires tels qu'Ansible, ce qui permet aux équipes d'utiliser leurs compétences existantes. Vous pouvez également utiliser des outils de ligne de commande spécialement conçus.
- Fonctionnalités Enterprise : spécialement conçues pour assurer la haute disponibilité et la reprise après sinistre grâce à un gestionnaire de cluster centralisé.
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 Omni et les composants spécifiques à AlloyDB Omni.
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.
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. Maximisez la quantité de données pouvant être stockées dans le pool de mémoire tampon ou dans la couche 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_mbdans lepostgresql.confutilisé 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.
Pour en savoir plus, consultez À propos du moteur de données en colonnes AlloyDB pour PostgreSQL.
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.
Plan de contrôle de l'orchestrateur
L'orchestrateur Red Hat RPM utilise un gestionnaire de cluster centralisé pour automatiser les opérations à l'échelle du cluster, y compris l'amorçage et le basculement.
Interfaces de gestion
L'orchestrateur Red Hat RPM fournit à la fois un utilitaire de ligne de commande (alloydbctl) et des rôles Ansible pour gérer un ou plusieurs clusters à grande échelle.
Optimisation des performances
L'orchestrateur Red Hat RPM inclut une compatibilité intégrée avec PgBouncer pour le regroupement de connexions et HAProxy pour l'équilibrage de charge entre les points de terminaison en lecture/écriture et en lecture seule.
Étapes suivantes
Commencez par choisir l'une des options de déploiement d'AlloyDB Omni suivantes :