:Serverless mode

Présentation

En mode Serverless, AnalyticDB for PostgreSQL dissocie les ressources de calcul et de stockage afin de permettre leur mise à l'échelle indépendante. Les ressources de stockage restent facturées selon le modèle de paiement à l'utilisation, tandis que les capacités de calcul peuvent être ajustées séparément pour répondre aux besoins métier. Cette approche réduit les coûts de stockage et améliore l'efficacité opérationnelle.

Le mode Serverless d'AnalyticDB for PostgreSQL présente les avantages suivants par rapport au mode de stockage élastique :

• Réduction des coûts de stockage et utilisation des ressources à la demande. Ce mode permet d'effectuer des analyses de données rentables sans migrer vos données vers d'autres supports de stockage. Il répond aux exigences d'analyse des secteurs financier et Internet.

• Optimisation des écritures à haut débit et des opérations de traitement par lots haute performance grâce à une mise à l'échelle élastique, adaptée aux scénarios impliquant de grands volumes de données et d'importantes fluctuations de trafic.

• Fonctionnalité de partage de données basée sur la séparation du stockage et du calcul. Les données partagées sont accessibles depuis d'autres bases de données sans export ni import. Cette solution est plus simple et plus économique que l'accès aux données dans les entrepôts de données traditionnels.

Remarques relatives à l'utilisation

Comparaison des modes de service

Le mode Serverless prend en charge la plupart des fonctionnalités du mode de stockage élastique. Le tableau suivant décrit les différences entre ces deux modes de service.

Limites

Le mode Serverless prend en charge plus de 95 % des fonctionnalités du mode de stockage élastique. Dans la plupart des cas, la même syntaxe s'applique aux deux modes. Des outils tels que le connecteur JDBC (Java Database Connectivity), le connecteur ODBC (Open Database Connectivity) et psql s'utilisent de la même manière en mode Serverless qu'en mode de stockage élastique. Le tableau suivant décrit les limites d'AnalyticDB for PostgreSQL en mode Serverless pour certaines fonctionnalités.

Migration des données

Vous pouvez migrer des données depuis une instance AnalyticDB for PostgreSQL en mode de stockage élastique ou réservé vers une instance en mode Serverless. Pour plus d'informations, consultez la rubrique Migration de données entre des instances AnalyticDB for PostgreSQL.

Le tableau suivant indique la prise en charge, par le mode Serverless, des différents types de migration de données.

Planification automatique (en aperçu sur invitation)

Les instances AnalyticDB for PostgreSQL en mode de planification automatique Serverless peuvent être automatiquement mises en pause et reprises en fonction de la détection du trafic. En l'absence de trafic, les instances passent automatiquement à l'état inactif. Aucun frais n'est facturé pour les ressources de calcul lorsque les instances sont inactives.

Les instances AnalyticDB for PostgreSQL en mode de planification automatique Serverless vous permettent de modifier les valeurs des paramètres Computing Resource Threshold et Wait Time for Idle Resource Release. Pour plus d'informations, consultez la rubrique Configuration des ressources de l'instance.

Les instances en mode de planification automatique Serverless sont facturées à la seconde en fonction des unités de calcul AnalyticDB (ACU), qui mesurent la puissance de calcul des instances. Le système collecte le nombre d'ACU utilisées et génère les factures sur une base horaire. Pour plus d'informations, consultez la rubrique Tarification.

Mise à l'échelle élastique

Les instances en mode Serverless peuvent être mises à l'échelle en quelques minutes. Les performances de mise à l'échelle suivantes sont fournies à titre indicatif :

• Une instance disposant de 16 nœuds de calcul ou moins peut être mise à l'échelle en 60 secondes.

• Une instance disposant de plus de 16 nœuds de calcul peut être mise à l'échelle en 5 minutes.

Tirez parti de la capacité de mise à l'échelle élastique d'AnalyticDB for PostgreSQL en mode Serverless pour augmenter le nombre de nœuds de calcul avant les pics de trafic prévus, tels que le Double 11, puis réduisez-le après ces périodes de pointe. AnalyticDB for PostgreSQL est facturé à l'heure en fonction de la durée réelle d'utilisation des ressources et des spécifications des nœuds de calcul. Cette approche vous permet de minimiser les coûts tout en garantissant les performances du service.

