Analysez vos données en temps réel sans ralentir votre base de données de production

Séparez les transactions OLTP des charges de travail OLAP pour protéger les performances de production. Déplacez les données analytiques vers ClickHouse et obtenez un chemin clair pour bénéficier en moins d'une seconde d’une visibilité sur des milliards de lignes, sans forcer votre base de données transactionnelle à gérer d’importants scans et agrégations.
Découvrir ClickHouseDécouvrir Analytics
Noms de domaine illustration

Séparer les transactions des analyses

Les applications en développement atteignent toutes le même point d'inflexion. Il s’agit du moment où une entreprise souhaite interroger une base de données PostgreSQL ou MySQL contenant des pétaoctets de données d'une manière pour laquelle elle n'a jamais été conçue. 

Résultat : une requête de tableau de bord qui devrait prendre 200 ms nécessite en réalité 40 secondes, car l'analyse scanne 500 millions de lignes, écrasant le processeur et les E/S. Les utilisateurs attendent trop longtemps les résultats des requêtes, et au bout du compte, l'intégralité de l'accord de niveau de service (SLA) est mise en doute.  Ce n'est pas un problème qui se résout avec des réglages. Cela nécessite plutôt un changement d'architecture : vous devez arrêter d'exécuter des requêtes lourdes sur votre base de données de production. 

Gardez PostgreSQL axé sur les lectures et écritures transactionnelles, pendant qu’OVHcloud Managed ClickHouse gère les requêtes analytiques. Pour l'analyse de données de pétaoctets en temps réel, le stockage objet compatible S3 fournit une couche de capacité évolutive au-delà du stockage haut débit principal, permettant à votre environnement analytique de croître sans étendre la base de données de production. 
OVHcloud_Dedicated_Server_HG_Memory_DB_61200x800.png

Performance et contrôle à grande échelle

Isoler les analyses, exécuter des requêtes en moins d'une seconde et conserver la résidence des données dans l'UE sans risque lié au Cloud Act
[object Object]
Isoler les analyses en temps réel
[object Object]
Prendre en charge des requêtes en moins d'une seconde
[object Object]
Exécuter sur trois zones de disponibilité
[object Object]
Utiliser une mise à l'échelle basée sur les ressources

Pourquoi la mise à l'échelle des bases de données de production est insuffisante pour la demande analytique

Pression sur les bases de données transactionnelles

Les bases de données transactionnelles excellent dans les recherches, insertions et mises à jour rapides. L'analyse de pétaoctets de données en temps réel crée une demande différente : des scans étendus, des jointures complexes et des agrégations répétées qui rivalisent avec le trafic de production pour le processeur, la mémoire et le débit de stockage.  Une instance de base de données Public Cloud de production est conçue pour les transactions, pas pour l'analyse. Lorsque les équipes métier commencent à demander des tableaux de bord, une détection des fraudes ou des requêtes de segmentation client sur des téraoctets de données historiques en temps réel… eh bien, les performances s'effondrent.

Limites des réplicas en lecture

Les réplicas en lecture dans les bases de données Public Cloud sont la première réponse la plus courante à la pression analytique sur les bases de données de production. Ils déchargent le trafic de lecture du nœud principal, mais ils ne corrigent pas l'inadéquation architecturale. Un réplica en lecture peut réduire le conflit sur votre base de données principale, mais lorsque vous exécutez SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' sur 500 millions de lignes, le réplica lit et rejette tout de même presque chaque ligne. Ces requêtes analytiques entrent en concurrence avec les transactions de production pour le processeur, la mémoire et les E/S. La latence de l'application augmente, les SLA sont menacés et les cas d'usage en temps réel comme la détection de fraude ou la surveillance d'anomalies deviennent impossibles.

Séparation durable des charges de travail

Une approche durable sépare les charges de travail. Apache Kafka transmet les événements validés vers une plateforme dédiée conçue pour l'analyse à l'échelle du pétaoctet. Les bases de données de production continuent de servir les transactions, tandis que l'environnement analytique évolue indépendamment pour les données à grande échelle, le streaming des analyses, l'intelligence artificielle et la Business Intelligence. 

