Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Important
Azure Cosmos DB pour PostgreSQL n’est plus pris en charge pour les nouveaux projets. N’utilisez pas ce service pour les nouveaux projets. Utilisez plutôt l’un des deux services suivants :
Utilisez Azure Cosmos DB pour NoSQL pour une solution de base de données distribuée conçue pour des scénarios à grande échelle avec un contrat de niveau de service de disponibilité (SLA) de 99,999%, une mise à l’échelle automatique instantanée et un basculement automatique entre plusieurs régions.
Utilisez la fonctionnalité Elastic Clusters d'Azure Database pour PostgreSQL pour un PostgreSQL partagé utilisant l'extension open source Citus.
La taille d’un cluster, que ce soit le nombre de nœuds ou leur capacité matérielle, est facile à modifier. Toutefois, vous devez choisir une taille initiale pour un nouveau cluster. Voici quelques conseils pour effectuer un choix raisonnable.
Cas d’usage
Azure Cosmos DB for PostgreSQL est fréquemment utilisé de différentes manières.
SaaS mutualisé
En cas de migration vers Azure Cosmos DB for PostgreSQL à partir d’une instance de base de données PostgreSQL à nœud unique existante, choisissez un cluster dont le nombre de vCores Worker et la mémoire RAM sont au total égaux à ceux de l’instance d’origine. Dans de tels scénarios, nous avons constaté que les performances ont doublé, voire triplé, car le partitionnement améliore l’utilisation des ressources, ce qui permet des index plus petits, etc.
Le nombre de vCore constitue en fait la seule décision. L’allocation de RAM est actuellement déterminée en fonction du nombre de vCore, comme décrit dans la page Calcul et stockage. Le nœud coordinateur n’a pas besoin d’autant de RAM que les nœuds Worker, mais il n’existe aucun moyen de choisir la RAM et les vCore indépendamment.
Analyse en temps réel
Nombre total de vCores : quand les données de travail tiennent dans la mémoire RAM, vous pouvez vous attendre à une amélioration linéaire des performances proportionnelle au nombre de cœurs Worker sur Azure Cosmos DB for PostgreSQL. Pour déterminer le nombre de vCores adapté à vos besoins, tenez compte de la latence actuelle des requêtes dans votre base de données à nœud unique et de la latence nécessaire dans Azure Cosmos DB for PostgreSQL. Divisez la latence actuelle par la latence souhaitée, puis arrondissez le résultat.
RAM worker : le meilleur des cas serait de fournir suffisamment de mémoire pour que la majorité de la plage de travail tienne dans la mémoire. Le type de requêtes que votre application utilise affecte les besoins en mémoire. Vous pouvez exécuter EXPLAIN ANALYZE sur une requête pour déterminer la quantité de mémoire nécessaire. N’oubliez pas que les vCores et la RAM sont ajustés ensemble comme décrit dans l’article sur le le Calcul et le Stockage.
Étapes suivantes
- Mise à l'échelle d'un cluster
- En savoir plus sur les options de performances des clusters.