Accueil
Blog
Milvus Collection externe : indexer et récupérer des données résidant dans le lac sans les déplacer

Milvus Collection externe : indexer et récupérer des données résidant dans le lac sans les déplacer

Engineering

August 24, 2026

Leo Liu

Dans de nombreux pipelines d'IA, les embeddings et les métadonnées sont déjà produits et stockés dans un lac de données. Un pipeline produit peut écrire les attributs produits et les embeddings multimodaux dans des fichiers Parquet sur S3. Un corpus de récupération ou d'entraînement peut résider dans une table Iceberg ou Lance. C'est déjà dans le lac que ces ensembles de données sont générés, mis à jour, versionnés et utilisés par le reste de la pile de données.

Les bases de données vectorielles, cependant, ont traditionnellement été construites autour d'une copie de service détenue par la base de données. Si les équipes souhaitaient une recherche vectorielle à faible latence sur des données déjà présentes dans un lac, elles avaient généralement deux options :

Copier les données dans une base de données vectorielle. Cela fournit des index ANN et un chemin de service de production, mais crée une seconde copie de l'ensemble de données et un pipeline ETL qui doit rester synchronisé avec la source.
Interroger le lac directement. Cela évite la duplication, mais sans couche d'indexation et de service ANN, la recherche vectorielle retombe sur des balayages qui ne sont pas conçus pour la latence de production.

Milvus 3.0 External Collection introduit une troisième voie. Les données sources restent dans Parquet, Iceberg, Lance, Vortex ou un autre format externe pris en charge, tandis que Milvus construit et sert des index sur celles-ci. Vous mappez les champs externes dans un schéma Milvus, définissez les index dont vous avez besoin, actualisez la collection et utilisez les API de recherche et d'interrogation normales de Milvus—sans avoir à copier au préalable les lignes sources dans une collection gérée par Milvus.

Le changement architectural est simple : les données peuvent rester dans le lac, tandis que Milvus ajoute la couche d'indexation et de récupération.

Cela fait également d'External Collection une étape importante vers le Vector Lakebase, une architecture de données unifiée et native du lac pour l'IA qui combine un service de niveau base de données vectorielle avec un stockage ouvert dans le lac, des index réutilisables au niveau du lac et une couche sémantique partagée. La récupération en ligne n'a plus à partir d'une copie de service séparée pendant que Spark, les pipelines d'entraînement, les tâches d'évaluation et les outils de gouvernance travaillent sur une autre version des données. Ils peuvent travailler sur la même fondation de données résidant dans le lac.

Ce qu'est une External Collection et ce qu'elle change

Une External Collection est un type de collection Milvus dont les données sources résident en dehors du stockage géré par Milvus.

Sans External Collection, placer ce catalogue derrière une recherche vectorielle de production signifie généralement créer une autre copie dans Milvus :

Chaque fois que le catalogue change, que le modèle d'embedding change ou qu'un champ est rétro-rempli, un autre pipeline doit déplacer les données mises à jour à travers cette frontière.

Avec External Collection, l'architecture devient :

Milvus ne fait pas des fichiers externes sa propre copie des données sources. Au lieu de cela, l'External Collection contient les informations dont Milvus a besoin pour les interpréter et les rechercher :

Un external_source qui identifie les fichiers ou la table externes.
Un external_spec qui décrit le format source et l'accès au stockage.
Des mappages external_field qui connectent les champs du schéma Milvus aux colonnes de l'ensemble de données externe.
Les index, manifestes et l'état de service que Milvus crée pour la récupération.

Des données sources en zéro copie ne signifient pas un état nul dans Milvus. Milvus construit toujours des index. Il utilise toujours du calcul. Il met toujours des données en cache. Le changement est que les lignes faisant autorité n'ont plus besoin d'être copiées dans Milvus simplement parce que vous avez besoin que Milvus les recherche.

Collection Milvus normale vs External Collection

