Les copies maintiennent une base de données en vie — mais chaque copie contient toujours TOUTES les données. Que se passe-t-il donc lorsque les données elles-mêmes ne tiennent pas sur une seule machine ? Vous les divisez. Voici comment.
Dans l'épisode 9 de The Tech Intern · Conception de Système, nous reprenons exactement là où l'épisode 8 s'est arrêté. Même base de données de commande Dabba — mais maintenant elle a dépassé une seule boîte, et aucun nombre de copies ne peut résoudre cela. Nous passons l'épisode à la faire GRANDIR (sharding) et à rester RAPIDE (indexation), un compromis délibéré à la fois.
Vous repartirez en sachant (chaque terme expliqué à sa première utilisation, aucun jargon laissé en suspens) :
✦ Partitionnement — horizontal (par lignes) vs vertical (par colonnes), avec une image de répertoire à deux comptoirs
✦ Sharding vs partitionnement — la différence sur laquelle les gens trébuchent : le sharding est un partitionnement horizontal sur des machines SÉPARÉES ("le partitionnement divise les données ; le sharding les divise entre les machines")
✦ Stratégies de sharding — plage vs hachage (la fourche qui décide de tout), plus répertoire, géo, composite & fonctionnel
✦ Le problème du hot-shard / célébrité — pourquoi une ligne virale fait fondre un seul shard, et comment le refroidir (coalescer, shard dédié, sel, cache)
✦ Sharding réel dans la nature — l'ID 64 bits d'Instagram (8 192 shards), Notion (480 shards, re-shardé sans temps d'arrêt), Discord (177→72 nœuds)
✦ Rééquilibrage — pourquoi le naïf `hash(key) mod N` redistribue ~67% de vos clés pour ajouter une machine
✦ Hachage cohérent — l'anneau qui déplace seulement ~1/N des clés, et nœuds virtuels (Cassandra : 256/nœud)
✦ Indexation — comment un arbre B transforme un scan de 23 SECONDES en 2 MILLISECONDES sur 500M de lignes (~10 000× plus rapide), le compromis lecture-vs-écriture, et index local vs global sur une base de données sharded
Un exemple en cours (l'application alimentaire Dabba), des chiffres réels (tous sourcés), zéro gesticulation.
⏭ Prochain épisode : mise en cache — parce que la requête la plus rapide est celle que vous n'envoyez jamais.
━━━━━━━━━━━━━━━━━━━━
⏱ CHAPITRES
0:00 Pourquoi les copies ne suffisent pas (récapitulatif)
0:59 Partitionnement — lignes vs colonnes
1:53 Sharding vs partitionnement : la vraie différence
3:08 Stratégie de sharding : plage vs hachage
4:50 Répertoire, géo, composite & fonctionnel
6:26 Le problème du hot-shard
7:41 Sharding dans la nature (Instagram, Notion, Discord)
8:56 Rééquilibrage — le piège mod-N
10:00 Hachage cohérent — l'anneau
11:19 Indexation — une ligne dans un milliard
12:43 Les index ne sont pas gratuits (types & compromis)
14:31 Récapitulatif + ce qui vient ensuite
━━━━━━━━━━━━━━━━━━━━
🔔 Abonnez-vous pour le reste de la série Conception de Système — nous construisons une application depuis "qu'est-ce qu'un serveur" jusqu'à la conception de WhatsApp, UPI et Hotstar depuis zéro.
#conceptiondesystème #basesdedonnées #sharding #indexation #backend #ingénieriesoftware