Présentation
Neki est la solution de sharding de PostgreSQL proposée par PlanetScale. Chaque fragment, appelé shard, est un serveur PostgreSQL complet, ce qui garantit 100 % de compatibilité avec les outils existants. La plateforme ajoute un router, des sidecars et un plan de contrôle pour orchestrer le trafic entre des centaines de shards, permettant ainsi de dépasser les limites d’une machine unique et d’atteindre plus de 100 millions de requêtes par seconde et plusieurs pétaoctets de données par base, le tout sans interruption de service.
Architecture
Le cœur de Neki repose sur trois couches : le router, qui dirige les requêtes en fonction de la topologie et de l’état de santé des shards ; les sidecars, qui assurent la collecte de métriques et la gestion des connexions ; et le plan de contrôle, qui maintient la configuration de placement des données. Chaque shard possède son propre WAL et un chemin de réplication logique, ce qui rend les flux de CDC compatibles avec les modèles PostgreSQL classiques. Le mapping explicite des tables vers des groupes de shards rend le processus de resharding révisable et contrôlé.
Opérations et répartition dynamique
Lorsque la charge d’un shard devient critique, Neki crée de nouveaux shards cibles, les synchronise via réplication et bascule le trafic grâce à des changements de topologie transparents. Cette procédure, décrite comme « split hot shards », se déroule sans aucune période d’indisponibilité. Les changements de schéma sont exécutés comme des workflows coordonnés : le plan de contrôle applique la méthode adaptée à chaque shard et suit la progression jusqu’au cut‑over. Les transactions couvrant plusieurs shards sont atomiques ; Neki orchestre un commit distribué où chaque shard doit valider ou annuler l’opération, garantissant ainsi la cohérence globale.
Résilience et migrations
Chaque shard fonctionne comme un cluster PostgreSQL hautement disponible réparti sur plusieurs zones de disponibilité, de sorte que les pannes restent confinées à l’unité la plus petite possible. Les mises à jour de version PostgreSQL s’effectuent en créant de nouveaux groupes de shards, en répliquant les données, puis en coupant le trafic vers les anciens groupes, ce qui évite les fenêtres de maintenance. Le modèle d’importation en ligne copie les données depuis la source, les réplique, les valide, puis effectue le cut‑over, assurant une migration sans interruption. Enfin, la compatibilité CDC par shard permet aux pipelines de données existants de continuer à consommer les changements sans adaptation majeure.