Aspect	Collection gérée par Milvus	External Collection
Enregistrements sources	Stockés et gérés par Milvus	Restent dans les fichiers ou la table externes
Comment les données entrent dans Milvus	Insertion, upsert, importation ou écriture en continu	Mappage de source externe + Refresh
Mutations en ligne	Prises en charge	Lecture seule depuis Milvus
Fraîcheur	Suit le chemin d'écriture et le modèle de cohérence de Milvus	Suit le dernier Refresh publié avec succès
État géré par Milvus	Données sources, métadonnées, index, caches	Mappages, manifestes, index, caches
Chemin d'interrogation	API de recherche et d'interrogation de Milvus	API de recherche et d'interrogation de Milvus
Meilleure adaptation	Données en ligne en évolution continue	Grandes données de lac produites par lots et à forte lecture

L'External Collection complète donc les collections Milvus normales plutôt que de les remplacer.

Un système peut conserver un état en ligne en évolution rapide dans des collections Milvus normales tout en utilisant les External Collections pour de grands corpus, catalogues, ensembles de données historiques, caractéristiques de modèles ou d'autres données déjà produites et gouvernées dans le lac.

Pourquoi la suppression de la seconde copie est importante

Il est tentant de décrire les External Collections comme une optimisation du stockage : ne copiez pas plusieurs téraoctets de données dans une autre base de données et vous économisez du stockage. C'est utile, mais ce n'est pas le principal problème architectural.

Le coût le plus élevé vient du maintien de l'alignement de deux systèmes de données.

Reprenons le catalogue produits. La plateforme de données produit l'ensemble de données Parquet faisant autorité. La recherche l'importe dans une base de données vectorielle. Une équipe de recommandation peut lire les mêmes données du lac via Spark pour une analyse hors ligne. Un nouveau modèle d'embedding génère ensuite une colonne vectorielle de remplacement. L'inventaire et les métadonnées continuent de changer simultanément.

Une fois que la copie de service en ligne devient indépendante du lac, chaque changement doit franchir cette frontière :

les données doivent être copiées ;
le transfert doit être planifié et surveillé ;
les tâches échouées nécessitent de nouvelles tentatives ;
les schémas et les autorisations peuvent devoir être représentés dans plusieurs systèmes ;
la fraîcheur dépend de la rapidité avec laquelle le pipeline de synchronisation rattrape son retard ;
les équipes doivent savoir quelle copie représente la version qu'elles veulent réellement.

Le stockage n'est qu'un poste de dépense.

Coût	Lac séparé + copie de service	External Collection
Copies des données sources	Copie dans le lac plus une copie de service séparée	Les lignes sources restent dans le lac
Mouvement des données	Pipeline ETL/importation persistant	Refresh sur la source externe
Fraîcheur	Dépend de la cadence d'exportation/importation	Contrôlée par le moment où un nouveau Refresh est publié
Gouvernance	Les copies source et de service doivent rester alignées	La propriété de la source, la traçabilité et le versionnement restent avec la plateforme du lac
Réutilisation hors ligne	D'autres consommateurs peuvent préparer leurs propres copies	Les outils de lac existants peuvent continuer à lire la même source
Ressources de service	Dimensionnées autour de la copie de base de données et de la charge d'interrogation	L'indexation, le calcul d'interrogation et les caches peuvent être gérés séparément de la propriété des lignes sources

La différence devient particulièrement importante à mesure que les données IA changent plus souvent.

Les équipes dédupliquent les corpus. Elles regroupent les données pour l'analyse. Elles génèrent de nouveaux embeddings lorsqu'un modèle change. Elles ajoutent des étiquettes, des résumés, des entités extraites, des scores de qualité ou des signaux de retour. Elles exécutent des tâches d'évaluation et des pipelines de nettoyage de données sur le même corpus que celui à partir duquel les applications de production effectuent leur récupération.

Si chaque système possède sa propre copie, chaque amélioration devient une autre tâche de synchronisation.

External Collection change cette frontière : les systèmes hors ligne peuvent continuer à travailler sur l'ensemble de données du lac, tandis que Milvus sert la récupération sur la même fondation.

Quelles sources de données External Collection prend en charge

External Collection est conçue autour de données ouvertes et gérées en externe plutôt que d'une disposition de source spécifique à Milvus. Elle prend en charge plusieurs formats de sources externes via Storage V3 :

Format externe	valeur de format	Ce que Milvus lit
Apache Parquet	parquet	Un répertoire ou un préfixe de stockage d'objets contenant des fichiers Parquet et des groupes de lignes
Vortex	vortex	Fichiers Vortex et leurs métadonnées de disposition
Lance	lance-table	Un ensemble de données Lance et ses métadonnées de fragments
Apache Iceberg	iceberg-table	Métadonnées Iceberg plus un instantané sélectionné
Instantané Milvus	milvus-table	Un instantané Milvus pris en charge exposé comme source externe

Le mappage entre la source et Milvus est explicite.

Une colonne source nommée product_id peut devenir le champ Milvus id ; image_vec peut devenir embedding ; et une table source large n'a pas besoin d'exposer chaque colonne à la collection. Cela signifie que la plateforme de données n'a pas à renommer ou réécrire sa source simplement pour satisfaire la base de données de service.

Les formats versionnés ajoutent une autre propriété utile. Avec une source telle qu'Iceberg, la collection peut pointer vers un instantané particulier plutôt que vers ce qui se trouve être courant au moment où la requête est exécutée. Une version source fixe est utile pour l'évaluation reproductible, les tests de régression, l'analyse historique et les charges de travail d'audit.

Les fichiers sous-jacents restent également utilisables par le reste de la pile de données. Spark, les frameworks d'entraînement, les systèmes de gouvernance et d'autres outils compatibles avec le lac peuvent continuer à lire les mêmes données ouvertes.

External Collection ajoute un autre consommateur de ces données ; elle ne fait pas de Milvus son unique propriétaire.

Accéder au stockage externe en toute sécurité

Milvus a également besoin d'autorisation pour lire le stockage externe.

Selon le fournisseur de stockage, les déploiements peuvent utiliser des mécanismes tels que l'identité de charge de travail ou d'instance, l'assomption de rôle AWS STS, l'emprunt d'identité de compte de service, l'accès basé sur SAS ou les systèmes de rôles spécifiques au fournisseur, plutôt que d'intégrer des identifiants de longue durée dans la configuration de l'application.

Cette identité de stockage contrôle la manière dont Milvus accède à la source. L'autorisation à l'intérieur de Milvus reste une frontière de sécurité distincte.

Comment créer, indexer, actualiser et interroger une External Collection

Le cycle de vie d'une External Collection comporte quatre étapes principales :

Définir la source externe et mapper ses colonnes dans un schéma Milvus.
Définir les index dont la charge de travail a besoin.
Exécuter Refresh pour que Milvus découvre les données sources et prépare une version interrogeable.
Charger la collection et utiliser les API de recherche et d'interrogation normales de Milvus.

Voici le même catalogue produits représenté comme External Collection :

import json
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(
uri=“http://localhost:19530”,
token=“root:Milvus”,
)
schema = client.create_schema(
external_source=“s3://my-lake/datasets/products/”,
external_spec=json.dumps(
{
“format”: “parquet”,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“use_iam”: “true”,
“iam_endpoint”: “https://sts.us-east-1.amazonaws.com”,
},
}
),
)
schema.add_field(
field_name=“id”,
datatype=DataType.INT64,
external_field=“product_id”,
)
schema.add_field(
field_name=“embedding”,
datatype=DataType.FLOAT_VECTOR,
dim=768,
external_field=“image_vec”,
)
schema.add_field(
field_name=“title”,
datatype=DataType.VARCHAR,
max_length=256,
external_field=“product_name”,
)
schema.add_field(
field_name=“stock”,
datatype=DataType.INT64,
external_field=“stock”,
)
schema.add_field(
field_name=“rating”,
datatype=DataType.FLOAT,
external_field=“rating”,
)
client.create_collection(
collection_name=“products_ext”,
schema=schema,
)

Les index utilisent l'interface normale de Milvus :

index_params = client.prepare_index_params()
index_params.add_index(
    field_name="embedding",
    index_type="HNSW",
    metric_type="COSINE",
)
index_params.add_index(field_name="stock", index_type="AUTOINDEX")
index_params.add_index(field_name="rating", index_type="AUTOINDEX")
client.create_index(
collection_name=“products_ext”,
index_params=index_params,
)

Puis actualisez la source externe :

job_id = client.refresh_external_collection(
    collection_name="products_ext",
)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(2)

Une fois la version actualisée prête, chargez-la et recherchez-la comme une collection Milvus normale :

client.load_collection("products_ext")
results = client.search(
collection_name=“products_ext”,
data=[query_vec],
anns_field=“embedding”,
filter=“stock > 0 and rating >= 4.0”,
limit=10,
output_fields=[“id”, “title”, “stock”, “rating”],
)

La différence importante n'est pas l'appel de recherche. C'est là où commence le cycle de vie. Une collection gérée par Milvus commence avec des données écrites ou importées dans Milvus. Une External Collection commence avec une référence à des données qui existent déjà ailleurs.

Comment Refresh détecte les changements dans les données externes

L'External Collection est en lecture seule du côté de Milvus, mais l'ensemble de données sous-jacent dans le lac n'a pas à rester gelé pour toujours.

Supposons que le pipeline produit ajoute un autre lot, met à jour des métadonnées ou écrit des embeddings provenant d'un nouveau modèle. Milvus ne suit pas en continu chaque objet qui apparaît dans le chemin source. Ces changements deviennent visibles via Refresh.

Refresh lit les métadonnées externes, résout les fragments sources, met à jour les manifestes qui les connectent à la collection Milvus et prépare l'état d'index correspondant.

Le point clé est que ce travail peut être incrémental.

Milvus identifie les fragments sources qui n'ont pas changé et peut réutiliser leurs segments et travaux d'index existants. Les fragments nouveaux ou modifiés sont les parties qui nécessitent un nouveau traitement.

Un petit changement dans un ensemble de données de plusieurs téraoctets n'a donc pas à déclencher une nouvelle importation complète et une reconstruction complète des index.

Refresh donne également au système de service une frontière de version claire. Pendant qu'une nouvelle version est préparée, les requêtes continuent d'utiliser l'état publié précédemment. Une fois Refresh terminé, le nouvel état devient disponible en tant que version complète plutôt que d'exposer un mélange de données anciennes et partiellement préparées.

Ce modèle s'intègre naturellement avec les constructions de catalogue horaires, les mises à jour nocturnes de base de connaissances, les actualisations périodiques d'embeddings, les pipelines de caractéristiques générés par modèle et d'autres charges de travail orientées lots.

Il ne remplace pas un chemin d'écriture en continu. Si chaque insertion ou suppression doit devenir interrogeable via Milvus immédiatement, une collection gérée reste le meilleur modèle.

Comment le chargement paresseux réduit l'utilisation de la mémoire pour les ensembles de données larges

Le fait de conserver les lignes sources dans le stockage d'objets n'aide que si la couche de service n'a pas à charger chaque octet localement avant de pouvoir répondre aux requêtes. Avec le Tiered Storage de Milvus activé, ce n'est pas le cas.

Au moment du chargement de la collection, les QueryNodes peuvent initialement ne conserver que des métadonnées légères telles que les informations de schéma, les définitions d'index, les cartes de chunks et les références aux objets distants. Les données de champ sont récupérées au niveau du chunk lorsqu'une requête en a besoin ; les index peuvent rester distants jusqu'à la première utilisation, puis être mis en cache localement. Les données fréquemment utilisées restent chaudes, tandis que les données moins fréquemment accédées peuvent être évincées.

C'est particulièrement utile pour les ensembles de données IA larges.

Une ligne produit peut contenir plusieurs embeddings, une longue description, du JSON brut, des métadonnées d'image, des résumés générés, l'inventaire, les prix, les évaluations et de nombreux autres attributs. Une recherche de similarité typique peut ne toucher qu'un seul vecteur plus l'inventaire, le prix et l'évaluation. Il n'y a aucune raison pour que chaque autre champ occupe en permanence la mémoire de service simplement parce qu'il appartient au même enregistrement.

External Collection peut réduire l'empreinte de service à deux niveaux :

D'abord, la projection au niveau du schéma. Via external_field, l'External Collection ne peut exposer que les colonnes sources dont l'application a besoin. Les autres colonnes restent dans l'ensemble de données du lac et ne sont pas incluses dans ce schéma de service.
Ensuite, la projection au moment de l'exécution. Avec le modèle de service à plusieurs niveaux, les QueryNodes récupèrent et mettent en cache les champs et index réellement nécessaires à la charge de travail plutôt que de charger l'ensemble du dataset mappé au préalable.

En d'autres termes, l'ensemble de données peut rester large dans le lac sans forcer l'empreinte de service à être tout aussi large.

Il y a un compromis évident. Une requête qui atteint un champ ou un index froid peut subir un coût de lecture distante au premier accès. Les politiques de préchauffage peuvent précharger les champs ou index critiques pour la latence, tandis que les politiques de cache et d'éviction évitent que les états moins fréquemment accédés n'occupent indéfiniment les ressources locales.

Le but n'est pas que le stockage d'objets se comporte comme de la RAM. C'est que la mémoire et le disque local peuvent suivre l'ensemble de travail de la charge de récupération, plutôt que la taille et la largeur totales de l'ensemble de données source.

Le format source compte également ici. Les formats conçus pour des balayages analytiques larges et les formats optimisés pour des lectures plus étroites ou aléatoires peuvent produire des comportements d'E/S différents sous un accès à la demande. External Collection n'efface pas ces compromis au niveau du stockage ; elle permet à Milvus de construire une couche de récupération par-dessus.

Quelles capacités de recherche et d'indexation External Collection prend en charge

External Collection ne se contente pas de pointer Milvus vers un répertoire d'embeddings et de balayer les fichiers. Milvus construit des structures de récupération sur des données externes et exécute les requêtes via son moteur de récupération standard.

Index Milvus construits sur des données externes

Selon les champs et la charge de travail, Milvus peut construire :

des index vectoriels pour la recherche ANN ;
des index scalaires pour le filtrage des métadonnées ;
des index JSON pour les attributs semi-structurés ;
des index BM25 et de texte intégral pour la récupération lexicale ;
des champs générés par fonction pris en charge par le modèle de données Milvus.

La recherche ANN utilise ces index pour réduire l'ensemble des candidats au lieu de lire chaque vecteur source.

Cette distinction est importante car stocker un embedding dans un lac n'est pas la même chose que d'exploiter une base de données vectorielle par-dessus. La persistance vous donne des octets. La récupération de production nécessite également des index, la planification de requêtes, le filtrage, le classement, la mise en cache et un chemin de service à faible latence.

Au-delà du top-K vectoriel

Une autre erreur courante est de lire « External Collection » comme « recherche vectorielle sur Parquet ». Cela sous-estime ce que la récupération de production exige réellement.

Un résultat de recherche de production dépend rarement de la seule similarité vectorielle. Il peut également dépendre de termes exacts, de la politique d'accès, de l'inventaire, de l'horodatage, de la catégorie, du prix, de la qualité de la source ou de signaux de classement métier.

Considérons une requête telle que :

robe fleurie rouge pour l'été, en stock, meilleures évaluations d'abord

Un chemin de récupération de production peut nécessiter plusieurs signaux :

Similarité vectorielle pour le sens sémantique de « robe fleurie d'été ».
Recherche lexicale ou en texte intégral pour un terme exact tel que « rouge ».
Filtres scalaires pour exclure les produits en rupture de stock ou sous un seuil d'évaluation.
Récupération hybride et classement pour combiner plusieurs signaux de récupération.

Milvus 3.0 étend également le moteur de requête au-delà de la recherche initiale des plus proches voisins avec des capacités telles que le tri, l'agrégation et le facettage côté serveur.

Le point plus large est qu'External Collection donne aux données résidant dans le lac un chemin de récupération de base de données—pas simplement un moyen de lire des vecteurs à partir de fichiers.

Comment les mêmes données du lac prennent en charge le service en ligne et le traitement hors ligne

La raison architecturale la plus forte de conserver la source dans un format de lac ouvert n'est pas simplement qu'une seconde copie coûte de l'argent. C'est que le même ensemble de données peut rester disponible pour les systèmes qui l'améliorent en continu.

Revenons au catalogue produits.

Pendant la journée, Milvus peut servir une External Collection pour la recherche de produits, les recommandations ou la récupération pour agents.

En parallèle, d'autres systèmes peuvent travailler directement sur l'ensemble de données du lac :

Spark peut identifier les produits en double.
Un pipeline d'entraînement peut générer des embeddings à partir d'un nouveau modèle.
Une tâche de qualité des données peut détecter les enregistrements malformés ou anormaux.
Un pipeline d'évaluation peut comparer la qualité de récupération entre les versions de modèles.
Un processus par lots peut générer des résumés, des étiquettes ou des métadonnées supplémentaires.

