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.
Le partitionnement est une technique utilisée dans les systèmes de base de données et l’informatique distribuée pour partitionner horizontalement des données sur plusieurs serveurs ou nœuds. Il implique la séparation d’une base de données ou d’un jeu de données volumineux en parties plus petites et plus gérables appelées partitions. Une partition contient un sous-ensemble des données, et l’ensemble des partitions forme le jeu de données complet.
Les clusters élastiques sur les instances de serveur flexible Azure Database pour PostgreSQL offrent deux types de partitionnement de données : basé sur des lignes et basés sur un schéma. Chaque option est fournie avec ses propres compromis, ce qui vous permet de choisir l’approche qui s’aligne le mieux sur les exigences de votre application.
Partitionnement basé sur les lignes
partitionne les tables dans le modèle de schéma partagé de base de données unique, également appelé partitionnement basé sur les lignes ; les tenants coexistent en tant que lignes dans la même table. Le locataire est déterminé en définissant une colonne de distribution, ce qui permet de diviser un tableau horizontalement.
Le partitionnement basé sur les lignes est le plus efficace au niveau du matériel. Les locataires sont empaquetés de manière dense et distribués entre les nœuds du cluster. Cette approche nécessite toutefois de s’assurer que toutes les tables du schéma ont la colonne de distribution et que toutes les requêtes dans l’application lui appliquent le filtre de cette colonne. Le partitionnement basé sur les lignes brille dans les charges de travail IoT et permet d’obtenir la meilleure marge d’utilisation matérielle.
Avantages :
- Meilleures performances.
- Meilleure densité de locataire par nœud.
Inconvénients :
- Nécessite des modifications de schéma.
- Nécessite des modifications des requêtes de l’application.
- Nécessite que tous les tenants partagent le même schéma.
Partitionnement basé sur un schéma
Le partitionnement basé sur un schéma est la base de données partagée, un modèle de schéma distinct, et le schéma devient la partition logique dans la base de données. Les applications multilocataires peuvent utiliser un schéma par locataire pour partitionner facilement le long de la dimension du locataire. Il n’est pas nécessaire de modifier les requêtes et l’application nécessite seulement une petite modification pour définir le search_path approprié lors des changements de tenants. Le partitionnement basé sur un schéma est une solution idéale pour les microservices et pour les éditeurs de logiciels indépendants déployant des applications qui ne peuvent pas subir les modifications nécessaires pour intégrer le partitionnement basé sur les lignes.
Avantages :
- Les locataires peuvent avoir des schémas hétérogènes.
- Aucune modification du schéma n’est requise.
- Aucune modification des requêtes des applications n’est requise.
- La compatibilité SQL du partitionnement basée sur un schéma est mieux comparée au partitionnement basé sur les lignes.
Inconvénients :
- Moins de locataires par nœud par rapport au partitionnement basé sur les lignes.
Compromis de partitionnement
| Partitionnement basé sur un schéma | Partitionnement basé sur les lignes | |
|---|---|---|
| Modèle multilocataire | Schéma distinct par locataire | Tables partagées avec des colonnes d’ID de locataire |
| Version Citus | 12.0+ | Toutes les versions |
| Étapes supplémentaires par rapport à vanilla PostgreSQL | Aucune, seule une modification de configuration | Utiliser create_distributed_table sur chaque table pour distribuer et colocaliser des tables par ID de locataire |
| Le nombre de locataires | 1 à 10 000 | 1 à 1 000 000+ |
| Exigence de modélisation des données | Aucune clé étrangère entre les schémas distribués | Vous devez inclure une colonne d’ID de locataire (une colonne de distribution, également appelée clé de sharding) dans chaque table, et dans les clés primaires, les clés étrangères |
| Spécification SQL pour les requêtes à nœud unique | Utiliser un schéma distribué unique par requête | Les clauses JOIN et WHERE doivent inclure la colonne tenant_id |
| Requêtes multilocataires parallèles | Non | Oui |
| Définitions de table personnalisées par locataire | Oui | Non |
| Contrôle d’accès | Autorisations sur un schéma | Autorisations sur un schéma |
| Partage de données entre locataires | Oui, à l’aide de tables de référence (dans un schéma distinct) | Oui, à l’aide de tables de référence |
| Isolement du locataire à la partition | Chaque locataire a son propre groupe de partitions par définition | Possibilité de donner à des ID de locataire spécifiques leur propre groupe de partitions via isolate_tenant_to_new_shard |