qdrant-horizontal-scaling

Diagnostique et guide les décisions de mise à l'échelle horizontale de Qdrant. À utiliser lorsque quelqu'un demande « vertical ou horizontal ? », « combien de nœuds ? », « combien de shards ? », « comment ajouter des nœuds », « resharding », « les données ne rentrent pas » ou « besoin de plus de capacité ». À utiliser également lorsque la croissance des données dépasse le déploiement actuel.

npx skills add https://github.com/qdrant/skills --skill qdrant-horizontal-scaling

Que faire quand Qdrant a besoin de plus de capacité

Vertical d'abord : opérations plus simples, pas de surcharge réseau, correct jusqu'à environ 100M vecteurs par nœud selon les dimensions et la quantification. Horizontal quand : les données dépassent la capacité d'un seul nœud, besoin de tolérance aux pannes, besoin d'isoler les locataires, ou limité par les IOPS (plus de nœuds = plus d'IOPS indépendantes).

Configuration distribuée la plus basique

  • 3 nœuds, 3 shards avec replication_factor: 2 pour une mise à l'échelle sans temps d'arrêt

Le minimum de 3 nœuds est important pour le consensus et la tolérance aux pannes. Avec 3 nœuds, vous pouvez perdre 1 nœud sans temps d'arrêt. Avec 2 nœuds, la perte d'1 nœud cause un temps d'arrêt pour les opérations de collection. Un facteur de réplication de 2 signifie que chaque shard a 1 réplica, donc vous avez 2 copies des données. Cela permet une mise à l'échelle et une maintenance sans temps d'arrêt. Avec replication_factor: 1, l'absence de temps d'arrêt n'est pas garantie même pour les opérations au niveau des points, et la maintenance du cluster nécessite un temps d'arrêt.

Choisir le nombre de shards

Les shards sont l'unité de distribution des données. Plus de shards permet plus de nœuds et une meilleure distribution, mais ajoute de la surcharge. Moins de shards réduit la surcharge mais limite la mise à l'échelle horizontale.

Pour un cluster de 3-6 nœuds, le nombre de shards recommandé est 6-12. Cela permet 2-4 shards par nœud, ce qui équilibre la distribution et la surcharge.

Changer le nombre de shards

À utiliser quand : le nombre de shards n'est pas divisible de manière égale par le nombre de nœuds, causant une distribution inégale, ou besoin de rééquilibrage.

Le resharding est coûteux et long, il devrait être utilisé en dernier recours si la distribution régulière des données n'est pas possible. Le resharding est conçu pour être transparent pour les opérations utilisateur, les mises à jour et recherches devraient toujours fonctionner pendant le resharding avec un petit impact sur les performances.

Mais l'opération de resharding elle-même est longue et nécessite de déplacer de grandes quantités de données entre les nœuds.

  • Disponible dans Qdrant Cloud Resharding
  • Le resharding n'est pas disponible pour les déploiements auto-hébergés.

Meilleures alternatives : sur-provisionner les shards initialement, ou lancer un nouveau cluster avec la configuration correcte et migrer les données.

Ce qu'il NE FAUT PAS faire

  • Ne pas passer au horizontal avant d'épuiser le vertical (ajoute de la complexité sans gain)
  • Ne pas définir shard_number qui n'est pas un multiple du nombre de nœuds (distribution inégale)
  • Ne pas utiliser replication_factor: 1 en production si vous avez besoin de tolérance aux pannes
  • Ne pas ajouter de nœuds sans rééquilibrer les shards (utiliser l'API de déplacement de shard pour redistribuer)
  • Ne pas réduire la RAM sans test de charge (l'éviction du cache cause des incidents de latence durant des jours)
  • Ne pas atteindre la limite de collections en utilisant une collection par locataire (utiliser le partitionnement par payload)