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 votre propre environnement IT. AlloyDB Omni et le service AlloyDB pour PostgreSQL entièrement géré sur Google Cloud partagent les mêmes composants principaux. AlloyDB pour PostgreSQL utilise une couche de stockage cloud native qui optimise les performances du journal WAL, tandis qu'AlloyDB Omni utilise la même interface de système de fichiers standard que PostgreSQL.
La portabilité d'AlloyDB Omni vous permet de l'exécuter dans de nombreux environnements, dont les suivants:
- Centres de données
- Ordinateurs portables
- Instances de VM cloud
Cas d'utilisation d'AlloyDB Omni
AlloyDB Omni est adapté aux scénarios suivants:
- Vous avez besoin d'une version évolutive et performante de PostgreSQL, mais vous ne pouvez pas exécuter de base de données dans le cloud en raison de contraintes réglementaires ou de souveraineté des données.
- Vous avez besoin d'une base de données qui continue de s'exécuter même lorsqu'elle est déconnectée d'Internet.
- Pour réduire la latence, vous devez placer votre base de données aussi près que possible de vos utilisateurs.
- Vous souhaitez migrer depuis une ancienne base de données, mais sans vous engager à migrer complètement vers le cloud.
AlloyDB Omni n'inclut pas les fonctionnalités AlloyDB pour PostgreSQL qui reposent sur l'opération in Google Cloud. Si vous souhaitez mettre à niveau votre projet vers les fonctionnalités d'évolutivité, de sécurité et de disponibilité entièrement gérées d'AlloyDB pour PostgreSQL, vous pouvez migrer vos données AlloyDB Omni vers un cluster AlloyDB pour PostgreSQL comme vous le feriez avec toute autre importation de données initiale.
Principales fonctionnalités
- Un serveur de base de données 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 à l' Google Cloud écosystème d'IA, y compris le Vertex AI Model Garden et les outils d'IA générative Open Source.
Prise en charge des fonctionnalités d'automatisation d'AlloyDB pour PostgreSQL dansGoogle Cloud , qui permet à AlloyDB Omni de s'autogérer et de s'ajuster automatiquement.
Par exemple, AlloyDB Omni est compatible avec la gestion automatique de la mémoire et l'autovacuum adaptatif des données obsolètes.
Un conseiller d'index qui analyse les requêtes fréquemment exécutées et recommande de nouveaux index pour améliorer leurs performances.
Le moteur de données en colonnes d'AlloyDB Omni, qui stocke en mémoire les données fréquemment interrogées dans un format en colonnes. Il accélère les opérations sur l'informatique décisionnelle, la création de rapports, ainsi que le traitement 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 PostgreSQL standard.
Fonctionnement d'AlloyDB Omni
Vous pouvez installer AlloyDB Omni en tant que serveur autonome ou dans un environnement Kubernetes.
AlloyDB Omni s'exécute dans un conteneur Docker que vous installez dans votre propre environnement. Nous vous recommandons d'exécuter AlloyDB Omni sur un système Linux avec un stockage SSD et au moins 8 Go de mémoire par CPU.
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. Pour en savoir plus, consultez la section Installer AlloyDB Omni sur Kubernetes.
Vos applications se connectent à votre installation AlloyDB Omni et communiquent avec elle, tout comme elles se connectent à un serveur de base de données PostgreSQL et communiquent avec lui. Le contrôle de l'accès des utilisateurs repose également sur les normes PostgreSQL.
De la journalisation à l'aspiration en passant par le moteur de données en colonnes, vous pouvez configurer le comportement de la base de données d'AlloyDB Omni à l'aide d'options de base de données.
Avantages de l'exécution d'AlloyDB Omni en tant que conteneur
Google distribue AlloyDB Omni en tant que conteneur que vous pouvez exécuter avec des environnements d'exécution de conteneur tels que Docker et Podman. Sur le plan 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 pour s'assurer 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.
- Séparation de sécurité: vous choisissez les éléments auxquels 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 que le conteneur AlloyDB Omni utilise.
- Correctifs et mises à niveau fluides: pour corriger un conteneur, il vous suffit de remplacer l'image existante par une nouvelle.
Sauvegarde des données et reprise sur sinistre
AlloyDB Omni dispose d'un système de sauvegarde et de récupération continue qui vous permet de créer un cluster de base de données à partir de n'importe quel moment au cours d'une période de conservation ajustable. Vous pouvez ainsi récupérer rapidement les données en cas d'accident.
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. Vous pouvez à tout moment restaurer à partir d'une sauvegarde vers un cluster de base de données AlloyDB Omni contenant toutes les données du cluster de base de données d'origine au moment de la création de la sauvegarde.
Pour en savoir plus, consultez Sauvegarder et restaurer AlloyDB Omni.
Pour une autre méthode de reprise après sinistre, vous pouvez effectuer 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 base de données principal désigné vers chacun de ses clusters secondaires. Si nécessaire, vous pouvez promouvoir un cluster de base de données secondaire en cluster de base de données AlloyDB Omni principal.
Pour en savoir plus, consultez la page À propos de la réplication entre centres de données.
Composants de la VM AlloyDB Omni
AlloyDB Omni sur VM se compose de deux ensembles de composants d'architecture: des composants PostgreSQL avec des améliorations AlloyDB pour PostgreSQL et des composants AlloyDB pour PostgreSQL. Le diagramme suivant décrit les deux ensembles de composants, la couche d'infrastructure dans laquelle ils se trouvent sur une VM ou un serveur, ainsi que les fonctionnalités associées que vous pouvez attendre pour chaque composant.
Figure 1 : Architecture AlloyDB Omni
Moteur de la base de données
Ce document décrit l'architecture de la base de données dans AlloyDB Omni dans un conteneur. Dans ce document, nous partons du principe que vous connaissez PostgreSQL.
Un moteur de base de données effectue les tâches suivantes:
- Traduit une requête d'un client en plan exécutable
- Recherche les données nécessaires pour répondre à la requête
- Effectue le filtrage, le tri et l'agrégation nécessaires
- Renvoie les résultats au client
Lorsque l'application cliente envoie une requête à AlloyDB Omni, les actions suivantes se produisent:
- La couche de traitement des requêtes transforme la requête en plan d'exécution qui est transmis à la couche d'exécution des requêtes.
- La couche d'exécution des requêtes effectue les opérations nécessaires pour calculer la réponse à la requête.
- Lors de l'exécution, les données peuvent être chargées à partir du cache tampon ou directement à partir du stockage. Si les données sont chargées à partir du stockage, elles sont stockées dans le cache pour une utilisation ultérieure.
Les ressources utilisées lors du traitement de la requête du client incluent le processeur, la mémoire, les E/S, le réseau et les primitives de synchronisation telles que les verrous de base de données. L'ajustement des performances vise à optimiser l'utilisation des ressources à chaque étape de l'exécution des requêtes.
L'objectif d'un moteur de base de données performant est de répondre à une requête en utilisant le moins de ressources possible. Pour atteindre cet objectif, vous devez commencer par un bon modèle de données et une bonne conception de requêtes.
- Comment répondre aux requêtes en examinant le moins de données possible ?
- Quels index sont nécessaires pour réduire l'espace de recherche et les E/S ?
- Le tri des données nécessite un processeur et, souvent, un accès au disque pour les grands ensembles de données. Comment éviter de trier les données ?
Stockage de données
AlloyDB Omni stocke les données dans des pages de taille fixe stockées dans le système de fichiers sous-jacent. Lorsqu'une requête doit accéder aux données, AlloyDB Omni vérifie d'abord le pool de tampons. Si la ou les pages contenant les données requises ne sont pas trouvées dans le pool de tampons, AlloyDB Omni lit la ou les pages requises à partir du système de fichiers. L'accès aux données à partir du pool de mémoire tampon est beaucoup plus rapide que la lecture à partir du système de fichiers. Par conséquent, il est important de maximiser la taille du pool de mémoire tampon pour la quantité de données auxquelles une application aura accès.
Gestion des ressources
AlloyDB Omni utilise une gestion dynamique de la mémoire pour permettre au pool de mémoire tampon de se développer et de se réduire de manière dynamique dans les limites configurées en fonction des demandes de 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, les premières métriques à prendre en compte sont le taux de réussite du pool de mémoire tampon et le taux de lecture pour voir si votre application profite 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 tampons. Vous pouvez alors envisager de redimensionner l'instance vers une machine plus grande avec plus de mémoire.
Les opérations de récupération, de filtrage, d'agrégation, de tri et de projection des données nécessitent toutes 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, réduisez 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%. Cette quantité laisse suffisamment de marge sur le serveur pour les pics d'utilisation ou les changements de schémas d'accès au fil du temps. L'exécution à une utilisation proche de 100% entraîne des frais généraux en raison de la planification des processus et du changement de contexte, et 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 lorsque vous prenez des décisions concernant les spécifications de la machine.
Les opérations d'entrée/sortie par seconde (IOPS) 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 l'appareil de stockage sous-jacent peut fournir à la base de données. Pour éviter d'atteindre les limites d'IOPS du stockage de la base de données, réduisez les lectures et les écritures sur le stockage en maximisant la quantité de données pouvant tenir dans le pool de tampons.
Moteur de données en colonnes
Le moteur en colonnes accélère le traitement des requêtes SQL pour les analyses, les jointures et les agrégations en fournissant les composants suivants:
Magasin de colonnes en mémoire: contient les données de table et de vue materialisée pour les colonnes sélectionnées dans un format orienté colonnes. Par défaut, le magasin de colonnes consomme 1 Go de 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.Pour savoir comment modifier ce paramètre, consultez la section Modifier les paramètres de configuration.
Planificateur et moteur d'exécution de requêtes en colonnes: permet d'utiliser le magasin de colonnes dans les requêtes.
Gestion automatique de la mémoire
Le gestionnaire de mémoire automatique 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 tampons partagé en fonction de la pression de la mémoire. Par défaut, le gestionnaire de mémoire automatique définit la limite supérieure sur 80 % de la mémoire système et alloue 10% de la mémoire système au cache de tampon partagé.
Pour modifier la limite supérieure de la taille du cache de tampons partagé, définissez le paramètre shared_buffers dans le postgresql.conf utilisé par votre instance AlloyDB Omni.
Pour en savoir plus, consultez la section Gestion automatique de la mémoire.
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 d'aspiration. Cet ajustement automatique permet à la base de données d'atteindre ses performances maximales, même lorsque la charge de travail change, sans interférence du processus d'aspiration.
L'aspirateur automatique adaptatif utilise les facteurs suivants pour déterminer la fréquence et l'intensité des opérations d'aspiration:
- Taille de la base de données
- Nombre de tuples inactifs 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 d'aspiration estimée
L'autovacuum adaptatif offre les avantages suivants:
- Gestion dynamique des ressources d'aspiration: au lieu d'utiliser une limite de coût fixe, AlloyDB Omni utilise des statistiques sur les ressources en temps réel pour ajuster les nœuds d'aspiration. Lorsque le système est occupé, le processus d'aspiration et l'utilisation des ressources associées sont limités. Si suffisamment de mémoire est disponible, de la mémoire supplémentaire est allouée à
maintenance_work_mempour réduire le temps d'aspiration de bout en bout. - Limitation dynamique des XID: surveille automatiquement et en continu la progression de l'aspiration et la vitesse de consommation des ID de transaction. Si un risque de réinitialisation de l'ID de transaction est détecté, AlloyDB Omni ralentit les transactions pour limiter la consommation d'ID. De plus, AlloyDB Omni alloue plus de ressources aux nœuds de nettoyage pour traiter les tables bloquant l'avancement et la libération de l'espace d'ID de transaction. Au cours de ce processus, le nombre total de transactions par seconde est réduit jusqu'à ce que les ID de transaction se trouvent dans une zone de sécurité (observable en tant que sessions en attente sur
AdaptiveVacuumNewXidDelay). Lorsque l'âge de l'ID de transaction augmente, le nombre de nœuds de calcul d'aspiration augmente de manière dynamique. - Aspirateur efficace pour les tables plus grandes: la logique PostgreSQL par défaut utilisée pour décider quand aspirer une table est basée sur des statistiques spécifiques à la table stockées dans
pg_stat_all_tables, qui contient le ratio de tuple mort. Cette logique fonctionne pour les petites tables, mais elle peut ne pas fonctionner efficacement pour les tables plus volumineuses et fréquemment mises à jour. AlloyDB Omni fournit un mécanisme d'analyse mis à jour qui permet de déclencher l'autovacuum plus souvent. Ce mécanisme d'analyse analyse des segments de grandes tables et supprime les tuples morts plus efficacement que la logique PostgreSQL par défaut. - Enregistrer des messages d'avertissement: dans AlloyDB Omni, les bloqueurs de vide, tels que les transactions de longue durée, les transactions préparées ou les emplacements de réplication qui ont perdu leurs cibles, sont détectés et des avertissements sont enregistrés dans les journaux PostgreSQL afin que vous puissiez résoudre les problèmes dans les meilleurs délais.
Nœud de travail d'IA/ML
Dans AlloyDB Omni, le worker en arrière-plan d'IA/ML fournit toutes les fonctionnalités nécessaires pour appeler des modèles Vertex AI directement à partir de la base de données. Le nœud de calcul d'IA/ML s'exécute en tant que processus appelé omni ml worker.
Pour en savoir plus, consultez la page Créer des applications d'IA générative à l'aide d'AlloyDB AI.