Cette méthode utilise une formule mathématique (une fonction de hachage) sur la clé de segmentation pour attribuer les données. Par exemple, le système peut calculer l'ID utilisateur (mod 4) pour attribuer un utilisateur à l'un des quatre serveurs.

Bien que les fonctions de hachage contribuent à répartir les données de manière cohérente, elles ne garantissent une distribution uniforme que si la clé de segmentation présente une cardinalité élevée et un faible biais de fréquence. Si vous choisissez une clé de segmentation avec une valeur courante, comme un nom de famille ("Smith" apparaît 1 000 fois plus souvent que "Pyne"), la fonction de hachage enverra chaque enregistrement "Smith" au même segment. Cela crée un "segment chaud" malgré l'utilisation d'une formule mathématique.

L'ajout de nouveaux serveurs est également complexe avec cette méthode, car la formule change, ce qui vous oblige souvent à "resegmenter" ou à déplacer vos données sur le nouveau cluster de serveurs.

Les données sont attribuées en fonction de plages de valeurs. Par exemple, vous pouvez placer les ID utilisateur 1 à 1 000 sur le serveur A et les ID utilisateur 1 001 à 2 000 sur le serveur B. Cette méthode est très intuitive et idéale pour les requêtes qui doivent lire une séquence de données (requêtes de plage). L'inconvénient est que cela crée des "points chauds" : si tous vos nouveaux utilisateurs sont affectés au serveur B, ce serveur effectuera tout le travail tandis que le serveur A restera inactif.

Cette stratégie utilise un tableau de conversion (un répertoire) qui indique exactement quel segment contient quelles données. Elle offre une flexibilité maximale, car vous pouvez déplacer des données entre les segments sans modifier de formule. Cependant, ce tableau de conversion devient un goulot d'étranglement : chaque requête doit d'abord consulter le répertoire, ce qui ajoute de la latence. En cas de défaillance du répertoire, toute la base de données devient inaccessible.

La segmentation géographique attribue les données à des serveurs spécifiques en fonction de la position géographique de l'utilisateur. Par exemple, les données des utilisateurs en France sont stockées sur des serveurs situés dans l'UE, tandis que celles des utilisateurs aux États-Unis sont stockées sur des serveurs situés en Amérique du Nord. Cela réduit considérablement la latence (vitesse) pour les utilisateurs et aide les entreprises à respecter les lois sur la résidence des données, comme le RGPD.

Parfois appelé "partitionnement fonctionnel", il consiste à répartir les données par caractéristique plutôt que par ligne. Par exemple, vous pouvez placer toutes les tables "Profil utilisateur" sur le serveur A et toutes les tables "Importation de photos" sur le serveur B. Bien que cette approche organise les données de manière logique, elle est fonctionnellement semblable à une architecture de données de microservices et ne résout pas le problème si une fonctionnalité spécifique (comme Photos) devient trop volumineuse pour un seul serveur.

La segmentation est un type spécifique de partitionnement horizontal dans lequel les éléments de données sont répartis sur des serveurs complètement différents. Elle permet de résoudre les problèmes de limites de capacité matérielle (stockage) et les goulots d'étranglement liés au débit d'écriture, car différents serveurs peuvent traiter les écritures simultanément.

• Segmentation manuelle : dans un environnement de segmentation manuelle, le développeur ou l'administrateur de base de données est chargé de définir les clés de segmentation, de créer l'infrastructure pour chaque segment et d'écrire la logique d'acheminement des requêtes. Vous pouvez ainsi contrôler précisément l'emplacement des données. Toutefois, cela nécessite une maintenance importante. Si un segment devient trop volumineux, vous devez "resegmenter" manuellement les données, ce qui implique de déplacer des millions de lignes vers de nouveaux serveurs tout en essayant de minimiser les temps d'arrêt de l'application.
• Segmentation automatique : la segmentation automatique, souvent présente dans les bases de données NoSQL comme Bigtable ou les bases de données SQL distribuées comme Spanner, gère la distribution des données et du trafic de manière automatique. Le système surveille la taille des données et la charge sur chaque serveur. Si un segment spécifique devient un "point chaud" ou devient trop volumineux, le moteur de base de données le divise automatiquement et déplace les données vers un serveur moins encombré. Cela réduit la charge opérationnelle de votre équipe et contribue à assurer des performances constantes à mesure que votre application évolue.

Le partitionnement consiste à diviser une grande table en parties plus petites et plus faciles à gérer (par exemple, en divisant une table de journaux par mois), tout en les conservant sur la même instance de serveur. Il permet de résoudre les problèmes de stockage en facilitant l'archivage ou la suppression des anciennes données sans affecter le reste de la table. Cependant, il ne résout pas les problèmes de serveur. Comme l'ensemble des partitions résident toujours sur une seule machine, elles continuent de partager le même processeur et la même RAM. Le partitionnement n'est donc pas utile si le serveur atteint ses limites de performances.

La réplication consiste à copier l'intégralité de la base de données sur plusieurs serveurs. Cette option est intéressante pour la disponibilité en lecture, car si un serveur tombe en panne, un autre peut prendre le relais. Cependant, elle ne contribue pas au scaling pour l'écriture, car toutes les données écrites doivent être copiées sur chaque instance répliquée, ce qui limite la vitesse d'écriture à la capacité d'une seule machine.

Autre point important, la plupart des modèles de réplication n'autorisent qu'un seul nœud d'écriture (le nœud principal) à la fois. Si vous autorisez plusieurs serveurs à accepter des écritures simultanément, vous risquez de rencontrer des conflits d'écriture, où deux serveurs tentent de mettre à jour le même enregistrement avec des informations différentes. La résolution de ces conflits est techniquement difficile et peut entraîner une perte ou une incohérence des données si elle n'est pas gérée par un système distribué sophistiqué.

Une base de données distribuée, comme Spanner, offre les avantages de la segmentation sans la complexité opérationnelle manuelle. Ces systèmes sont conçus pour fonctionner sur un cluster de machines dès le départ. Ils gèrent automatiquement la distribution, le rééquilibrage et la réplication des données de manière transparente. Certains de ces systèmes disposent de plusieurs nœuds d'écriture et gèrent automatiquement les conflits d'écriture. Vous pouvez ainsi effectuer un scaling horizontal tout en conservant la cohérence d'une base de données relationnelle traditionnelle.