Découper pour grandir : le partage de bases en clair

Deux amis lancent Chirp, une petite appli sociale. Quelques centaines de curieux le premier jour; un seul serveur applicatif et une seule base suffisent. On touche envoyer et le message part; on ouvre un profil en un clic. Une épicerie de quartier avec une seule caisse. Personne ne parle de taille, tout le monde cherche des inscrits. J'aime ce tableau car il montre le mal de la taille en montrant d'abord son absence.

Puis les inscrits grimpent, de centaines en milliers. Séparons deux métiers: lire (ouvrir un profil, lister des messages) et écrire (publier, suivre quelqu'un). Quand les deux s'écrasent sur un seul serveur, la file s'allonge. Premier réflexe: acheter un serveur plus gros, avec un processeur plus fort et une mémoire plus large. Cette route finit sur un mur. Un jour plus de gros serveur, ou une facture qui pique. Le partage naît exactement contre ce mur.

Partager, c'est découper les tables et poser chaque morceau sur son serveur. La table des utilisateurs se coupe en quatre; devant, une couche d'orientation sait quelle question va où. Une épicerie remplacée par quatre succursales plus un accueil qui envoie chacun vers la bonne. Simple à dire, fin à réussir.

Premier point fin: la clé de partage, la colonne qui disperse les lignes. Chirp choisit l'identifiant. En changer plus tard, qu'est-ce que cela donne? Imaginons un partage par pays. Chaque ligne sur chaque morceau se relit une par une, chacun se voit chercher son pays puis déménage vers le bon morceau. Un déménagement géant. D'où un choix soigné dès le départ. La documentation MongoDB donne le même avertissement: richesse des valeurs, fréquence, croissance continue.

Une bonne clé a ses habitudes. Un: beaucoup de valeurs distinctes. Partager par pays donne deux cents valeurs pour soixante-quatre morceaux; les morceaux des pays peuplés suent pendant que les calmes dorment. Les identifiants offrent des millions de valeurs pour autant de morceaux voulus. Deux: les nouveaux arrivent partout. Partager par année d'inscription gonfle le morceau de l'année pendant que les vieux se vident. Des identifiants en série tournent zéro, un, deux, trois et s'équilibrent seuls.

Première méthode: le hachage. On passe l'identifiant dans une fonction de hachage, on divise par le nombre de morceaux, on garde le reste. Leo tombe sur le morceau zéro. Beauté: identifiant plus nombre suffisent, chaque serveur calcule seul sans bavarder. Comme un tirage au sort pour des paniers de linge, où chacun connaît la règle par coeur. Les équipes peu portées sur les questions d'intervalle adorent cette voie.

Deuxième méthode: les intervalles. Chaque morceau possède une plage de valeurs. Une appli bancaire garde mars ensemble sur un morceau, avril sur le suivant. Les questions d'intervalle filent vite avec peu de morceaux visités. Prix: les lignes fraîches portent toutes la date du jour, donc chaque écriture pleut sur le morceau le plus jeune. Le guide MongoDB pose l'arbitrage simplement: les intervalles servent les questions d'intervalle, le hachage disperse les écritures.

Troisième méthode: le répertoire. Une table de correspondance note quel client vit sur quel morceau. Une ligne change et un gros client obtient son morceau privé; les petits partagent. Souplesse maximale. Prix: chaque demande consulte d'abord la table. Table lente, tout lent; table morte, tout perdu. Comme le carnet du gardien: pratique jusqu'au jour où il disparaît. Les équipes aux clients inégaux prennent cette voie.

Quatrième méthode: la géographie. Les lignes reposent près de leurs maîtres, les Européens sur des serveurs d'Europe. Deux motifs. Un: la vitesse, car la réponse saute l'océan. Deux: les règles, car certains dossiers doivent rester au pays. Comme acheter près de chez soi au lieu de rouler à l'autre bout de la ville. Prix: une région enfiévrée peut rôtir son morceau. Les équipes aux questions régionales et au délai sensible prennent cette voie.

Puis le point délicat: les clés brûlantes. Le message de Lena explose; des millions de j'aime cognent un seul morceau jusqu'à l'étouffer. Remède: le salage. Des numéros un à dix rejoignent l'identifiant 500, les mentions se dispersent sur dix clés. Un seul caractère changé donne une empreinte toute différente, donc les dix clés tombent sur des morceaux variés. Profils et messages restent en place; seule la charge des mentions s'éparpille. Prix: le total demande dix lectures plus une somme. Règle nette: le modeste Chris reste sans sel, seules les clés qui brûlent se salent. Le texte CosmicLearn chiffre la douleur, une seule partition cale passé mille écritures par seconde, et le billet Amazon montre des partitions chauffées qui se divisent seules.

Comment la couche d'orientation décide-t-elle? Chaque lecture visite d'abord le cache; un succès ne touche jamais les morceaux. Sur un manque, ou quand la demande écrit, la balle est dans le camp de la couche. La couche pose deux questions: clé salée ou non, quel morceau sert. Mention salée? On tire une des dix clés au hasard et on écrit là. Total demandé? On lit dix morceaux et on additionne. Standardiste et réception: le bureau répond ce qu'il sait, le reste part vers la bonne salle.

Ajouter des morceaux fait mal avec les restes simples. Passer de quatre à cinq change presque tous les restes, presque tout le monde déménage. Chris et Leo partent vers des maisons neuves. La route prise pour grandir se remplit de camions. Soulagement: l'ordre en cercle du hachage stable. Toutes les empreintes forment un cercle, les morceaux s'y posent, et la règle marche dans le sens horaire depuis chaque identifiant jusqu'au premier morceau. Un nouveau ne prend que la charge du voisin; Chris et Leo restent chez eux. Le coût passe de tout le monde à un seul morceau. L'idée remonte à un article Karger de 1997, du temps d'Akamai.

Les cercles tremblent aussi: des places tirées au hasard donnent de larges arcs à certains, d'étroits à d'autres, et les pannes versent des arcs entiers sur un voisin. Remède: des places virtuelles, poser chaque morceau dix fois sur le cercle. Chacun possède des petits arcs éparpillés dont les totaux se rejoignent, et les pannes s'éventent sur tous les survivants. Note de terrain: Cassandra a vécu des années à 256 places, puis réduit à 16 pour alléger l'entretien. Peu de places, équilibre maigre; trop de places, entretien lourd; le point doux se cherche. Les outils adoucissent le reste: la documentation Vitess décrit un redécoupage en ligne, nouveaux morceaux bâtis, lignes copiées pendant que les écritures coulent, lectures déplacées puis écritures, tandis que la documentation CitusData, venue du monde Postgres, offre un rééquilibrage vivant semblable. Leçon gardée: le partage est un ménage, pas une chirurgie. Quand un serveur ne tient plus les lignes, quand le nombre de serveurs bougera, et quand le coût des déménagements s'accepte, le cercle mérite sa place; sinon gros serveur, bons index et cache achètent une paix moins chère.