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, vous avez besoin de tolérance aux pannes, vous avez besoin d'isoler les locataires, ou vous êtes 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 une montée en charge 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, perdre 1 nœud provoque 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, vous avez donc 2 copies des données. Cela permet une montée en charge 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 du point, 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 vous avez besoin de rééquilibrer.

Le resharding est coûteux et prend du temps, il doit ê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 de l'utilisateur, les mises à jour et les recherches doivent toujours fonctionner pendant le resharding avec un petit impact sur les performances.

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

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

Ce qu'il NE FAUT PAS faire

• Ne passez pas à l'horizontal avant d'avoir épuisé le vertical (ajoute de la complexité sans gain)
• Ne fixez pas un shard_number qui n'est pas un multiple du nombre de nœuds (distribution inégale)
• N'utilisez pas replication_factor: 1 en production si vous avez besoin de tolérance aux pannes
• N'ajoutez pas de nœuds sans rééquilibrer les shards (utilisez l'API shard move pour redistribuer)
• Ne réduisez pas la RAM sans tests de charge (l'éviction du cache cause des incidents de latence durant des jours)
• Ne dépassez pas la limite de collections en utilisant une collection par locataire (utilisez plutôt le partitionnement par payload)