MySQL vs MongoDB : critères techniques pour projets à fort trafic

Table des matières :

Fort trafic : poser des SLO et profiler le workload avant de comparer MySQL vs MongoDB
Modèle de données : relationnel (MySQL) vs document (MongoDB) et effets de bord à haute charge
Transactions, cohérence et concurrence : ce que vous payez (vraiment) en prod
Scalabilité : réplication, sharding et failover (sans romantisme)
Indexation, requêtes et moteurs secondaires : là où se gagnent les millisecondes
Sécurité, sauvegardes, observabilité : le coût réel d’une base en charge
Patterns hybrides réalistes (et compatibles avec PrestaShop) : MySQL comme source de vérité, MongoDB comme read model
Checklist de décision pour projets à fort trafic (et pièges classiques)

Fort trafic : poser des SLO et profiler le workload avant de comparer MySQL vs MongoDB

Sur un projet à fort trafic, « choisir une base » sans définir d’objectifs de latence et de débit est une perte de temps. Les métriques minimales à figer dès le départ : QPS/RPS par type d’opération (read vs write), p95/p99 de latence côté API, taille du working set (données réellement chaudes), et taux de miss sur les couches de cache (CDN/Varnish/Redis). En e‑commerce, le profil typique est massivement orienté lecture (listing, navigation, SEO) avec des pointes d’écriture (panier, checkout, stock). Dans ce contexte, la base ne doit pas « tout faire » : elle doit surtout rester prévisible sous contention.

Un point qui évite des débats stériles : formaliser 2–3 SLO “utiles métier” (orientés utilisateur) et les relier à des SLO techniques (orientés DB). Exemple de grille (à adapter à votre stack et à votre marché : France/UE vs international, mobile vs desktop, etc.) :

Parcours / endpoint	Charge typique	Cible p95 (API)	Cible p99 (API)	Remarques d’architecture
Page catégorie (listing)	très read	150–250 ms	300–450 ms	cache CDN + Varnish + index + éventuellement moteur de recherche
Fiche produit	read + un peu de write (tracking)	150–250 ms	300–450 ms	read model dénormalisé possible, cache applicatif
Ajout au panier	write	200–350 ms	450–700 ms	idempotence + verrouillage maîtrisé + éviter “hot document/row”
Checkout (création commande)	write critique	300–600 ms	700–1200 ms	transactions courtes + cohérence forte + observabilité

L’autre erreur fréquente : comparer MySQL vs MongoDB sur une intuition (“NoSQL scale mieux”, “SQL est plus sûr”) au lieu de profiler le workload. Une démarche minimaliste mais efficace, avant tout changement :

activer des slow logs (côté DB) + traces APM (côté API) et tagger les requêtes par “use-case” (listing, product, search, cart, checkout) ;
mesurer la distribution (p50/p95/p99), pas seulement la moyenne ;
isoler le working set (tables/collections réellement “hot”) et vérifier si la RAM couvre ce working set (sinon vous serez I/O bound) ;
vérifier la part de charge absorbée par le cache : un cache “hit” à 90–95% sur le catalogue change complètement le dimensionnement et peut rendre la question “changer de base” inutile à court terme.

MySQL (ou MariaDB) est le choix naturel quand la transaction est au centre : commandes, paiements, réservations de stock, règles de prix. PrestaShop est construit autour de ce postulat : le cœur s’appuie sur un schéma relationnel et un ensemble de requêtes SQL parfois très bavardes, avec des jointures et des agrégations. MongoDB, lui, est pertinent quand le modèle est document, quand on veut réduire les jointures côté base, ou quand la scalabilité horizontale (sharding) doit être « native » et opérable rapidement.

La conséquence pratique : pour un projet à fort trafic, MySQL vs MongoDB n’est pas un duel abstrait, c’est un arbitrage entre cohérence stricte + modèle relationnel (plus simple pour la partie transactionnelle) et modèle document + distribution (souvent plus simple pour des vues de lecture dénormalisées). Si votre enjeu immédiat est la stabilité en production (TTFB, p99, incidents), commencez par optimiser la pile existante (caches, index, requêtes lentes) avant d’envisager un changement de paradigme. Sur PrestaShop, le sujet est couvert côté MySQL/MariaDB ici : Audit MySQL/MariaDB : optimiser les requêtes lentes e‑commerce et côté cache ici : Cache PrestaShop : stratégie 2026 OPcache, Redis, Varnish et CDN.

