Évolutivité horizontale avec le Sharding dans PostgreSQL – Où cela se passe Partie 1 de 3

J’ai récemment eu l’occasion de participer à quelques discussions intéressantes sur l’avenir du sharding dans PostgreSQL. La première conférence a été prononcée par Bruce Momjain dans PostgreSQL conf Ottawa (mai 2019) dans laquelle il a présenté l’avenir du Sharding dans PostgreSQL et a parlé de l’état actuel et de l’avenir du sharding intégré dans PostgreSQL. La deuxième conférence a été présentée par moi-même lors de la conférence PostgreSQL à Beijing (Chine – juillet 2019) dans laquelle j’ai également parlé de l’état actuel et de l’avenir du sharding intégré dans PG. J’ai essentiellement utilisé les diapositives de la présentation de Bruce (avec sa permission bien sûr) et ajouté quelques diapositives supplémentaires discutant des exigences qui justifient l’évolutivité et j’ai également parlé d’autres alternatives pour global transaction manager.

Au cours de la conférence PostgreSQL à Ottawa, j’ai poursuivi la tradition d’organiser un petit-déjeuner de réunion pendant la semaine de la conférence pour discuter du sujet du sharding. Nous le faisons chaque année depuis plusieurs années lorsque je travaillais avec EnterpriseDB et continuons la réunion maintenant que je travaille avec HighGo Software Inc. La réunion du petit-déjeuner de cette année a été suivie par des gens d’EDB, NTT, HighGO et Pivotal, le nombre de participants cette année était plus élevé que ce que nous obtenions ces dernières années, nous avons donc dû opter pour une plus grande table de petit-déjeuner. 🙂 Le but de cette réunion est d’obtenir des gens d’entreprises qui travaillent sur cette fonctionnalité dans la communauté et cette fois aussi des gens d’entreprises qui ont l’intention de contribuer à cette fonctionnalité dans la communauté. L’ordre du jour est de discuter de l’état actuel du sharding intégré, des travaux en cours, de ce qui s’en vient. Les autres sujets abordés lors de cette réunion sont de discuter de l’objectif global de la fonctionnalité de partage, des cas d’utilisation auxquels nous nous attendons à bénéficier de ces fonctionnalités, des échelles de temps approximatives pour obtenir quelque chose dans PG que nous pouvons appeler sharding.

À propos de ce blog

J’espérais initialement couvrir ce sujet dans un blog, mais comme cette fonctionnalité est si énorme, le blog s’est également avéré être beaucoup plus long que ce que je m’attendais initialement à écrire. J’ai couvert cela dans 3 blogs pour que les gens ne se fatiguent pas à le lire et perdent leur intérêt. La conclusion est donnée à la fin du 3ème blog de cette série.

Le premier blog de la série traitera de l’évolutivité, des différents types d’évolutivité et des options actuellement disponibles pour l’évolutivité dans PostgreSQL. La deuxième partie du blog se concentre sur le partitionnement déclaratif ajouté à la PAGE 10 et sur le fonctionnement du sharding dans PostgreSQL TM aujourd’hui. La troisième partie de ce blog se concentre sur l’architecture de sharding intégrée, les capacités de pushdown déjà dans PG et enfin les fonctionnalités restantes et les défis associés.

Une chose dont je n’ai pas parlé dans ce blog est d’autres solutions qui ont essayé de fournir un sharding, il y a postgres-xc, xl et pg_shards de ce monde. Je crois que certaines de ces tentatives ont été impressionnantes, mais toutes ont des limites qui les ont empêchées d’atteindre les heures de grande écoute avec la communauté PG.

Qu’est-ce que l’évolutivité et pourquoi nous en avons besoin

Avant d’entrer dans le sharding, il est important de comprendre « qu’est-ce que l’évolutivité » et le besoin d’évolutivité et quelles sont les différentes façons de rendre votre base de données évolutive. La mise à l’échelle de la base de données consiste essentiellement à augmenter le débit / les performances de la base de données en augmentant les ressources telles que les E / S, la mémoire, le processeur ou en ajoutant des ordinateurs supplémentaires au cluster. L’ajout de plus de calculs à son tour signifie également augmenter les performances de la base de données en utilisant les ressources de plusieurs systèmes pour faire le travail. Votre base de données n’a besoin d’évolutivité que si vous exécutez votre base de données PostgreSQL sur un seul serveur standard et qu’elle n’est pas en mesure de répondre aux besoins de votre charge de travail. Les symptômes qui indiquent la nécessité d’une évolutivité sont que la base de données ne fonctionne pas bien, que la taille des données devient très importante et qu’elle ne peut pas tenir dans le stockage du serveur, que la base de données reçoit trop de clients simultanés qu’elle n’est pas capable de gérer, qu’il y a des requêtes analytiques complexes qui prennent trop de temps à s’exécuter ou qui ne renvoient aucune donnée dans certains cas et qui mettent le système à l’arrêt.

Lorsque l’utilisateur commence à voir certains des problèmes mentionnés dans le paragraphe précédent, il doit réfléchir à diverses options pour résoudre ce problème avant de commencer à réfléchir à l’évolutivité.Les différentes options que l’utilisateur doit considérer avant de penser à la scalabilitésont les suivantes :

