Quand NE PAS partitionner horizontalement

Le partitionnement horizontal multiplie la complexité opérationnelle. La plupart des applications n'en ont jamais besoin. Commencez par épuiser les solutions plus simples.

Utilisez une machine plus puissante. Les instances modernes du cloud peuvent facilement gérer :

• 128 cœurs
• 1 TB de RAM
• 50 000 IOPS sur NVMe

Cela représente de 100 000 à 500 000 QPS sur un seul nœud PostgreSQL. La plupart des applications tiennent aisément sur une telle machine.

Si les lectures dominent, ajoutez des réplicas. Un primary et 3 réplicas peuvent traiter 10 fois plus de lectures.

Placez Redis ou memcached devant les requêtes très consultées. C'est souvent le gain le moins coûteux.

Le partitionnement déclaratif natif de PG résout le problème de la « table trop volumineuse » sur un seul serveur. Il est souvent 100 fois plus simple que le partitionnement horizontal.

Déplacez les différents domaines vers des bases de données distinctes — base de données des commandes, base de données des utilisateurs, base de données analytique. Chacune peut être mise à l'échelle indépendamment.

Requêtes OLTP → PostgreSQL. Requêtes analytiques → ClickHouse / BigQuery / Snowflake. De nombreux projets où l'on pense « nous devons effectuer un partitionnement horizontal » sont en réalité des projets où « l'analytique sature notre OLTP ».

Si vous manquez toujours de capacité avec 50 TB de données uniquement OLTP et que la charge exige plus d'écritures qu'un seul serveur ne peut en gérer, commencez à planifier le partitionnement.

• Davantage de serveurs à surveiller et à mettre à jour
• Les sauvegardes entre partitions doivent être coordonnées
• Les requêtes inter-partitions sollicitent le code de l'application
• Le repartitionnement est difficile
• Les partitions surchargées exigent un rééquilibrage actif

Construisez votre système avec des schémas compatibles avec le partitionnement (incluez toujours tenant_id, n'utilisez jamais de compteurs à incrémentation globale) afin que vous CAN effectuer le partitionnement plus tard. Mais ne partitionnez pas avant d'y être contraint.

Même si vous restez sur un seul nœud, concevez votre système comme si vous pouviez le partitionner :

• tenant_id sur chaque ligne
• UUID ou identifiants distribués (pas d'auto-incrémentation)
• Aucune séquence globalement unique
• Clés étrangères dans le périmètre d'un locataire

Le partitionnement horizontal augmente la capacité au prix d'une réduction des possibilités. Les JOIN, les transactions et les requêtes deviennent plus difficiles. Assurez-vous que le gain en vaut la peine.

Le partitionnement horizontal résout un problème réel, mais c'est une solution lourde.

• Commencez par la mise à l'échelle verticale
• Ajoutez des réplicas de lecture et une mise en cache
• Effectuez un partitionnement avant le partitionnement horizontal
• Déportez l'analytique d'OLTP
• Concevez votre système pour permettre le partitionnement, mais reportez sa mise en œuvre