FerroDruid Container

Build container de FerroDruid. Déployez la base OLAP temps réel compatible avec la spécification Apache Druid sous forme d’un binaire Rust unique sur Amazon EKS via le chart Helm inclus. Parle l’API REST Druid, le JSON de requête natif et Druid SQL ; lit/écrit les segments Druid v9/v10. Pas de JVM, pas de ZooKeeper, pas de control plane à six processus. Mesuré au pod-hour, impose une rotation du mot de passe admin à la première connexion et échoue fermé sans entitlement Marketplace.

Un cluster Apache Druid classique nécessite au moins six processus JVM, plus ZooKeeper, plus une base de métadonnées externe et 16 GB+ de RAM avant de servir une seule requête ; FerroDruid Container remplace tout cela par un seul binaire Rust exécuté comme un pod EKS. C’est le même binaire que le build AMI et il sert les huit types de requêtes natives (timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary) ; exécute Druid SQL (SELECT, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, 30+ fonctions, EXPLAIN PLAN FOR, un endpoint de tâche MSQ, ~95% de parité SQL core) ; expose 40+ endpoints REST compatibles Druid ; et lit/écrit les segments Druid v9/v10. La topologie prise en charge est un node unique avec métadonnées SQLite + deep storage sur système de fichiers local ; le chart Helm échoue fermé au moment du template sur les métadonnées externes, le deep storage externe, `replicaCount>1` et l’injection d’un code produit payant dans une image OSS. Le compte admin est soumis à une rotation forcée à la première connexion (chaque endpoint renvoie 403 jusqu’à rotation), et le container payant vérifie l’entitlement via `RegisterUsage` au démarrage.

Points forts