1. Optimisation du schéma – Vous devez vous assurer que le schéma est entièrement optimisé pour gérer la charge de travail et le type de requêtes envoyées au serveur de base de données. L’aspect important est de vérifier si les tables utilisateur sont suffisamment grandes pour être partitionnées afin que les requêtes puissent être acheminées vers des tables de plus petite taille. Il faut également réfléchir si les tableaux sont correctement normalisés.
2. Ajustement de la logique d’application – Un autre domaine important auquel nous devons penser lorsque nous rencontrons un problème est l’ajustement de la logique d’application. L’utilisateur peut se demander si l’application peut être modifiée pour obtenir les meilleures performances de la base de données. Cela peut impliquer de réécrire certaines requêtes de base de données ou, dans certains cas, de refactoriser au niveau de l’application pour accélérer les performances.
3. Réglage des paramètres de configuration de la base de données – Il s’agit probablement de la suggestion la plus importante des options, les paramètres de configuration de la base de données doivent être activés en fonction de la charge de travail et du type de trafic généré pour la base de données. Les valeurs des paramètres importants tels que la mémoire partagée, la mémoire de travail, le point de contrôle, etc. doivent être configurées correctement et en fonction de la table de travail. C’est une bonne source qui discute de certains des paramètres de configuration importants pour le réglage de la base de données PG.

https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Options d’évolutivité

Après avoir essayé toutes les options ci-dessus ou plus et que les problèmes persistent, il est préférable de commencer à penser aux options d’évolutivité. La base de données peut être mise à l’échelle de deux manières :

Les deux options d’évolutivité sont assez simples à comprendre, l’évolutivité verticale consiste à mettre à l’échelle vers le haut et l’évolutivité horizontale consiste à mettre à l’échelle des voies latérales. L’évolutivité verticale est obtenue en améliorant le serveur unique, en ajoutant plus de ressources au serveur pour atteindre l’évolutivité. L’évolutivité horizontale consiste à lancer plus d’ordinateurs sur le problème, en ajoutant plus de nœuds au cluster afin d’utiliser les ressources de plusieurs machines pour gagner en évolutivité de la base de données.

L’évolutivité verticale est la voie à suivre si elle répond aux exigences de l’utilisateur et qu’elle est également rentable pour l’utilisateur. La raison pour laquelle la verticale est l’option préférée est due à la facilité de configuration et à la maintenance minimale et aux frais généraux du gestionnaire. Vous pouvez simplement renforcer le serveur avec un stockage plus rapide, plus de mémoire et ajouter plus de CPU et plus rapide pour augmenter les performances de votre base de données. Il y a principalement deux raisons pour lesquelles l’évolutivité verticale n’est plus l’option pour votre charge de travail. La première raison est que l’amélioration du serveur peut être très coûteuse et, à un moment donné, elle peut devenir rentable pour l’utilisateur. La deuxième raison est que les exigences de charge de travail, c’est-à-dire le stockage, le nombre de clients simultanés et le trafic entrant, deviennent tellement importantes que le serveur unique ne peut pas évoluer pour répondre à la charge de travail. Il y a des discussions sur le fait que PostgreSQL ne peut évoluer qu’à 64 cœurs et après cela, la ligne devient linéaire. Cependant, ce sont des résultats de référence publiés qui montrent la mise à l’échelle de PostgreSQL sur plus de 64 cœurs, je crois que la mise à l’échelle basée sur le noyau est relative au nombre de clients simultanés et au trafic de base de données.

L’évolutivité horizontale consiste à ajouter plus d’un ordinateur au cluster de bases de données afin d’utiliser les ressources d’ordinateurs supplémentaires pour obtenir une évolutivité horizontale. L’évolutivité horizontale n’est pas le premier choix car elle implique la surcharge de configuration et de maintenance du cluster de machines, de sorte que l’utilisateur doit penser aux temps d’arrêt, au basculement, à la sauvegarde, etc. de toutes les machines du cluster. L’évolutivité horizontale devient le choix évident si les exigences de charge de travail ne peuvent pas être satisfaites avec un seul serveur pour les raisons indiquées dans le paragraphe précédent. Il existe des moyens d’obtenir une évolutivité horizontale même sans partage, la solution la plus populaire d’évolutivité horizontale sans partage est l’évolutivité en lecture avec Pgpool II. Pgpool II est un produit middleware qui se situe entre le client et le cluster PostgreSQL et fournit des fonctionnalités telles que la mise en commun des connexions, l’équilibrage de charge, le basculement, etc. Pgpool II fournit une évolutivité horizontale en équilibrant la charge, en envoyant les écritures au nœud principal et en équilibrant la charge des instructions de lecture sur les nœuds de veille. Pgpool II fournit un équilibrage de charge au niveau de la connexion et au niveau des instructions, avec un équilibrage de charge au niveau de la connexion Le processus Pgpool II établit une connexion avec un nœud de veille, toutes les lectures de la connexion sont envoyées au nœud de veille et les écritures sont envoyées au nœud principal. Avec la connexion au niveau des instructions (disponible dans Pgpool II 4.1), chaque instruction est équilibrée en charge sur les nœuds de veille. Il y a un bon article sur ce sujet https://highgo.ca/2019/07/19/pgpool-ii-4-1-taking-the-bull-by-its-horn/