TOC

Pools de connexions aux bases de données gérées et analyse comparative PostgreSQL à l’aide de pgbench

introduction

DigitalOcean Managed Databases vous permet de mettre à l’échelle votre base de données PostgreSQL à l’aide de plusieurs méthodes. L’une de ces méthodes est un pool de connexions intégré qui vous permet de gérer efficacement un grand nombre de connexions client et de réduire l’encombrement du processeur et de la mémoire de ces connexions ouvertes. En utilisant un pool de connexions et en partageant un ensemble fixe de connexions recyclables, vous pouvez gérer beaucoup plus de connexions client simultanées et réduire les performances supplémentaires de votre base de données PostgreSQL.

Dans ce didacticiel, nous utiliserons + pgbench +, l’outil d’analyse comparative intégré de PostgreSQL, pour exécuter des tests de charge sur une base de données PostgreSQL gérée DigitalOcean. Nous allons explorer les pools de connexions, décrire leur fonctionnement et montrer comment en créer un à l’aide du panneau de configuration Cloud. Enfin, en utilisant les résultats des tests + pgbench +, nous montrerons comment l’utilisation d’un pool de connexions peut être une méthode peu coûteuse d’accroître le débit de la base de données.

Conditions préalables

Pour compléter ce tutoriel, vous aurez besoin de:

  • Un cluster de bases de données PostgreSQL gérées par DigitalOcean. Pour savoir comment provisionner et configurer un cluster DigitalOcean PostgreSQL, consultez la base de données gérée documentation du produit.

  • Un ordinateur client sur lequel PostgreSQL est installé. Par défaut, votre installation PostgreSQL contiendra l’utilitaire de benchmarking + pgbench + et le client + psql +, que nous utiliserons tous les deux dans ce guide. Consultez Comment installer et utiliser PostgreSQL sur Ubuntu 18.04 pour apprendre à installer PostgreSQL. Si vous n’exécutez pas Ubuntu sur votre ordinateur client, vous pouvez utiliser le moteur de recherche de versions pour trouver le didacticiel approprié.

Une fois que vous avez un cluster DigitalOcean PostgreSQL opérationnel et une machine cliente avec + pgbench + installé, vous êtes prêt à commencer avec ce guide.

Étape 1 - Création et initialisation + benchmark + base de données

Avant de créer un pool de connexions pour notre base de données, nous allons d’abord créer la base de données + benchmark + sur notre cluster PostgreSQL et l’alimenter avec des données factices sur lesquelles + pgbench + exécutera ses tests. L’utilitaire + pgbench + exécute à plusieurs reprises une série de cinq commandes SQL (composées de requêtes + SELECT +, + UPDATE + et + INSERT +) à l’aide de plusieurs threads et clients, et calcule une métrique de performance utile appelé T transactions p er S seconde (TPS). Le TPS est une mesure du débit de la base de données, comptant le nombre de transactions atomiques traitées par la base de données en une seconde. Pour en savoir plus sur les commandes spécifiques exécutées par + pgbench +, consultez Quelle est la «transaction» effectivement exécutée dans pgbench? de la documentation officielle + pgbench +.

Commençons par nous connecter à notre cluster PostgreSQL et créer la base de données + benchmark +.

Tout d’abord, récupérez les * Détails de connexion * de votre cluster en naviguant dans * Bases de données * et en localisant votre cluster PostgreSQL. Cliquez dans votre cluster. Vous devriez voir une page de présentation du cluster contenant la boîte * Détails de connexion * suivante:

image: https: //assets.digitalocean.com/articles/managed_db_pools/conn_details.png [Détails de la connexion au cluster PostgreSQL]

À partir de là, nous pouvons analyser les variables de configuration suivantes:

  • Utilisateur administrateur: + doadmin +

  • Mot de passe administrateur:

  • Point de terminaison du cluster: + dbaas-test-do-user-3587522-0.db.ondigitalocean.com +

  • Port de connexion: + 25060 +

  • Base de données à laquelle se connecter: + defaultdb +

  • Mode SSL: + require + (utilisez une connexion cryptée SSL pour une sécurité accrue)

Prenez note de ces paramètres, car vous en aurez besoin lorsque vous utiliserez à la fois les outils + psql + client et + pgbench +.