Modèle de données : relationnel (MySQL) vs document (MongoDB) et effets de bord à haute charge

Le relationnel est performant quand votre modèle est normalisé et que vos requêtes reposent sur des jointures maîtrisées via des index composites. Dans MySQL 8.x / MariaDB 11.x, InnoDB fournit MVCC, index B‑tree, contraintes et transactions ; autrement dit, la base « comprend » la cohérence inter‑tables (FK, unicité, contraintes applicatives).

MongoDB est un moteur document : le document (BSON) est l’unité de stockage, avec des structures imbriquées. Le pitch est aussi sans ambiguïté :

“MongoDB stores data in flexible, JSON-like documents.” — MongoDB Manual

À fort trafic, l’arbitrage « embed vs reference » devient un sujet de performance et de coûts opérationnels. Exemple e‑commerce : un produit avec variantes, prix, attributs, stocks par entrepôt, contenus multi‑langues, règles de TVA. En relationnel, vous aurez des tables (product, productattribute, stockavailable, specific_price…) et des jointures ; en document, vous êtes tenté d’embarquer des sous‑documents (variants[], prices[], stocks[]) pour servir un read model complet en une lecture.

Mais vous payez ailleurs :

documents volumineux : plus de données transférées, plus de cache pressure, plus de coût d’indexation ;
contention : si un même document est modifié très souvent (prix/stock/attributs), vous créez un hotspot ;
duplication : le même attribut ou libellé (ex. une marque, une déclinaison, une règle de livraison) peut se retrouver recopié dans des centaines de milliers de documents ;
évolution de schéma : en SQL, une contrainte et une migration structurent l’évolution ; en document, la cohabitation de versions est courante et doit être gérée explicitement (backfill, “read repair”, versioning).

Ce que les équipes découvrent souvent trop tard : la dénormalisation n’est pas gratuite. Elle augmente la surface d’incohérence, oblige à des pipelines de synchronisation (events, CDC, jobs) et rend les opérations de correction (backfill) plus lourdes. Si vous avez déjà un ERP/PIM qui pousse des updates fréquentes, un modèle document « tout en un » peut se dégrader : vous transformez des petites écritures relationnelles en grosses écritures sur des documents chauds.

Un bon garde-fou, quel que soit le moteur : documenter les “read models” comme des produits (qui les consomme ? quelles garanties de fraîcheur ? quelle tolérance au stale ?). En e‑commerce, on accepte souvent quelques secondes de retard sur un listing SEO, mais beaucoup moins sur :

le stock affiché en fiche produit si vous êtes sur des quantités faibles ;
les règles de prix au moment de l’ajout au panier ;
les états de commande (SAV, expédition, facturation).

Transactions, cohérence et concurrence : ce que vous payez (vraiment) en prod

Pour les flux critiques (commande, paiement, décrément de stock, génération de facture), la question n’est pas « ACID ou pas » mais quel niveau de cohérence sous incident. MySQL/InnoDB a l’avantage de la maturité : transactions multi‑tables, contraintes, niveaux d’isolation, rollback robuste.

“InnoDB is a general-purpose storage engine that balances high reliability and high performance.” — MySQL Reference Manual, InnoDB

MongoDB supporte aussi les transactions multi‑documents (depuis plusieurs versions), mais avec un coût non négligeable quand vous les utilisez intensivement sur un cluster distribué. Le point clé à retenir : dans MongoDB, la transaction est une fonctionnalité à utiliser avec parcimonie quand la distribution (replica set, sharding) et les writeConcern/majority entrent en jeu. La documentation officielle reste claire :

“MongoDB supports multi-document transactions.” — MongoDB Manual, Transactions

Concrètement, si votre application dépend d’une forte atomicité inter‑entités (ex. création commande + lignes + paiements + réservations + logs), MySQL est généralement plus simple à tenir sur la durée, à condition d’optimiser vos transactions (durée courte, index de FK, éviter les scans). À l’inverse, si votre flux critique peut être modélisé en sagas (compensation, outbox, idempotence) et que la cohérence est « orchestrée » côté applicatif, MongoDB devient un candidat crédible.

Mini-scenario (classique en fort trafic) : une promo flash, 50 QPS sur un produit “vedette”, stock réel = 10.