Attribuer chaque charge de travail au bon moteur

OLTPOLAPDebezium
L'OLTP (traitement transactionnel en ligne) et l'OLAP (traitement analytique en ligne) se situent aux extrémités opposées du spectre de l'architecture des données. Les systèmes OLTP privilégient l'exactitude et la précision au niveau des transactions, traitant des milliers de petites écritures et lectures rapides par seconde.
Ils stockent les données ligne par ligne, optimisés pour rechercher un enregistrement client unique ou mettre à jour le statut d'une commande en quelques millisecondes.

Les systèmes OLAP, en revanche, sont conçus pour analyser des milliers de milliards de lignes pour des agrégations complexes. Ils utilisent un stockage en colonnes, où chaque colonne est enregistrée indépendamment. Cela signifie que lorsque vous effectuez la requête SUM(revenue) WHERE date > '2025-01-01', la base de données ne lit que les colonnes « revenus » et « date », en ignorant tout le reste. Ainsi, par exemple dans ClickHouse, les opérations s'exécutent de manière vectorisée. ClickHouse traite des tableaux entiers de valeurs à la fois plutôt que des lignes individuelles, ce qui réduit considérablement la surcharge sur le processeur et maximise l'utilisation du cache.

Aucune quantité d'indexation de données, d'optimisation de requêtes ou de mises à niveau matérielles ne rendra une base de données orientée ligne efficace pour les scans par colonne. Les architectures sont fondamentalement différentes.
Découvrir ClickHouseVérifier les bases de données OLTP
1200x800 forex.png
L'analyse de pétaoctets de données en temps réel offre aux équipes SaaS une vue unifiée de l'activité des locataires, de la télémétrie des produits et de la santé des services à travers des milliards d'événements. Le stockage en colonnes prend en charge des tableaux de bord opérationnels réactifs sans renvoyer les scans étendus vers la base de données PostgreSQL. Managed ClickHouse vous aide à analyser l'utilisation au niveau du locataire à grande échelle, afin que vous puissiez identifier les tendances d'adoption, comparer les performances et transformer les données produit en informations exploitables.
Les équipes FinTech peuvent évaluer les flux de transactions, les anomalies et les indicateurs de risque avec une faible latence, tandis que les systèmes de paiement restent axés sur le traitement. La résidence des données en Europe peut répondre aux exigences de gouvernance et de conformité au RGPD, sous réserve des contrôles et de l'évaluation juridique propres à l'entreprise. Les investigations en moins d'une seconde aident les analystes à explorer rapidement les activités suspectes, tandis que la séparation des charges de travail protège le traitement des paiements de la demande analytique. Les données analytiques gouvernées offrent aux équipes de de gestion des risques une base fiable pour le suivi et le reporting.
L'analyse de campagne rassemble les impressions, les clics, les conversions et les enregistrements d'attribution pour une comparaison rapide. Cette séparation améliore le reporting et permet une exécution cohérente des requêtes analytiques à travers les canaux, les audiences et les périodes. L'analyse de données en temps réel à l'échelle du pétaoctet aide les équipes AdTech à optimiser les campagnes pendant leur exécution, en identifiant rapidement les audiences et les emplacements les plus performants. Des informations rapides favorisent des ajustements budgétaires assurés et des décisions opportunes.
Les équipes de vente au détail peuvent combiner les catalogues, les commandes et les enregistrements comportementaux pour analyser la demande, le merchandising et l'exécution des commandes. Le traitement ETL par lots convient aux backfills historiques et aux flux de fournisseurs planifiés, tandis que le streaming capture l'activité actuelle. Cette intégration prend en charge la comparaison dans le temps et peut fournir à un blog technique des preuves actuelles et interrogeables. L'analyse en moins d’une seconde aide les équipes à surveiller les stocks, à comprendre les parcours clients et à prendre des décisions opérationnelles rapidement sans imposer de demande supplémentaire aux systèmes de production.
L'analyse de pétaoctets de données en temps réel offre aux équipes SaaS une vue unifiée de l'activité des locataires, de la télémétrie des produits et de la santé des services à travers des milliards d'événements. Le stockage en colonnes prend en charge des tableaux de bord opérationnels réactifs sans renvoyer les scans étendus vers la base de données PostgreSQL. Managed ClickHouse vous aide à analyser l'utilisation au niveau du locataire à grande échelle, afin que vous puissiez identifier les tendances d'adoption, comparer les performances et transformer les données produit en informations exploitables.