Cliquez sur la liste déroulante au-dessus de cette case et sélectionnez * Chaîne de connexion *. Nous allons copier cette chaîne et la transmettre à + ​​psql + pour se connecter à ce nœud PostgreSQL.

Connectez-vous à votre cluster en utilisant + psql + et la chaîne de connexion que vous venez de copier:

psql postgresql://doadmin:@:25060/defaultdb?sslmode=require

L’invite suivante du client PostgreSQL devrait indiquer que vous vous êtes connecté à votre cluster PostgreSQL avec succès:

Outputpsql (10.6 (Ubuntu 10.6-0ubuntu0.18.04.1))
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

defaultdb=>

À partir de là, créez la base de données + benchmark +:

CREATE DATABASE benchmark;

Vous devriez voir la sortie suivante:

OutputCREATE DATABASE

Maintenant, déconnectez-vous du cluster:

\q

Avant d’exécuter les tests + pgbench +, nous devons renseigner cette base de données + benchmark + avec des tables et des données factices nécessaires à l’exécution des tests.

Pour ce faire, nous allons lancer + pgbench + avec les drapeaux suivants:

  • + -h +: Le point de terminaison du cluster PostgreSQL

  • + -p +: port de connexion du cluster PostgreSQL

  • + -U +: Le nom d’utilisateur de la base de données

  • + -i +: indique que nous souhaitons initialiser la base de données + benchmark + avec des tables de benchmarking et leurs données factices.

  • + -s +: Définissez un facteur d’échelle de 150, qui multipliera les tailles de table par 150. Le facteur d’échelle par défaut + 1 + donne des tableaux de tailles suivantes:

    table                   # of rows
---------------------------------
pgbench_branches        1
pgbench_tellers         10
pgbench_accounts        100000
pgbench_history         0

    + En utilisant un facteur d’échelle de 150, la table + pgbench_accounts + contiendra 15 000 000 lignes.

Exécutez la commande complète + pgbench +:

pgbench -h  -p 25060 -U doadmin -i -s 150 benchmark

Après avoir exécuté cette commande, vous serez invité à entrer le mot de passe de l’utilisateur de la base de données que vous avez spécifié. Entrez le mot de passe et appuyez sur + ENTER.

Vous devriez voir la sortie suivante:

