Conçue pour une performance analytique soutenue.
Temps de réponse, capacité concurrente et efficacité opérationnelle sont conçus ensemble plutôt qu’ajoutés après le déploiement.
Le système, domaine par domaine.
- Exécution
- Le filtrage, le regroupement, les jointures et le classement s’exécutent sur le GPU, où les données restent entre les étapes.
- Matériel
- Un GPU par nœud de calcul. La capacité augmente en ajoutant des nœuds.
- Stockage
- Un stockage en colonnes et compressé qui ne lit que les champs référencés par une requête. Les chargements résistent aux pannes.
- Échelle et résilience
- Les tables sont réparties entre les machines avec autant de copies que nécessaire ; les lectures survivent à une panne ; sauvegarde et restauration de l’ensemble du cluster.
- SQL
- Jointures, sous-requêtes, blocs de requête réutilisables et catalogue étendu de fonctions.
- Compatibilité
- Les requêtes ClickHouse s’exécutent telles quelles grâce à une couche de compatibilité.
- Systèmes existants
- Les tables qui résident encore dans ClickHouse, PostgreSQL ou MySQL sont interrogées sur place et jointes aux tables RayoDB.
- Ingestion des données
- Des sources en temps réel provenant de Kafka, MySQL et PostgreSQL qui ne comptent jamais deux fois une ligne, ainsi que le chargement en masse et par API.
- Rétention
- Les données antérieures à une fenêtre choisie sont supprimées selon la planification définie.
- IA en SQL
- Prévisions, détection d’anomalies et recherche sémantique sous forme de fonctions SQL, avec des modèles intégrés ou les vôtres.
- Analyse de sessions
- Mesures de sessions sous forme de fonctions SQL : entonnoirs, activité concurrente, rétention et parcours d’événements.
- Exploitation
- Comptes et clés API avec autorisations, connexions chiffrées, métriques Prometheus et contrôles d’intégrité.
Les questions posées lors de chaque évaluation.
- Faut-il réécrire le SQL existant ?
- Rarement. Les jointures, les sous-requêtes et les fonctions habituelles sont prises en charge, et les requêtes ClickHouse s’exécutent telles quelles. Les éléments manquants sont indiqués ci-dessous.
- Les données doivent-elles être déplacées au préalable ?
- Non. Les tables qui résident encore dans ClickHouse, PostgreSQL ou MySQL peuvent être interrogées sur place. Une évaluation commence donc par les requêtes qui posent problème aujourd’hui.
- Quel matériel est nécessaire ?
- Des GPU NVIDIA, un par nœud de calcul. Le cluster de développement utilise huit cartes grand public par machine, un matériel qu’une équipe peut acheter.Pourquoi les GPU
- Où s’exécute-t-il ?
- Sur vos propres machines ou sur des instances GPU dans le cloud, au sein de votre réseau. Aucun service hébergé n’est proposé pendant l’accès anticipé.
- Quelles sont ses performances ?
- Chaque évaluation mesure le temps de réponse, la capacité concurrente et l’infrastructure face au système qui exécute déjà la même charge.Méthodologie de performance
Ce que RayoDB ne propose pas encore.
- Les tables sont créées par l’API, et non avec CREATE TABLE en SQL.
- Pas de UNION, INTERSECT ni EXCEPT, pas de requêtes récursives, une instruction par requête.
- Ce n’est pas une base de données transactionnelle : elle est conçue pour l’analyse, et non pour traiter des commandes ligne par ligne.
- Les comparaisons générales de performances suivront le programme de benchmark élargi.
Mesurez votre charge de travail.
Les partenaires en accès anticipé comparent RayoDB à leur système actuel avec leurs données et leurs requêtes.