Décision : sharding ou réplication (montée en charge) ?
La décision de montée en charge d'une base dépend de la nature du goulot (lectures ou écritures) et du fait que les données tiennent ou non sur un seul nœud. Une mauvaise stratégie signifie une complexité inutile ou un goulot non résolu. Cet arbre vous rappelle d'abord les options les moins chères et les plus simples (montée en charge verticale, cache), puis vous aide à choisir correctement entre réplicas de lecture et sharding.
Avez-vous d'abord essayé la voie la plus simple : montée en charge verticale et optimisation des requêtes ?
Avant de passer à une architecture distribuée, prenez le gain le moins coûteux : renforcer le matériel (CPU/RAM/IOPS), ajouter les index manquants et corriger les requêtes coûteuses résout la plupart des goulots. N'ajoutez de la complexité que lorsque ces leviers sont épuisés.
- Non / je n'ai pas encore atteint la limite
- Oui, la montée en charge verticale et l'optimisation ne suffisent pas
Le goulot concerne-t-il les lectures, ou les écritures/le volume de données ?
Isolez la source du problème de montée en charge : de nombreuses requêtes de lecture saturent-elles un seul nœud (charge en lecture), ou le débit d'écriture ou la taille totale des données dépasse-t-il la capacité d'un seul nœud (charge en écriture/volume) ? Cette distinction est la différence fondamentale entre réplicas et sharding.
- Le trafic de lecture domine, les écritures tiennent sur un seul nœud
- Le débit d'écriture ou le volume de données dépasse un seul nœud
Les lectures sont-elles répétitives/cachables, ou fraîches et variées ?
Affinez encore le goulot de lecture : les mêmes résultats sont-ils lus encore et encore (un cache est très efficace), ou les lectures demandent-elles des données variées, larges et actuelles (une capacité de lecture supplémentaire est nécessaire) ? Cela tranche entre une couche de cache et des réplicas de lecture.
- Les mêmes données sont lues de façon répétée, un léger décalage est acceptable
- Lectures variées/fraîches, une capacité de lecture brute est nécessaire
Recommandation : d'abord montée en charge verticale + optimisation des requêtes
La première voie, et la moins coûteuse, avant de passer à une architecture distribuée. Renforcer le matériel et corriger les requêtes/index résout la plupart des problèmes de montée en charge sans ajouter de complexité opérationnelle.
Recommandation : réplicas de lecture (montée en charge des lectures)
Les écritures restent sur un seul nœud (le primaire) tandis que le trafic de lecture est réparti sur un ou plusieurs réplicas. C'est la méthode standard pour accroître la capacité de lecture brute et la résilience des charges à forte lecture.
Recommandation : couche de cache
Conserver les résultats fréquemment relus dans une couche rapide en mémoire réduit considérablement la charge de la base. Avec le bon schéma, elle répond sans interroger la base, réduisant à la fois latence et charge.
Recommandation : sharding (montée en charge des écritures/données)
Les données sont découpées selon une clé de shard et réparties sur plusieurs nœuds indépendants ; chaque nœud détient une partie des données et leurs écritures. C'est la méthode pour faire monter en charge le débit d'écriture et le volume total de données, mais elle ajoute une complexité importante.