Stratégies de partitionnement

Le partitionnement par plages garde les clés voisines ensemble pour les parcours mais crée des points chauds sur les clés récentes ; le partitionnement par hachage répartit la charge mais perd l'ordre ; l'annuaire est flexible mais ajoute une recherche.

Où on le retrouve dans les vrais systèmes

  • Base clé-valeur

    Les données sont réparties entre partitions selon le hachage de la clé : le débit croît presque sans limite tant que les clés sont bien distribuées. Une clé très populaire atteint la limite de sa partition et se fait throttler. Le mode à la demande suit le trafic mais throttle les sauts brusques au-delà du double du pic précédent.

    En production : Amazon DynamoDB, Azure Cosmos DB, Google Bigtable, Riak, FoundationDB

  • Journal d'événements

    Les événements sont conservés pendant la rétention : un nouveau consommateur peut rejouer l'historique. L'ordre n'est garanti qu'au sein d'une partition, et un groupe de consommateurs utilise au plus un consommateur par partition : les partitions plafonnent ton parallélisme.

    En production : Apache Kafka (Confluent, Amazon MSK), Amazon Kinesis, Redpanda, Azure Event Hubs, Apache Pulsar

  • Index géospatial

    Les positions sont codées en geohash ou en cellules S2 pour que les points proches partagent un préfixe de clé. Garder les objets mobiles en mémoire, comme des chauffeurs qui se mettent à jour toutes les quelques secondes, évite de marteler la base principale d'écritures.

    En production : Redis GEO, PostGIS, Elasticsearch geo queries, Uber H3, Google S2

Regarde-le casser, puis répare-le

Construis une architecture, envoie-lui une journée de trafic et de pannes, et comprends pourquoi elle tient ou cède. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable