Architecture et conception
Parseable repose sur un lac de données colonne exascale, développé en Rust. Le langage offre une gestion fine de la mémoire et élimine les coûts d’allocation dynamique, ce qui réduit la latence d’ingestion. Les métriques sont écrites directement au format Parquet, un format colonne ouvert qui applique la compression par bloc et autorise la lecture sélective des colonnes requises. Cette chaîne d’acquisition transforme chaque point OTel en enregistrement Parquet sans étape de transformation intermédiaire lourde, tout en profitant du parallélisme natif de Rust.
Gestion du haut cardinalité
Le haut cardinalité, fréquent dans les métriques d’observabilité, est résolu par la structure colonne : chaque série temporelle devient une combinaison de dimensions stockée comme clé de colonne, évitant la duplication de métadonnées dans chaque enregistrement. Parseable ajoute un smart cache qui mémorise les mappings de clés récentes ; le cache utilise une politique LRU adaptée aux flux continus, limitant les recherches de métadonnées à quelques microsecondes même lorsqu’il traite 100 M points par minute.
Performances et scalabilité
Les spécifications indiquent une capacité d’ingestion de 100 M séries temporelles par minute. Cette performance provient de l’agrégation des écritures en blocs de plusieurs milliers de points avant l’écriture sur disque, réduisant le nombre d’appels système. Le moteur supporte nativement PromQL et SQL, permettant d’exécuter des requêtes analytiques directement sur les fichiers Parquet sans étape de transformation. Les index de colonne filtrent les séries par label, maintenant des temps de réponse constants même lorsque le volume de données dépasse le pétaoctet. Les benchmarks internes montrent une compression moyenne de 4 :1 et une latence de requête inférieure à 200 ms pour des agrégations sur 10 M de points.
Déploiement et écosystème
Parseable s’installe dans des clouds publics, privés ou en mode SaaS géré. Le modèle open‑core expose le moteur sous licence Apache, tandis que les extensions d’interface restent propriétaires. L’intégration native d’OpenTelemetry simplifie la collecte depuis les agents standards, et la compatibilité avec les API Prometheus autorise une migration progressive des systèmes existants. Le principal point de vigilance réside dans le stockage sous‑jacent : des SSD à haut débit sont requis pour soutenir le débit d’écriture décrit, sinon le taux d’ingestion chute proportionnellement. La configuration du partitionnement des fichiers Parquet doit également être adaptée aux schémas de requête pour éviter des scans de colonnes inutiles.
