Une Base de Données, Deux Charges de Travail, Beaucoup de Problèmes : OLTP vs OLAP P. 1

Pour les transactions en temps réel, vous avez besoin d’un type de système — OLTP (Online Transaction Processing). Pour l’analyse, vous en avez besoin d’un autre — OLAP (Online Analytical Processing). Un OLTP, c’est comme Sonic le Hérisson : toujours en mouvement, fonçant à pleine vitesse, réagissant instantanément aux obstacles et collectant des anneaux en chemin. Un OLTP traite chaque transaction rapidement et de manière prévisible. Un OLAP, en revanche, ressemble plus à Kirby : il absorbe tout sur son passage : tas d’objets, ennemis, mondes entiers. Les systèmes OLAP absorbent des volumes massifs de données — millions et milliards de lignes — afin de pouvoir ensuite les digérer et les transformer en quelque chose de significatif, comme un rapport.

Et comme les cas d’usage sont très différents, il est logique que l’architecture des serveurs, les systèmes de stockage et même les moteurs de base de données soient également différents.

C’est là que nous arrivons au sujet principal. Dans cette lecture approfondie, nous parlerons d’OLAP, d’OLTP et du matériel qui les supporte.

OLAP et OLTP : Ce qu’ils sont et pourquoi ils existent

Allons un peu plus en profondeur dans la technologie.

OLAP et OLTP ont des objectifs et des architectures complètement différents. C’est pourquoi, pour la plupart des entreprises, la vraie question n’est pas de choisir entre les deux, mais de déterminer comment les combiner correctement au sein d’une seule infrastructure.

Un OLAP est un outil pour l’analyse complexe de grands volumes de données. C’est ainsi que les entreprises obtiennent des insights analytiques significatifs. Prenons l’exemple de la grande distribution alimentaire : les analystes collectent toutes les données de vente d’une période donnée à partir de multiples sources — bases de données opérationnelles, services externes et autres systèmes. Toutes ces données sont ensuite chargées dans un système de stockage spécialisé — un data warehouse — optimisé pour l’analyse multidimensionnelle.

Ensuite, les analystes exécutent une requête :
« Combien de beurre et de pain ont été vendus en juin 2024 dans tous les magasins d’une région donnée, comment ces chiffres ont-ils changé en juin 2025, et quelle est la relation entre ces produits ? »

Répondre à une telle question nécessite d’agréger des millions de lignes, de filtrer les données par région, catégorie et date, puis de calculer les corrélations, les évolutions et les prévisions. De telles requêtes peuvent prendre beaucoup de temps — dans des limites raisonnables — et c’est parfaitement normal, car les résultats sont utilisés pour prendre des décisions commerciales et définir une stratégie à long terme.

En OLAP, la complétude et la précision sont plus importantes que le temps de réponse instantané. C’est pourquoi les analyses stratégiques — rapports annuels ou prévisions à long terme — peuvent durer une ou deux heures. C’est une autre histoire lorsque les analyses opérationnelles pour les décisions quotidiennes, comme les changements de prix, prennent des heures à s’exécuter — c’est généralement le signe d’une infrastructure inadaptée.

Au cœur de l’OLAP se trouvent des structures de données multidimensionnelles (cubes), qui permettent de visualiser les données sous différents angles — par temps, région, produit, client et des dizaines d’autres dimensions. Cela fait de l’OLAP un outil idéal pour l’analyse stratégique. Contrairement, par exemple, aux systèmes CRM, où l’objectif principal est la gestion opérationnelle des clients et des transactions, et non des requêtes complexes sur des téraoctets de données historiques de ventes.

Les outils OLAP classiques incluent ClickHouse, Greenplum, Hadoop/Spark et Amazon Redshift. Ils sont conçus pour le traitement à grande échelle et le parallélisme.

L’OLTP, en revanche, est conçu pour la vitesse lors du traitement d’opérations individuelles. À la caisse d’un supermarché, chaque transaction — scanner un article, prendre le paiement, enregistrer l’opération — doit se produire instantanément. Tout retard signifie que les files d’attente s’allongent et que les clients partent. Personne n’attendra trois minutes par article juste pour acheter du beurre et du pain.

Les systèmes OLTP sont optimisés spécifiquement pour ces opérations rapides, fréquentes et en temps réel. Mais les utiliser pour des analyses stratégiques est presque inutile — les requêtes complexes sur de grands ensembles de données ne sont tout simplement pas pour eux.

