Modèles de partitionnement
S’APPLIQUE À : 
Azure Cosmos DB for PostgreSQL (avec l’extension de base de données Citus pour PostgreSQL)
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.
Azure Cosmos DB for PostgreSQL offre deux types de partitionnement de données, à savoir basé sur les lignes et basé sur un schéma. Chaque option est fournie avec ses propres compromis de partitionnement, ce qui vous permet de choisir l’approche qui s’aligne le mieux sur les exigences de votre application.
Partitionnement basé sur les lignes
La façon traditionnelle dont Azure Cosmos DB for PostgreSQL partitionne les tables est le modèle de schéma partagé à base de données unique, également appelé partitionnement basé sur les lignes, où les locataires 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 fractionner une table 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. 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
- Tous les locataires doivent partager le même schéma
Partitionnement basé sur un schéma
Disponible avec Citus 12.0 dans Azure Cosmos DB for PostgreSQL, le partitionnement basé sur un schéma est le modèle de schéma distinct à base de données partagée, où 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. Les modifications de requête ne sont pas requises et l’application a uniquement besoin d’une petite modification pour définir le search_path approprié lors du changement de locataire. Le partitionnement basé sur un schéma est une solution idéale pour les microservices et pour les éditeurs de logiciels indépendants 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 de schéma requise
- Aucune modification des requêtes d’application 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 | No |
| 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 |