Choisir un modèle de chargement pour chaque source de données

Streaming

Livrez des événements en continu lorsque les tableaux de bord opérationnels et les alertes dépendent d'un traitement à faible latence.

Traitement par lots

Utilisez l'ETL par lots avec Airflow pour planifier les backfills historiques, les exportations périodiques et les chargements de sources en masse.

Capture des données modifiées

Propagez les modifications de base de données validées tout en limitant le travail supplémentaire sur la source transactionnelle.

Ingestion directe

Laissez les applications écrire des événements analytiques directement lorsque vos équipes possèdent et régissent le contrat d'événement.

Séparer l'OLTP de l'OLAP

DbtVuesAgrégats
PostgreSQL et MySQL stockent les données ligne par ligne, ce qui est logique pour les transactions d'ingénierie récupérant des enregistrements uniques, mais terrible pour les analyses agrégeant une colonne sur des milliards de lignes. ClickHouse, en revanche, stocke les données par colonne.

Lorsque vous interrogez SUM(revenue) sur 5 milliards de lignes, il ne lit que la colonne « revenus », en ignorant tout le reste. Cela réduit les E/S de 90 % ou plus et permet une compression agressive, car les valeurs d'une colonne sont similaires.

L'exécution vectorisée est le deuxième multiplicateur. Les bases de données traditionnelles traitent une ligne à la fois. ClickHouse traite des tableaux entiers de valeurs à la fois, en chargeant un bloc de la colonne « revenus » dans le cache du processeur et en appliquant des opérations sur l'ensemble du volume vectoriel en une seule instruction. Cela réduit considérablement la charge du processeur.

Cette combinaison permet d’exécuter des requêtes en moins d'une seconde sur des milliards de lignes. Le stockage en colonnes minimise les lectures sur disque ; l'exécution vectorisée minimise le travail du processeur. ClickHouse peut agréger 10 milliards de lignes en moins d'une seconde, tandis qu'il faut plusieurs minutes à une instance PostgreSQL pour y parvenir.
Découvrir Analytics
[object Object]

Concevoir une solution alliant actualisation, vitesse, résilience et gouvernance

ETL par lots

L'ETL par lots est le point de départ le plus simple. Extrayez les données de votre base de données de production selon une planification (toutes les heures ou tous les jours), transformez-les avec dbt et chargez-les dans ClickHouse. Airflow orchestre le pipeline, ou des tâches cron gèrent des scripts simples. 

Cela fonctionne lorsque vous n'avez pas besoin d'une actualisation à la minute près. Les tableaux de bord horaires conviennent à de nombreux cas commerciaux, et le traitement par lots est plus facile à déboguer et à surveiller. 

En contrepartie, vous créez une latence. Les données sont obsolètes entre les lots, donc la détection de fraude en temps réel ou la personnalisation en direct ne sont pas possibles. L'ETL par lots est approprié lorsque vous débutez avec ClickHouse, que vous manquez d'expertise en streaming ou que vous tolérez des données vieilles d'une heure.

CDC en temps réel

La capture des données modifiées (CDC) transmet chaque insertion, mise à jour et suppression de la production vers ClickHouse en temps quasi réel. Debezium lit le journal de transactions de votre base de données (WAL pour PostgreSQL, binlog pour MySQL) et publie les modifications dans Apache Kafka. ClickHouse consomme depuis Kafka et insère immédiatement.