Outputdropping old tables...
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
creating tables...
generating data...
100000 of 15000000 tuples (0%) done (elapsed 0.19 s, remaining 27.93 s)
200000 of 15000000 tuples (1%) done (elapsed 0.85 s, remaining 62.62 s)
300000 of 15000000 tuples (2%) done (elapsed 1.21 s, remaining 59.23 s)
400000 of 15000000 tuples (2%) done (elapsed 1.63 s, remaining 59.44 s)
500000 of 15000000 tuples (3%) done (elapsed 2.05 s, remaining 59.51 s)
. . .
14700000 of 15000000 tuples (98%) done (elapsed 70.87 s, remaining 1.45 s)
14800000 of 15000000 tuples (98%) done (elapsed 71.39 s, remaining 0.96 s)
14900000 of 15000000 tuples (99%) done (elapsed 71.91 s, remaining 0.48 s)
15000000 of 15000000 tuples (100%) done (elapsed 72.42 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.

À ce stade, nous avons créé une base de données d’analyse comparative, contenant les tables et les données nécessaires à l’exécution des tests + pgbench +. Nous pouvons maintenant passer à l’exécution d’un test de base que nous utiliserons pour comparer les performances avant et après l’activation du regroupement de connexions.

Étape 2 - Exécuter un test Baseline + pgbench +

Avant de lancer notre premier test, il convient de se plonger dans ce que nous essayons d’optimiser avec les pools de connexions.

Généralement, lorsqu’un client se connecte à une base de données PostgreSQL, le processus principal du système d’exploitation PostgreSQL se transforme en un processus enfant correspondant à cette nouvelle connexion. Quand il n’y a que quelques connexions, cela pose rarement un problème. Toutefois, à mesure que les clients et les connexions évoluent, la surcharge de temps CPU et mémoire liée à la création et à la maintenance de ces connexions commence à s’additionner, en particulier si l’application en question n’utilise pas efficacement les connexions à la base de données. De plus, le paramètre + max_connections + PostgreSQL peut limiter le nombre de connexions client autorisées, ce qui entraîne le refus ou la suppression de connexions supplémentaires.

image: https: //assets.digitalocean.com/articles/managed_db_pools/no_connection_pool.png [Connexions à la base de données sans pooling]

Un pool de connexions maintient ouvert un nombre fixe de connexions de base de données, la * taille du pool *, qu’il utilise ensuite pour distribuer et exécuter les demandes des clients. Cela signifie que vous pouvez gérer beaucoup plus de connexions simultanées, gérer efficacement les clients inactifs ou stagnants, ainsi que mettre en file d’attente les demandes des clients lors de pics de trafic au lieu de les rejeter. En recyclant les connexions, vous pouvez utiliser plus efficacement les ressources de votre machine dans un environnement où le volume de connexion est important et réduire les performances supplémentaires de votre base de données.

image: https: //assets.digitalocean.com/articles/managed_db_pools/with_connection_pool.png [Connexions à la base de données avec pooling]

Un pool de connexions peut être implémenté côté application ou en tant que middleware entre la base de données et votre application. Le programme de gestion de connexions de bases de données gérées repose sur pgBouncer, un système de gestion des connexions middleware léger à code source ouvert pour PostgreSQL. Son interface est disponible via l’interface utilisateur du panneau de configuration du cloud.

Accédez à * Bases de données * dans le Panneau de configuration, puis cliquez sur votre cluster PostgreSQL. De là, cliquez sur * Connection Pools *. Ensuite, cliquez sur * Créer un groupe de connexions *. Vous devriez voir la fenêtre de configuration suivante:

image: https: //assets.digitalocean.com/articles/managed_db_pools/connection_pool_blank.png [Fenêtre de configuration des pools de connexion]

Ici, vous pouvez configurer les champs suivants:

  • * Nom du pool *: Un nom unique pour votre pool de connexion

  • * Base de données *: la base de données pour laquelle vous souhaitez regrouper les connexions

  • * Utilisateur *: l’utilisateur PostgreSQL que le pool de connexion authentifiera comme

  • * Mode *: Un des * Session *, * Transaction *, ou * Statement *. Cette option contrôle la durée pendant laquelle le pool affecte une connexion d’arrière-plan à un client.

  • * Session *: le client conserve la connexion jusqu’à ce qu’il se déconnecte explicitement.

  • * Transaction *: le client obtient la connexion jusqu’à ce qu’il termine une transaction, après quoi la connexion est renvoyée au pool.

  • * Statement *: le pool recycle de manière agressive les connexions après chaque relevé du client. En mode instruction, les transactions multi-instructions ne sont pas autorisées. Pour en savoir plus, consultez la documentation sur les pools de connexions https://www.digitalocean.com/docs/databases/how-to/postgresql/manage-connection-pools.

  • * Taille du pool *: nombre de connexions que le pool de connexions gardera ouvert entre lui-même et la base de données.

Avant de créer un pool de connexions, nous allons exécuter un test de base auquel nous pouvons comparer les performances de la base de données avec le pool de connexions.

Dans ce didacticiel, nous utiliserons une configuration de base de données gérée de 4 Go de RAM, 2 vCPU, 80 Go. Vous pouvez mettre à l’échelle les paramètres de test de référence dans cette section en fonction des spécifications de votre cluster PostgreSQL.

Les clusters DigitalOcean Managed Database ont le paramètre PostgreSQL + max_connections + prédéfini à 25 connexions pour 1 Go de RAM. Un nœud PostgreSQL RAM de 4 Go a donc + max_connections + égal à 100. De plus, pour toutes les grappes, 3 connexions sont réservées à la maintenance. Donc, pour ce cluster PostgreSQL RAM de 4 Go, 97 connexions sont disponibles pour le regroupement de connexions.

Dans cet esprit, exécutons notre premier test de base + pgbench +.

Connectez-vous à votre ordinateur client. Nous allons exécuter + pgbench +, en spécifiant le point de terminaison de la base de données, le port et l’utilisateur comme d’habitude. De plus, nous fournirons les drapeaux suivants:

  • + -c +: nombre de clients simultanés ou de sessions de base de données à simuler. Nous avons défini ce paramètre sur 50 afin de simuler un nombre de connexions simultanées inférieur au paramètre + max_connections + de notre cluster PostgreSQL.

  • + -j +: Le nombre de threads de travail + pgbench + va utiliser pour exécuter le test. Si vous utilisez un ordinateur multiprocesseur, vous pouvez l’ajuster pour répartir les clients entre les threads. Sur une machine à deux cœurs, nous réglons ceci à «+ 2 +».

  • + -P +: Affiche la progression et les métriques toutes les + 60 + secondes.

  • + -T +: Lance le test d’évaluation pendant + 600 + `secondes (10 minutes). Pour obtenir des résultats cohérents et reproductibles, il est important d’exécuter le test de performances pendant plusieurs minutes ou par le biais d’un cycle de point de contrôle.

Nous préciserons également que nous ne souhaitons pas utiliser l’indice de référence avec la base de données `+ benchmark + 'que nous avons précédemment créée et remplie.

Exécutez la commande complète suivante + pgbench +:

pgbench -h  -p 25060 -U doadmin -c 50 -j 2 -P 60 -T 600 benchmark

Appuyez sur + ENTER puis tapez le mot de passe de l’utilisateur` + admin` pour commencer à exécuter le test. Vous devriez voir une sortie semblable à celle-ci (les résultats dépendront des spécifications de votre cluster PostgreSQL):

Outputstarting vacuum...end.
progress: 60.0 s, 157.4 tps, lat 282.988 ms stddev 40.261
progress: 120.0 s, 176.2 tps, lat 283.726 ms stddev 38.722
progress: 180.0 s, 167.4 tps, lat 298.663 ms stddev 238.124
progress: 240.0 s, 178.9 tps, lat 279.564 ms stddev 43.619
progress: 300.0 s, 178.5 tps, lat 280.016 ms stddev 43.235
progress: 360.0 s, 178.8 tps, lat 279.737 ms stddev 43.307
progress: 420.0 s, 179.3 tps, lat 278.837 ms stddev 43.783
progress: 480.0 s, 178.5 tps, lat 280.203 ms stddev 43.921
progress: 540.0 s, 180.0 tps, lat 277.816 ms stddev 43.742
progress: 600.0 s, 178.5 tps, lat 280.044 ms stddev 43.705
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 150
query mode: simple
number of clients: 50
number of threads: 2
duration: 600 s
number of transactions actually processed: 105256
latency average = 282.039 ms
latency stddev = 84.244 ms
tps = 175.329321 (including connections establishing)
tps = 175.404174 (excluding connections establishing)

Nous avons observé ici que, sur une période de 10 minutes avec 50 sessions simultanées, nous avons traité 105 256 transactions avec un débit d’environ 175 transactions par seconde.

Maintenant, exécutons le même test, en utilisant cette fois 150 clients simultanés, une valeur supérieure à + ​​max_connections + pour cette base de données, afin de simuler synthétiquement un afflux massif de connexions client:

pgbench -h  -p 25060 -U doadmin -c 150 -j 2 -P 60 -T 600 benchmark

Vous devriez voir une sortie similaire à celle-ci:

Outputstarting vacuum...end.
connection to database "pgbench" failed:
FATAL:  remaining connection slots are reserved for non-replication superuser connections
progress: 60.0 s, 182.6 tps, lat 280.069 ms stddev 42.009
progress: 120.0 s, 253.8 tps, lat 295.612 ms stddev 237.448
progress: 180.0 s, 271.3 tps, lat 276.411 ms stddev 40.643
progress: 240.0 s, 273.0 tps, lat 274.653 ms stddev 40.942
progress: 300.0 s, 272.8 tps, lat 274.977 ms stddev 41.660
progress: 360.0 s, 250.0 tps, lat 300.033 ms stddev 282.712
progress: 420.0 s, 272.1 tps, lat 275.614 ms stddev 42.901
progress: 480.0 s, 261.1 tps, lat 287.226 ms stddev 112.499
progress: 540.0 s, 272.5 tps, lat 275.309 ms stddev 41.740
progress: 600.0 s, 271.2 tps, lat 276.585 ms stddev 41.221
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 150
query mode: simple
number of clients: 150
number of threads: 2
duration: 600 s
number of transactions actually processed: 154892
latency average = 281.421 ms
latency stddev = 125.929 ms
tps = 257.994941 (including connections establishing)
tps = 258.049251 (excluding connections establishing)

Notez l’erreur + FATAL +, indiquant que + pgbench + a atteint le seuil de 100 connexions défini par + max_connections +, ce qui entraîne une connexion refusée. L’essai était toujours en mesure de se terminer, avec un TPS d’environ 257.

À ce stade, nous pouvons étudier comment un pool de connexions pourrait potentiellement améliorer le débit de notre base de données.

Étape 3 - Création et test d’un pool de connexions

Au cours de cette étape, nous allons créer un pool de connexions et réexécuter le test + pgbench + précédent pour voir si nous pouvons améliorer le débit de notre base de données.

En général, les paramètres + max_connections + et le pool de connexions sont ajustés en même temps pour maximiser la charge de la base de données. Toutefois, étant donné que + max_connections + est extrait de l’utilisateur dans les bases de données gérées DigitalOcean, nos principaux leviers sont les paramètres Pool de connexion * Mode * et * Taille *.

Commençons par créer un pool de connexions en mode * Transaction * qui garde toutes les connexions backend disponibles ouvertes.

Accédez à * Bases de données * dans le Panneau de configuration, puis cliquez sur votre cluster PostgreSQL. De là, cliquez sur * Connection Pools *. Ensuite, cliquez sur * Créer un groupe de connexions *.

Dans la fenêtre de configuration qui apparaît, renseignez les valeurs suivantes:

image: https: //assets.digitalocean.com/articles/managed_db_pools/connection_pool_full.png [Valeurs de configuration du pool de connexions]

Nous nommons ici notre pool de connexions * test-pool * et l’utilisons avec la base de données * benchmark *. Notre utilisateur de base de données est * doadmin * et nous avons défini le pool de connexions sur le mode * Transaction *. Rappelez-vous que, pour un cluster de bases de données gérées doté de 4 Go de RAM, il existe 97 connexions de base de données disponibles. En conséquence, configurez le pool pour conserver des connexions de base de données ouvertes.

Lorsque vous avez terminé, appuyez sur * Create Pool *.

Vous devriez maintenant voir ce pool dans le Panneau de configuration:

image: https: //assets.digitalocean.com/articles/managed_db_pools/connection_pool_ui.png [Pool de connexions dans le panneau de configuration]

Saisissez son URI en cliquant sur * Détails de la connexion *. Il devrait ressembler à ce qui suit

postgres://doadmin:@:/test-pool?sslmode=require

Vous devriez remarquer ici un port différent, et potentiellement un autre noeud final et un nom de base de données correspondant au nom de pool + test-pool +.

Maintenant que nous avons créé le pool de connexions + test-pool, nous pouvons réexécuter le test` + pgbench` que nous avons exécuté ci-dessus.

Réexécutez + pgbench +

À partir de votre ordinateur client, exécutez la commande + pgbench + suivante (avec 150 clients simultanés), en veillant à substituer les valeurs en surbrillance à celles de votre URI de pool de connexions:

pgbench -h  -p  -U doadmin -c 150 -j 2 -P 60 -T 600 test-pool

Ici, nous utilisons à nouveau 150 clients simultanés, exécutons le test sur 2 threads, imprimons la progression toutes les 60 secondes et exécutons le test pendant 600 secondes. Nous avons défini le nom de la base de données sur + test-pool +, le nom du pool de connexions.

Une fois le test terminé, vous devriez voir une sortie semblable à celle-ci (notez que ces résultats varieront en fonction des spécifications de votre nœud de base de données):

Outputstarting vacuum...end.
progress: 60.0 s, 240.0 tps, lat 425.251 ms stddev 59.773
progress: 120.0 s, 350.0 tps, lat 428.647 ms stddev 57.084
progress: 180.0 s, 340.3 tps, lat 440.680 ms stddev 313.631
progress: 240.0 s, 364.9 tps, lat 411.083 ms stddev 61.106
progress: 300.0 s, 366.5 tps, lat 409.367 ms stddev 60.165
progress: 360.0 s, 362.5 tps, lat 413.750 ms stddev 59.005
progress: 420.0 s, 359.5 tps, lat 417.292 ms stddev 60.395
progress: 480.0 s, 363.8 tps, lat 412.130 ms stddev 60.361
progress: 540.0 s, 351.6 tps, lat 426.661 ms stddev 62.960
progress: 600.0 s, 344.5 tps, lat 435.516 ms stddev 65.182
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 150
query mode: simple
number of clients: 150
number of threads: 2
duration: 600 s
number of transactions actually processed: 206768
latency average = 421.719 ms
latency stddev = 114.676 ms
tps = 344.240797 (including connections establishing)
tps = 344.385646 (excluding connections establishing)

Remarquez ici que nous avons pu augmenter le débit de notre base de données de 257 TPS à 344 TPS avec 150 connexions simultanées (une augmentation de 33%) sans rencontrer la limite + max_connections + que nous avions précédemment atteinte sans pool de connexions. En plaçant un pool de connexions devant la base de données, nous pouvons éviter les connexions interrompues et augmenter considérablement le débit de la base de données dans un environnement comportant un grand nombre de connexions simultanées.

Si vous exécutez le même test, mais avec une valeur + -c + de 50 (spécifiant un nombre inférieur de clients), les avantages de l’utilisation d’un pool de connexions deviennent beaucoup moins évidents:

Outputstarting vacuum...end.
progress: 60.0 s, 154.0 tps, lat 290.592 ms stddev 35.530
progress: 120.0 s, 162.7 tps, lat 307.168 ms stddev 241.003
progress: 180.0 s, 172.0 tps, lat 290.678 ms stddev 36.225
progress: 240.0 s, 172.4 tps, lat 290.169 ms stddev 37.603
progress: 300.0 s, 177.8 tps, lat 281.214 ms stddev 35.365
progress: 360.0 s, 177.7 tps, lat 281.402 ms stddev 35.227
progress: 420.0 s, 174.5 tps, lat 286.404 ms stddev 34.797
progress: 480.0 s, 176.1 tps, lat 284.107 ms stddev 36.540
progress: 540.0 s, 173.1 tps, lat 288.771 ms stddev 38.059
progress: 600.0 s, 174.5 tps, lat 286.508 ms stddev 59.941
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 150
query mode: simple
number of clients: 50
number of threads: 2
duration: 600 s
number of transactions actually processed: 102938
latency average = 288.509 ms
latency stddev = 83.503 ms
tps = 171.482966 (including connections establishing)
tps = 171.553434 (excluding connections establishing)

Nous voyons ici que nous n’avons pas pu augmenter le débit en utilisant un pool de connexions. Notre débit est descendu à 171 TPS à partir de 175 TPS.

Bien que dans ce guide, nous utilisions + pgbench + avec son ensemble de données de référence intégré, le meilleur test pour déterminer s’il faut ou non utiliser un pool de connexions est une charge de référence qui représente avec précision la charge de production de votre base de données, par rapport aux données de production. La création de scripts et de données d’analyse comparative personnalisés dépasse le cadre de ce guide, mais pour en savoir plus, consultez la documentation officielle https://www.postgresql.org/docs/10/pgbench.html].

Conclusion

Le regroupement de connexions aux bases de données gérées DigitalOcean est une fonctionnalité puissante qui peut vous aider à réduire rapidement les performances supplémentaires de votre base de données. Avec d’autres techniques telles que la réplication, la mise en cache et le sharding, le regroupement de connexions peut vous aider à redimensionner votre couche de base de données pour traiter un volume encore plus important de demandes.

Dans ce guide, nous nous sommes concentrés sur un scénario de test simpliste et synthétique utilisant l’outil d’analyse comparative + pgbench + intégré de PostgreSQL et son test de référence par défaut. Dans tout scénario de production, vous devez exécuter des tests de performance par rapport aux données de production réelles lors de la simulation de la charge de production. Cela vous permettra d’ajuster votre base de données pour votre modèle d’utilisation particulier.

En plus de + pgbench +, il existe d’autres outils pour analyser et charger votre base de données. Un de ces outils développés par Percona est sysbench-tpcc. Https://jmeter.apache.org/[JMeter], qui permet de charger des bases de données de test ainsi que des applications Web, est un autre exemple.

Pour en savoir plus sur les bases de données gérées DigitalOcean, consultez la documentation sur les bases de données gérées https://www.digitalocean.com/docs/databases. Pour en savoir plus sur le sharding, une autre technique de mise à l’échelle utile, consultez Understanding Database Sharding.

Références

Related