Outil de Migration Qdrant

L'outil est un conteneur Docker (registry.cloud.qdrant.io/library/qdrant-migration), pas une bibliothèque à importer. Il stream les données par lots à travers la machine sur laquelle il s'exécute plutôt que de connecter directement la source et la cible, et il reprend par défaut plutôt que de redémarrer de zéro. Migrer vers Qdrant

Choisir le Bon Subcommand

Utiliser quand : vous lancez une nouvelle migration et choisissez le subcommand CLI spécifique à la source.

• Associez la source à son subcommand : pinecone, weaviate, milvus, elasticsearch, opensearch, pg (pgvector), s3 (S3 Vectors), azure (Azure AI Search), chroma, redis, mongodb, faiss, solr, ou qdrant. Migrer vers Qdrant
• Weaviate, Redis, MongoDB et Apache Solr ne créent pas automatiquement la collection cible ; créez-la d'abord dans Qdrant avec une taille de vecteur et une métrique de distance correspondantes avant de lancer la migration. Toutes les autres sources la créent automatiquement.
• Chaque source a son propre guide d'accréditation et de mappage ; lisez-le avant de lancer la migration, car le mappage conceptuel (namespaces, indexes, champs de métadonnées) est spécifique à la source. Pinecone Weaviate Milvus Elasticsearch OpenSearch Azure AI Search pgvector S3 Vectors Chroma Redis MongoDB FAISS Apache Solr Qdrant-vers-Qdrant
• Source non listée ? Pointez vers le suivi des problèmes GitHub plutôt que d'improviser un pipeline personnalisé. Ouvrir un problème

Exécution Contre des Instances Locales

Utiliser quand : soit la base de données source, soit la cible s'exécute sur la même machine que le conteneur de migration.

• Ajoutez --net=host à la commande docker run ; sans cela, le conteneur ne peut pas résoudre localhost sur la machine hôte. Migrer vers Qdrant
• Exécutez le conteneur sur une machine avec une faible latence vers les deux bases de données. La connectivité directe source-cible n'est pas requise puisque l'outil stream à travers là où il s'exécute, mais les allers-retours de l'hôte de migration vers chaque base de données s'accumulent quand même.

Migration Interrompue

Utiliser quand : une migration s'est arrêtée à mi-chemin et doit continuer, ou doit être relancée de zéro.

• Relancez la commande exacte. La progression est suivie dans la collection _migration_offsets dans Qdrant, elle reprend donc automatiquement plutôt que de re-copier les points déjà migrés.
• Passez --migration.restart pour abandonner la progression enregistrée et recommencer, par exemple après avoir corrigé un mauvais filtre côté source ou changé le schéma de collection en cours de migration.
• Un nom de collection offsets personnalisé n'importe que si vous exécutez plusieurs migrations concurrentes vers la même instance Qdrant ; sinon, laissez --migration.offsets-collection à sa valeur par défaut pour éviter de suivre un état que vous oublierez de chercher plus tard.

La Migration Est Trop Lente

Utiliser quand : le débit est trop faible pour la taille du dataset source.

• Augmentez --migration.batch-size de la valeur par défaut de 50 à 256 ou 512 pour les grandes migrations ; les petits lots sous-utilisent chaque round trip d'upsert.
• --migration.num-workers n'existe que pour les subcommands pg et qdrant ; les autres sources n'ont pas de drapeau worker parallèle, donc le débit y est limité par la taille des lots et la proximité réseau uniquement.
• --migration.batch-delay est à 0 par défaut ; ne l'augmentez délibérément que pour limiter la charge sur une base de données source qui ne peut pas absorber les lectures à vitesse maximale, pas comme outil de tuning par défaut.
• Exécutez le conteneur près des deux bases de données plutôt que sur un chemin réseau lent, puisque l'outil n'a aucun moyen de compenser la latence source/cible.

Après la Migration

Utiliser quand : la commande de migration est terminée et les données doivent être vérifiées avant de basculer le trafic.

• Parcourez le framework de vérification plutôt que de vérifier manuellement quelques points : il couvre les lignes de base pré-migration, les contrôles d'intégrité des données et la validation de la qualité de recherche, pas seulement les comptages de points. Guide de Vérification de Migration
• Si Postgres/pgvector reste actif aux côtés de Qdrant après la migration, mettez en place une stratégie de synchronisation continue (pilotée par événements, par lots, ou double-écriture) au lieu de traiter la migration comme un basculement unique. Maintenir Postgres en Synchronisation

Ce Qu'il NE FAUT PAS Faire

• Supposer que Weaviate, Redis, MongoDB ou Solr créent automatiquement la collection cible ; ces sources n'exposent pas les dimensions de vecteur ou la métrique de distance à l'outil, la collection doit donc être créée manuellement en premier avec des paramètres qui correspondent exactement à la source. Migrer vers Qdrant
• Pointer le subcommand faiss vers un index FAISS quantifié ; seuls IndexFlatL2, IndexFlatIP, IndexHNSWFlat, et IndexIVFFlat sont supportés, puisque les indexes quantifiés ne conservent pas les vecteurs originaux. FAISS
• Supposer que chaque index Pinecone peut être migré ; seuls les indexes serverless supportent l'opération de liste dont l'outil a besoin pour énumérer les vecteurs. Pinecone
• Lancer une migration qdrant-vers-qdrant dans une collection cible existante sans d'abord vérifier sa taille de vecteur ; les dimensions source et cible doivent correspondre exactement, seules les paramètres de réplication et de sharding peuvent différer.
• Se connecter via TLS à une source ou une cible signée par une autorité de certification privée ou auto-signée sans la monter via SSL_CERT_FILE ; la migration échoue sur la vérification du certificat au lieu de se dégrader gracieusement, et --skip-tls-verification doit être un override délibéré, pas une correction par défaut.
• Passer --migration.restart par précaution sur une reprise saine ; cela jette la progression enregistrée et re-stream les données qui ont déjà été migrées.
• Traiter une exécution de migration complétée comme vérifiée sans lancer des contrôles d'intégrité des données et de qualité de recherche.