Les outils CDC atteignent une latence allant de la fraction de seconde à quelques secondes, permettant une véritable analyse de données en temps réel : détection de fraude qui repère et bloque les transactions au moment où elles se produisent, surveillance des anomalies qui alerte en quelques secondes, personnalisation qui réagit instantanément selon le comportement des utilisateurs.

Stockage hiérarchisé pour maintenir des coûts linéaires à l'échelle du pétaoctet

Le stockage de pétaoctets sur des SSD est extrêmement coûteux. Le stockage hiérarchisé déplace les données plus anciennes vers un stockage objet moins coûteux tout en conservant les données récentes sur des disques locaux rapides.

Par exemple, OVHcloud Managed ClickHouse implémente ceci nativement dans des outils avec le traitement de flux OVHcloud Object Storage (compatible S3)*. Les données récentes (30 à 90 jours) restent sur le flux sur des SSD NVMe.

Les données plus anciennes migrent automatiquement vers un bucket OVHcloud Object Storage pour un coût très inférieur, tout en permettant des requêtes rapides puisque ClickHouse ne lit que les colonnes nécessaires. Les coûts pour les ingénieurs restent linéaires à mesure que vous évoluez : chaque téraoctet supplémentaire coûte le même prix à 10 To ou 100 To.

Pré-agrégation au moment de l'ingestion

Même avec un stockage de données en colonnes, l'analyse des données brutes à chaque fois est coûteuse. 
Les vues matérialisées pré-calculent les agrégats au moment de l'ingestion.

Dans ClickHouse, une vue matérialisée est un pipeline actif, et non un aperçu passif (snapshot). Lorsque vous insérez des données, ClickHouse évalue automatiquement la requête de la vue et écrit les résultats dans une table distincte.

Si vous ingérez 100 000 événements par seconde avec une vue agrégeant par minute et par segment, ClickHouse calcule ces agrégats en temps réel.

Pourquoi ClickHouse est le moteur idéal pour l'analyse en temps réel

ClickHouse a été conçu dès le départ pour effectuer une analyse en temps réel sur des énormes ensembles de données.

ClickHouse atteint une latence inférieure à la seconde sur des requêtes analysant des milliards de lignes grâce au stockage en colonnes, à l'exécution vectorisée et à une compression agressive. Il peut agréger 10 milliards de lignes en moins d'une seconde, alors qu’il faut plusieurs minutes à PostgreSQL et plusieurs secondes voire des dizaines de secondes à d'autres entrepôts.

ClickHouse offre une tarification stable basée sur les ressources avec une congruence importante et une mise à l'échelle efficace, idéale pour l'analyse interactive en temps réel. Redshift est idéal pour l'entreposage de données orienté par lots avec des charges de travail prévisibles et une infrastructure AWS existante. BigQuery excelle dans l'analyse sans serveur avec des requêtes sporadiques et pour les équipes qui souhaitent zéro surcharge opérationnelle.

ClickHouse utilise un dialecte SQL compatible à 90 % avec l'expérience de développement SQL standard, mais il existe des différences importantes. Les fonctions d'agrégation utilisent des tables MergeTree avec une syntaxe de moteur spécifique. La plupart des requêtes SELECT se traduisent directement, mais les JOIN et sous-requêtes complexes peuvent nécessiter une optimisation.
1200x800 VPS-2.png
Faites évoluer l'analyse tout en protégeant les performances de production
Prêt à libérer votre base de données de production des requêtes analytiques lourdes ? Le déploiement d’OVHcloud Managed ClickHouse ne prend que quelques minutes via le panneau de commande ou l'API. 
Découvrez OVHcloud Managed ClickHouse ou travaillez avec nos spécialistes pour dimensionner une architecture en fonction de votre volume de données, de leur actualisation, de leur rétention et de la concomitance des requêtes.
Découvrir ClickHouse