En mode Serverless, chaque nœud de calcul dispose d'une capacité de stockage maximale. Avant de réduire le nombre de nœuds de calcul, assurez-vous que le volume total de données ne dépasse pas la capacité de stockage maximale combinée de tous les nœuds restants. Par exemple, si chaque nœud de calcul offre 2 cœurs, 8 Go de mémoire et une capacité de stockage maximale de 960 Go, et que vous souhaitez réduire votre instance à quatre nœuds de calcul, le volume total de données ne doit pas dépasser 3 840 Go (960 Go × 4).

Le tableau suivant décrit la capacité de stockage maximale des différentes spécifications de nœuds de calcul pour AnalyticDB for PostgreSQL en mode Serverless.

À l'exception des interruptions de service survenant avant et après la mise à l'échelle, les charges de travail restent lisibles et accessibles en écriture pendant le processus de mise à l'échelle.

Partage de données (bêta)

Par rapport à la méthode d'importation et d'exportation de données utilisée dans les entrepôts de données traditionnels, le partage de données proposé par AnalyticDB for PostgreSQL en mode Serverless présente les avantages suivants :

• Réduction des coûts de stockage : aucune réplication ni migration de données n'est nécessaire entre les instances AnalyticDB for PostgreSQL. Une seule copie des données est stockée dans le stockage distribué et peut être partagée par plusieurs instances dans la plage spécifiée, ce qui réduit l'espace de stockage requis.

• Facilité d'utilisation : après avoir créé un partage sur une instance productrice, accordé les autorisations et importé les données dans le partage, vous pouvez accéder aux données partagées depuis une instance consommatrice de la même manière que depuis l'instance productrice. Le schéma de table n'a pas besoin d'être migré. L'ajout ou la suppression d'objets partagés ainsi que les modifications d'autorisation sont automatiquement synchronisés avec l'instance consommatrice.

• Cohérence des données : les instances consommatrices peuvent accéder aux données partagées avec des capacités proches de celles des instances productrices. De plus, les instances consommatrices peuvent lire les dernières données écrites par les instances productrices, garantissant ainsi les propriétés ACID (atomicité, cohérence, isolation et durabilité) des transactions.

Le partage de données vous aide à résoudre les problèmes suivants :

• Isolation entre des permissions organisationnelles complexes : par exemple, supposons qu'une instance soit créée au siège social et une autre dans une succursale. Le partage de données permet à l'instance de la succursale d'accéder à des données spécifiques de l'instance du siège social.

• Isolation entre des ressources métier complexes : par exemple, supposons que les ressources physiques soient isolées entre les types d'activités ETL (extract, transform, load) et ad hoc. Le partage de données permet de partager les résultats ETL entre les instances impliquées dans les requêtes ad hoc.

• Échec de la collaboration intermétier : par exemple, si la même copie de données doit être analysée par les équipes R&D, commerciales, opérationnelles et financières, le partage de données permet l'accès aux données par différents groupes métier au sein d'une organisation.

Le partage de données est en phase de test bêta et présente les limites suivantes :

• Le partage de données est pris en charge sur les tables standard. Il n'est pas pris en charge sur les tables partitionnées, les tables externes, les vues, les schémas ou les fonctions.

• Le partage de données est pris en charge sur les tables distribuées par hachage. Il n'est pas pris en charge sur les tables répliquées ou aléatoires.

• Le partage de données n'est pas pris en charge pour les sous-transactions.

• Si plusieurs partages existent dans une instance productrice, une instance consommatrice ne peut s'abonner qu'à l'un d'entre eux.

• Les opérations DDL ne sont pas autorisées sur les tables partagées. Pour effectuer des opérations DDL sur une table partagée, vous devez désactiver le partage pour cette table.

Références

• [[Avis] Publication du mode Serverless pour AnalyticDB for PostgreSQL](t2130215.dita#concept_2130215)

• Démarrage rapide pour le mode de stockage élastique

• Migration de données entre des instances AnalyticDB for PostgreSQL

• Test de performance pour l'importation et l'interrogation des données en mode Serverless Pro

• 数据共享