Que faire quand Qdrant a besoin de plus de capacité

Vertical d'abord : opérations plus simples, pas de surcharge réseau, bon jusqu'à ~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épendants).

Configuration distribuée la plus basique

• 3 nœuds, 3 shards avec replication_factor: 2 pour un scaling sans downtime

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 downtime. Avec 2 nœuds, perdre 1 nœud cause un downtime 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 un scaling et une maintenance sans downtime. Avec replication_factor: 1, le sans-downtime n'est pas garanti même pour les opérations au niveau des points, et la maintenance du cluster nécessite un downtime.

Choisir le nombre de shards

Les shards sont l'unité de distribution des données. Plus de shards permettent plus de nœuds et une meilleure distribution, mais ajoutent de la surcharge. Moins de shards réduit la surcharge mais limite le scaling horizontal.

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 distribution et surcharge.

Changer le nombre de shards

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

Le resharding est coûteux et chronophage, 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 de performance.

Mais l'opération de resharding elle-même est chronophage 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 autohébergés.

Meilleures alternatives : sur-provisionner les shards initialement, ou créer un nouveau cluster avec la bonne config et migrer les données.

Ce qu'il NE FAUT PAS faire

• Ne pas sauter au horizontal avant d'épuiser le vertical (ajoute de la complexité sans bénéfice)
• 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 pendant des jours)
• Ne pas atteindre la limite de collection en utilisant une collection par locataire (utiliser le partitionnement par payload)