Analyse en temps réel de pétaoctets sans impact sur la base de données

Une instance de base de données de production Public Cloud est conçue pour les transactions, pas pour l'analyse. Lorsque les équipes métier commencent à demander des tableaux de bord en temps réel, de la détection de fraude ou des requêtes de segmentation client sur des téraoctets de données historiques… eh bien, les performances s'effondrent.
Cela n'arrive pas tant parce que l'infrastructure est faible, mais parce que l'application utilise le mauvais outil pour la tâche.

OLTP vs OLAP

OLTP (traitement transactionnel en ligne) et 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, gérant 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 billions de lignes pour des agrégations complexes. Ils utilisent un stockage en colonnes, où chaque colonne est stockée indépendamment. Cela signifie que lorsque vous interrogez SUM(revenue) WHERE date > '2025-01-01', la base de données ne lit que les colonnes revenue et date, en ignorant tout le reste. Ainsi, par exemple dans ClickHouse, les opérations s'exécutent en exécution vectorisée. ClickHouse traite des tableaux entiers de valeurs à la fois plutôt que des lignes individuelles, ce qui réduit considérablement la charge CPU 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 analyses par colonnes. Les architectures sont fondamentalement différentes.

Pourquoi les réplicas de lecture ne résoudront pas le problème

Les réplicas de lecture dans Public Cloud Databases 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 de lecture peut réduire la contention 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 toujours presque chaque ligne.

Ces requêtes analytiques entrent en concurrence avec les transactions de production pour le CPU, la mémoire et les E/S. La latence de l'application augmente, les SLA sont menacés et les cas d'utilisation en temps réel comme la détection de fraude ou la surveillance d'anomalies deviennent impossibles.

La requête de 40 secondes qui devrait prendre 200 ms

Voici le scénario typique pour une entreprise de plateforme SaaS en pleine croissance ou FinTech atteignant le point d'inflexion des données. Une requête s'exécute, destinée à agréger le revenu quotidien par segment de clientèle sur 18 mois (500 millions de lignes),

Le temps d'exécution attendu selon le modèle de domaine OLAP est de 200 ms, mais le temps réel sur la plateforme OLTP finit par être de 40 secondes. Pourquoi ? Voici ce qui se passe en arrière-plan :

• Analyse complète de la table : La plateforme PostgreSQL/MySQL doit lire les 500 millions de lignes car l'index n'aide pas pour les agrégations larges.

• Traitement ligne par ligne : Chaque ligne est décompressée, analysée et évaluée individuellement.

• Goulot d'étranglement des E/S : Les lectures sur disque dominent — la majeure partie des données lues est rejetée.

• Gaspillage de CPU : Cycles CPU consacrés à l'analyse des lignes au lieu de la qualité de l'agrégation.

• Pression sur la mémoire : Les tris volumineux et les jointures de hachage sont déversés sur le disque.

L'impact sur l'activité est immédiat et cumulatif, car ce qui devrait être un tableau de bord de données horaire ne peut, en pratique, être généré qu'une fois par jour, ce qui retarde les décisions commerciales.
Les décisions commerciales sont retardées car l'analyse minute par minute devient trop coûteuse et les fonctionnalités en temps réel deviennent impossibles à grande échelle. Et cela compte : la réactivité en temps réel est essentielle pour des cas d'utilisation tels que la détection de la fraude, la personnalisation et la surveillance des anomalies. Ces cas d'utilisation ne sont pas viables avec une latence de requête de 40 secondes.