En relationnel, vous pouvez faire un décrément atomique (UPDATE ... SET qty = qty-1 WHERE qty > 0) dans une transaction courte, avec un index efficace, et détecter le “stock épuisé” de façon fiable. Le risque : transaction trop longue (verrou tenu trop longtemps) ou requête non sélective → p99 qui explose.
En document, si stock et panier “vivent” dans le même document produit, vous risquez de concentrer la contention. Si au contraire vous séparez stock dans une collection dédiée, vous retombez sur des patterns proches du relationnel (et donc sur la même discipline : clé d’accès, index, atomicité locale).

À fort trafic, la concurrence est la vraie ennemie : transactions longues, verrous implicites, index manquants, ou hot‑keys. En MySQL, un UPDATE ... WHERE non sélectif peut verrouiller une plage et faire exploser le p99. En MongoDB, un document « hotspot » (ex. un compteur global, ou un panier stocké en un document unique fortement modifié) devient un point de contention. Dans les deux mondes, la discipline est la même : identifier les écritures chaudes, les isoler, et mesurer.

Scalabilité : réplication, sharding et failover (sans romantisme)

Pour beaucoup d’équipes, « fort trafic » veut dire « réplicas de lecture ». MySQL gère très bien le read scaling via réplication (souvent async, parfois semi‑sync), à condition de comprendre le lag et ses effets : lecture stale, incohérences temporaires (ex. panier qui “disparaît” si lu sur un replica). En e‑commerce, c’est acceptable pour des pages SEO/catalogue, mais rarement acceptable pour le checkout. Le pattern classique : writes sur primary, lectures non critiques sur replicas, et caches agressifs.

Une nuance importante en production (surtout si vos visiteurs sont majoritairement en France/Europe et que votre infra est multi‑zone) : la latence réseau intra‑région est faible mais non nulle, et le failover peut modifier brutalement les chemins réseau. Sans runbook clair, vous risquez d’avoir :

un failover qui “passe” mais une application qui pointe encore sur l’ancien nœud ;
un SLA théorique correct, mais un RTO réel mauvais faute de tests de bascule et de restauration.

MongoDB pousse un modèle distribution‑friendly : replica sets (failover automatique) et sharding intégré. C’est un avantage réel quand vous devez répartir un dataset énorme et des writes sur plusieurs nœuds, sans construire un sharding « à la main » côté application. Mais vous échangez du confort de dev contre une discipline ops : choix de la shard key (sinon hotspots), équilibrage, chunk migrations, et impact sur les index. En pratique, le sharding MongoDB se prépare comme une migration : POC, tests de charge, et politique de rollback (y compris un plan “retour en arrière” si la shard key choisie se révèle mauvaise).

MySQL peut aussi se sharder, mais rarement “out of the box” dans des équipes PHP/PrestaShop sans outillage (proxy, Vitess, schémas compatibles, discipline de clé de partition). Ce n’est pas impossible, c’est juste plus coûteux en ingénierie. Si votre applicatif est PrestaShop, gardez en tête une contrainte dure : le core n’est pas conçu pour parler à un cluster sharded ni pour router dynamiquement des requêtes. À ce stade, l’alternative réaliste est souvent : MySQL/MariaDB bien dimensionné + cache + moteur de recherche externe (OpenSearch/Elasticsearch) + éventuellement des read models.

Sur l’aspect exploitation, l’hébergement a un impact massif (IOPS, latence réseau, backups, HA). Si vous visez du HA sans bricolage, faites-vous une idée claire du niveau de service attendu et des procédures (staging, migration à chaud, maintenance) : Hébergement PrestaShop géré : migration sans coupure, staging et maintenance.

Indexation, requêtes et moteurs secondaires : là où se gagnent les millisecondes

Dans MySQL, l’optimisation à fort trafic est très souvent une histoire de : index composites (ordre des colonnes), réduction de cardinalité, suppression de SELECT *, et plan d’exécution stable. Le workflow est connu : EXPLAIN ANALYZE, inspection des scans, et correction. Quand ça ne suffit plus, vous arrivez sur des sujets plus avancés : partitionnement (rarement utile sur OLTP pur), query cache (disparu), mais surtout caches applicatifs et réduction de requêtes (N+1, listes produits trop gourmandes).

Deux points “terrain” qui font souvent gagner du p99 en e‑commerce :

pagination : le LIMIT ... OFFSET ... devient coûteux sur de gros offsets ; dès que possible, passer à une pagination “seek/keyset” (basée sur un dernier identifiant trié) stabilise les temps ;
index couvrants : quand une requête très fréquente peut être servie sans retourner au moteur de stockage (colonnes toutes dans l’index), vous réduisez les I/O et vous gagnez en stabilité.