External Collection n'exécute pas ces tâches elle-même. Spark reste Spark ; l'entraînement reste l'entraînement. Son rôle est de supprimer la frontière supplémentaire des données de service entre eux.

Le travail hors ligne peut écrire des données améliorées ou de nouveaux champs dans le lac. Un Refresh ultérieur rend la source mise à jour disponible pour le chemin de récupération Milvus.

Il n'y a pas de boucle d'exportation-importation séparée dont le seul but est de reconstruire une autre copie faisant autorité pour le service.

La gouvernance reste également clairement répartie. Les versions sources, la traçabilité et la propriété de la source restent avec la plateforme du lac. Milvus maintient sa propre autorisation au niveau de la collection et les identifiants nécessaires pour lire la source. Partager une seule fondation de données ne signifie pas fusionner tous les domaines de sécurité dans un système unique.

C'est le lien avec le Vector Lakebase : le lac reste la fondation de données partagée, tandis que Milvus fournit une couche de récupération à faible latence par-dessus. External Collection est une partie de cette architecture, aux côtés de Storage V3, des instantanés, de l'intégration Spark, de l'évolution de schéma et du rétro-remplissage.

Où External Collection s'intègre—et où elle ne s'intègre pas

External Collection est un excellent choix lorsque :

Vos données faisant autorité résident déjà dans Parquet, Vortex, Lance, Iceberg ou une autre source externe prise en charge.
L'ensemble de données est principalement produit par lots plutôt que par des écritures transactionnelles à haute fréquence.
Le maintien d'une seconde copie de service crée une charge importante d'ETL, de fraîcheur ou de gouvernance.
Plusieurs systèmes doivent travailler avec le même ensemble de données ouvert.
Une frontière Refresh explicite est acceptable pour la fraîcheur du service.
Vous voulez une récupération Milvus de production sans faire de Milvus le propriétaire des lignes sources.

Une collection Milvus normale reste le meilleur choix lorsque :

l'application insère ou met à jour (upsert) des enregistrements en continu ;
les suppressions doivent devenir visibles via le chemin d'écriture en ligne ;
la charge de travail dépend de fonctionnalités de collection indisponibles pour les schémas externes ;
la conception du service maintient intentionnellement toutes les données nécessaires en mémoire, évitant les manques de cache distants.

Plusieurs frontières méritent d'être gardées à l'esprit.

Les External Collections sont en lecture seule. Les changements de source se produisent en dehors de Milvus.
La zéro copie s'applique aux lignes sources. Les index, manifestes, caches et le calcul coûtent toujours des ressources.
Refresh est explicite. Ce n'est pas un mécanisme de synchronisation en continu.
La source doit rester accessible. La recherche, l'index et le comportement de Refresh dépendent toujours de l'accès au stockage et des identifiants.
Storage V3 est requis. Dans Milvus 3.0 open source, il doit être activé avant d'utiliser External Collection.
External Collection ne remplace pas le traitement en amont. La génération d'embeddings, le regroupement, la déduplication et le nettoyage des données se font toujours dans les systèmes en amont appropriés.

Le choix est donc complémentaire plutôt que binaire. Un système peut utiliser des collections Milvus normales pour l'état en ligne en évolution rapide et des External Collections pour les grands ensembles de données produits par lots dont la maison naturelle est le lac.

Essayez External Collection dans Milvus 3.0

External Collection est disponible dans Milvus 3.0. Commencez avec un ensemble de données de lac représentatif et évaluez les aspects qui comptent pour votre charge de travail : le refresh initial et incrémental, le coût de construction des index, le comportement des requêtes à chaud et à froid, et l'intervalle de fraîcheur requis par votre application.

Pour les détails d'implémentation, voir :

Si vous préférez une voie gérée, External Collection est également disponible dans le cadre de Zilliz Vector Lakebase sur Zilliz Cloud. Voir :

Vous pouvez également apporter des questions d'implémentation ou des retours au dépôt GitHub Milvus ou à la communauté Discord Milvus.

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started

Like the article? Spread the word