Les bases de données OLTP typiques incluent PostgreSQL, MySQL/InnoDB, Oracle Database et Microsoft SQL Server.

Il existe également des solutions hybrides — HTAP (Hybrid Transactional/Analytical Processing) — qui tentent de combiner transactions et analyses au sein d’un même système, comme TiDB, SAP HANA ou YugabyteDB. En pratique, cependant, la plupart des entreprises séparent encore les charges de travail : une base gère les opérations rapides, une autre gère l’analytique. La commodité des systèmes hybrides se paie par une complexité accrue de l’infrastructure et des exigences matérielles plus élevées.

Et c’est là que les architectes IT, administrateurs ou toute personne responsable commencent à se poser des questions. Quel serveur utiliser pour un système OLAP et lequel pour un OLTP ? Faut-il des serveurs séparés ? Des machines virtuelles ? Un cluster ? Peut-être des nœuds de calcul combinés à un stockage séparé ? Combien de systèmes de stockage sont nécessaires ? S’il y en a plusieurs, doivent-ils être actifs-actifs ou actif-standby ? Et ce n’est que le début — il y a des dizaines, voire des centaines, de détails similaires.

Et ces détails affectent directement l’entreprise.

Je ne pourrai pas répondre à toutes les questions possibles — chaque charge de travail est différente — mais je vais essayer de donner des points de référence utiles. Et, comme toujours, les commentaires sont ouverts.

Comment Choisir les Serveurs et le Stockage pour OLTP et OLAP

Sélectionner des serveurs pour OLTP et OLAP sont deux tâches très différentes, et les erreurs ici sont coûteuses. Mettre un stockage lent sous OLTP, et vous aurez des files d’attente de requêtes et des clients mécontents. Essayer de faire tourner un OLAP sur des serveurs inadaptés, et vous verrez des requêtes s’exécuter pendant des semaines. Économiser sur la redondance des données et des composants… eh bien, vous savez déjà comment cela finit.

Dans les systèmes de bases de données à forte charge, la performance et la fiabilité dépendent directement de l’architecture et du matériel. Mais avant d’acheter du matériel, il faut s’intéresser aux décisions architecturales. Commençons par l’OLTP.

Architecture OLTP : Vitesse et Prédictibilité

Les systèmes OLTP sont le front du business. La banque en ligne, les passerelles de paiement et les plateformes e-commerce fonctionnent dessus. Ces systèmes ont des exigences claires : des dizaines ou des centaines de milliers de transactions par seconde, des SLA de latence stricts mesurés en millisecondes et l’intégrité des données — perdre un seul enregistrement de transaction équivaut à perdre de l’argent.

Chaque système transactionnel est construit autour des exigences ACID (Atomicité, Cohérence, Isolation, Durabilité). En termes simples :

• Une transaction est exécutée entièrement ou pas du tout (Atomicité)

• Les données restent dans un état cohérent (Cohérence)

• Les opérations parallèles ne s’interfèrent pas entre elles (Isolation)

• Les données ne sont pas perdues même en cas de panne (Durabilité)

Lorsqu’un architecte IT examine un tel système, il ne commence pas par penser au matériel. Les préoccupations principales sont : comment normaliser les données afin que les transactions restent rapides et cohérentes ; comment distribuer la charge sur les clusters en utilisant le sharding et la réplication ; et comment concevoir la tolérance aux pannes afin que la défaillance d’un ou plusieurs nœuds ne mette pas l’ensemble du système hors service.

Conclusion :
Si la simplicité compte et que la charge attendue est modérée, le choix optimal est une combinaison de réplication et de caching — par exemple PostgreSQL ou MySQL avec Redis. Lorsque le volume de données croît et que la charge augmente linéairement, et si la cohérence globale stricte n’est pas critique, les architectures shared-nothing avec sharding ont plus de sens. Si la cohérence stricte est la priorité absolue — et que le budget le permet — les solutions shared-disk comme Oracle RAC sont le meilleur choix. Pour les systèmes nécessitant une vitesse de traitement extrême ou de l’analytique en temps réel, il vaut la peine de considérer les bases de données en mémoire.

Dans le tableau ci-dessous, j’ai résumé les principales approches architecturales utilisées pour la conception des systèmes OLTP.