Dans MongoDB, l’optimisation est tout aussi exigeante : index composés, index partiels, et compréhension du query planner. La différence : vous devez être vigilant sur les opérateurs qui cassent l’index (regex non ancrée, sort sans index compatible) et sur l’impact de l’agrégation (pipeline) qui peut devenir “CPU-bound”. À fort trafic, une règle simple : toute requête exécutée à haute fréquence doit avoir un plan indexé stable, et être tracée (slow query logs/Profiler). Et dans un modèle document, n’oubliez pas la projection : ne retournez que les champs utiles au front (surtout si vos documents deviennent riches).

Pour la recherche et la navigation à facettes (use-case e‑commerce typique), ni MySQL ni MongoDB ne sont le meilleur outil dès que vous avez de la pertinence, du scoring, des facettes combinées et du tri multi‑critères. Vous finissez tôt ou tard avec un moteur dédié. Côté PrestaShop, la réalité est que ps_facetedsearch a ses limites (perf, complexité, risques) et doit être configuré proprement. Si vous externalisez, regardez aussi les contraintes de migration et de snapshot/restore : Elasticsearch managé : migration zéro interruption via snapshot, restore et parallélisation ou l’équivalent OpenSearch : OVHcloud Managed OpenSearch : déploiement, SLA et haute disponibilité 3-AZ.

Sécurité, sauvegardes, observabilité : le coût réel d’une base en charge

À fort trafic, la disponibilité passe par des fondamentaux : TLS obligatoire, comptes à privilèges minimaux, audit des accès, et segmentation réseau. MySQL a un écosystème mature sur ces sujets (roles, auditing, firewalls/proxy, TLS). Si vous voulez un rappel opérationnel côté MySQL/MariaDB (pare-feu, TLS, privilèges, audit), il existe un guide très concret : Sécurité MySQL : pare-feu, TLS, privilèges minimaux et audit.

Le sujet backups est souvent l’endroit où les choix “théoriques” explosent. Sur MySQL/MariaDB, vous devez décider : logical dumps (simples mais lents), backups physiques (plus rapides, PITR via binlogs), et stratégie de restore testée. Sur MongoDB, même combat : sauvegarde cohérente sur replica set/sharded cluster, PITR si possible, et surtout test régulier de restauration (sinon vous avez juste des fichiers). Le point commun : la procédure de restore est plus importante que l’outil.

Une façon pragmatique de cadrer le débat (et d’éviter le “on fera des backups plus tard”) : écrire noir sur blanc vos objectifs RPO/RTO et les vérifier en exercice.

Objectif	Question	Exemple réaliste en e‑commerce
RPO (perte de données tolérée)	“Combien de minutes de commandes puis-je perdre ?”	0–5 min (souvent proche de 0 sur commande/paiement)
RTO (temps de reprise)	“Combien de temps puis-je être indisponible ?”	15–60 min selon maturité et budget HA
Fréquence de tests	“À quelle fréquence je restaure vraiment ?”	mensuel/trimestriel (au minimum)

Enfin, l’observabilité n’est pas optionnelle. Vous devez voir : saturation CPU, IO wait, hit ratio buffer pool/cache, locks, temps de commit, replication lag, et erreurs applicatives. Les équipes PrestaShop qui montent en charge gagnent du temps avec une solution de monitoring capable d’absorber Prometheus/SNMP/StatsD et de corréler infra + applicatif : Netdata : intégrer Prometheus, SNMP et StatsD pour tout surveiller. Sans ça, MySQL vs MongoDB devient un débat d’opinion.

Patterns hybrides réalistes (et compatibles avec PrestaShop) : MySQL comme source de vérité, MongoDB comme read model

Si vous travaillez sur PrestaShop 9.x (PHP 8.3) ou un projet PHP e‑commerce proche, il faut être clair : remplacer MySQL par MongoDB n’est pas un simple swap de driver. Le cœur, les modules, et l’écosystème s’attendent à du SQL, des transactions et un schéma relationnel. Dans ce cadre, le pattern raisonnable est hybride : MySQL/MariaDB reste la source de vérité transactionnelle, et MongoDB sert des vues de lecture optimisées (catalogue dénormalisé, pages de contenu enrichies, profils, tracking événementiel), ou un stockage de documents métier (exports, snapshots de panier).

Le pattern qui fonctionne bien en fort trafic : write in MySQL → event/outbox → projection dans MongoDB. Vous publiez un événement “ProductUpdated”, “StockChanged”, “PriceRuleChanged”, puis vous mettez à jour un document prêt à servir côté front/API. La projection doit être idempotente, rejouable (backfill), et versionnée (schema evolution).

Quelques règles simples pour que ce pattern reste “opérable” :

outbox transactionnelle : l’écriture de l’événement est atomique avec l’écriture métier (sinon vous perdez des événements) ;
consommateur idempotent : retraiter deux fois le même événement ne doit pas casser l’état ;
backfill outillé : si vous changez le schéma du read model, vous devez pouvoir reconstruire (par lot) sans impacter la prod ;
SLO de fraîcheur : par exemple “stock et prix propagés en < 2 secondes p95”, mesuré et alerté.

Ce pattern est souvent couplé à une file (RabbitMQ/Kafka) et à une intégration SI plus large ; si vous êtes déjà dans ces problématiques (ERP, webhooks, files), vous pouvez vous appuyer sur : Intégration ERP e‑commerce : architecture API, webhooks et files RabbitMQ.

L’autre pattern pragmatique : MongoDB pour des données “non critiques” et à forte volumétrie (logs applicatifs structurés, tracking, sessions si vous n’avez pas Redis), tout en évitant de l’utiliser pour ce qui demande de la cohérence forte. Pour les sessions, Redis est souvent plus simple et plus performant ; et pour la recherche, OpenSearch/Elasticsearch reste le choix standard. MongoDB devient alors un composant spécialisé, pas un remplacement.

Checklist de décision pour projets à fort trafic (et pièges classiques)

Si vous devez trancher MySQL vs MongoDB, forcez une réponse écrite à ces questions, sinon vous allez “choisir” sur des préférences d’équipe. (1) Votre modèle impose-t-il des jointures complexes et une cohérence inter‑entités forte ? (2) Quel est le ratio read/write et quelle est la part de requêtes analytiques vs OLTP ? (3) Avez-vous besoin de sharding dès J1 ou vous pouvez scaler verticalement + caches + replicas ? (4) Quelle est la tolérance à la cohérence éventuelle ? (5) Quelle est votre maturité ops (backup, restore, monitoring, on-call) ?

Une matrice rapide (à utiliser comme support de décision, pas comme vérité absolue) :

Critère	Favorise MySQL/MariaDB	Favorise MongoDB
Checkout / finance / stock strict	Transactions et contraintes natives	Possible, mais plus coûteux si transactions multi-doc fréquentes
Catalogue “lecture” très riche	OK, mais risque de jointures/agrégations lourdes	Read models dénormalisés plus naturels
Sharding natif exigé	Sharding possible mais plus d’ingénierie	Sharding intégré, mais shard key critique
Écosystème PrestaShop	Aligné (core + modules)	Fort décalage (intégration plus spécifique)
Tolérance au stale	À gérer via replicas/caches	S’intègre bien dans une approche CQRS/read model

Les pièges MySQL les plus fréquents en e‑commerce : index manquants sur tables de liaison, transactions trop longues, “feature” ajoutée via triggers sans contrôle de perf, et absence de tests de restore. Si vous utilisez des triggers pour automatiser la cohérence, faites-le en connaissant le coût sous charge et les risques de verrouillage : Triggers MySQL : automatiser la cohérence des données en production. Autre piège : penser que “un gros serveur” suffira ; à fort trafic, la dette de requêtes s’accumule et finit en incident.

Les pièges MongoDB les plus fréquents : mauvaise shard key (hot partitions), dénormalisation non maîtrisée, index insuffisants, et utilisation trop large des transactions multi‑documents “par confort” (ce qui annule une partie des bénéfices de distribution). Si vous êtes dans un contexte PrestaShop, le piège supplémentaire est organisationnel : vous sortez du chemin supportable par la majorité des modules et des intégrateurs. La décision devient un engagement long terme (outillage, formation, runbooks, CI de migrations).

Au final, pour des projets à fort trafic, la règle empirique est simple : MySQL/MariaDB gagne quand la transaction et la cohérence dominent (checkout, stock, finance), MongoDB gagne quand le read model document et la distribution sont au cœur (contenu, événements, vues agrégées, multi-tenant document). Et quand vous avez les deux, la solution robuste n’est pas “l’un ou l’autre”, c’est souvent une architecture où chaque moteur fait ce qu’il sait faire, avec des contrats de données clairs, des objectifs SLO mesurés, et des procédures de restauration réellement testées.