3 min de lecture<\/p>\n
Le paysage des bases de donn\u00e9es dans le cloud a radicalement \u00e9volu\u00e9. Aujourd\u2019hui, choisir une base de donn\u00e9es ne signifie plus seulement trancher entre SQL et NoSQL. Les bases de donn\u00e9es serverless, les solutions NewSQL, les moteurs multi-mod\u00e8les et les bases de donn\u00e9es \u00ab purpose-built \u00bb offrent chacune la solution optimale pour un mod\u00e8le d\u2019acc\u00e8s sp\u00e9cifique. Le d\u00e9fi n\u2019est plus le manque d\u2019options – mais bien le choix judicieux parmi celles-ci.<\/strong><\/p>\n Les bases de donn\u00e9es g\u00e9r\u00e9es<\/strong>, telles qu\u2019Amazon RDS, Azure SQL Database et Google Cloud SQL, prennent en charge le patching<\/em>, les sauvegardes et le basculement (failover<\/em>). La taille de l\u2019instance est choisie manuellement, ou ajust\u00e9e via un auto-scaling<\/em>. Les efforts op\u00e9rationnels diminuent d\u2019environ 80 % par rapport \u00e0 une solution auto-h\u00e9berg\u00e9e – tout en conservant un contr\u00f4le total sur la configuration et le tuning<\/em> des performances.<\/p>\n Les bases de donn\u00e9es serverless<\/strong> vont encore plus loin : aucune s\u00e9lection d\u2019instance, aucune planification de capacit\u00e9. Aurora Serverless v2, Neon (PostgreSQL serverless) et PlanetScale (MySQL serverless) s\u2019adaptent automatiquement – y compris la mise \u00e0 l\u2019\u00e9chelle jusqu\u2019\u00e0 z\u00e9ro (scale-to-zero<\/em>) pour les environnements de d\u00e9veloppement. On ne paie que pour l\u2019utilisation r\u00e9elle. Pour les charges de travail variables et les configurations de d\u00e9veloppement, c\u2019est un v\u00e9ritable changement de paradigme.<\/p>\n Les bases de donn\u00e9es relationnelles (SQL)<\/strong> restent la r\u00e9f\u00e9rence pour les charges de travail transactionnelles impliquant des relations complexes : e-commerce, ERP, syst\u00e8mes financiers. PostgreSQL et MySQL dominent ce segment, tous deux disponibles sous forme de services g\u00e9r\u00e9s chez tous les hyperscalers.<\/p>\n Les bases de donn\u00e9es NoSQL<\/strong> conviennent \u00e0 des mod\u00e8les d\u2019acc\u00e8s sp\u00e9cifiques : DynamoDB pour les acc\u00e8s cl\u00e9-valeur et les requ\u00eates simples avec latence garantie ; MongoDB Atlas pour les charges de travail bas\u00e9es sur des documents et dot\u00e9es d\u2019un sch\u00e9ma flexible ; Redis pour la mise en cache et la gestion des sessions ; Cassandra\/ScyllaDB pour les charges de travail fortement orient\u00e9es \u00e9criture (Write-Heavy<\/em>) avec un d\u00e9bit extr\u00eame.<\/p>\n Les bases de donn\u00e9es NewSQL<\/strong> combinent des transactions ACID avec une mont\u00e9e en charge horizontale : Google Spanner offre une coh\u00e9rence globale \u00e0 travers les continents ; CockroachDB fournit une compatibilit\u00e9 PostgreSQL avec un sharding<\/em> automatique ; TiDB permet une mont\u00e9e en charge horizontale de MySQL. Leur cible : les applications qui ont besoin des deux – s\u00e9curit\u00e9 transactionnelle et<\/em> mont\u00e9e en charge massive.<\/p>\n AWS promeut depuis des ann\u00e9es le concept de \u00ab bases de donn\u00e9es purpose-built \u00bb – soit une motorisation optimale pour chaque type d\u2019acc\u00e8s aux donn\u00e9es. Ce principe est valide : une base de donn\u00e9es graphique (Neptune, Neo4j) mod\u00e9lise naturellement les r\u00e9seaux de relations, bien mieux qu\u2019un JOIN<\/em> SQL sur cinq tables. Une base de donn\u00e9es temporelle (TimescaleDB, InfluxDB) compresse et agr\u00e8ge les donn\u00e9es IoT bien plus efficacement que PostgreSQL.<\/p>\n L\u2019inconv\u00e9nient ? Chaque moteur suppl\u00e9mentaire augmente la complexit\u00e9 op\u00e9rationnelle. Notre recommandation : d\u00e9marrer avec PostgreSQL (qui couvre 80 % des cas d\u2019usage), et n\u2019introduire une base sp\u00e9cialis\u00e9e que lorsque PostgreSQL atteint des limites prouv\u00e9es.<\/p>\n Pour les applications critiques m\u00e9tiers, une architecture mono-r\u00e9gion constitue un risque : les pannes r\u00e9gionales surviennent rarement, mais elles surviennent bel et bien. La r\u00e9plication multi-r\u00e9gion distribue les donn\u00e9es sur plusieurs zones g\u00e9ographiques et permet un basculement (failover<\/em>) en quelques secondes.<\/p>\n Les co\u00fbts sont significatifs : transfert de donn\u00e9es inter-r\u00e9gions, ressources de calcul dans plusieurs r\u00e9gions, et complexit\u00e9 accrue de la r\u00e9solution des conflits (conflict resolution<\/em>) dans les configurations multi-writer<\/em>. Pour les charges de travail fortement orient\u00e9es lecture (Read-Heavy<\/em>), les r\u00e9pliques de lecture (Read Replicas<\/em>) dans d\u2019autres r\u00e9gions constituent un compromis pragmatique – moins co\u00fbteux et moins complexe qu\u2019une architecture Active-Active<\/em> multi-r\u00e9gion compl\u00e8te.<\/p>\n Les migrations de bases de donn\u00e9es constituent la phase la plus risqu\u00e9e de tout projet cloud. AWS DMS, Azure Database Migration Service et GCP Database Migration Service proposent des services de migration g\u00e9r\u00e9s avec une indisponibilit\u00e9 minimale. Le processus standard consiste en une r\u00e9plication continue depuis le syst\u00e8me source, suivie d\u2019un basculement (switchover<\/em>) dans une fen\u00eatre de maintenance courte, avec une option de retour arri\u00e8re (fallback<\/em>) valable pendant 48 \u00e0 72 heures.<\/p>\n Facteurs critiques de r\u00e9ussite : v\u00e9rifier au pr\u00e9alable la compatibilit\u00e9 des sch\u00e9mas (notamment lors d\u2019un changement de moteur), r\u00e9aliser des tests de performance sous charge r\u00e9elle, et disposer d\u2019un plan de retour arri\u00e8re ex\u00e9cutable en moins de 30 minutes.<\/p>\n PostgreSQL sur un service g\u00e9r\u00e9 (Neon Serverless ou Supabase pour un d\u00e9marrage rapide, RDS\/Cloud SQL pour un contr\u00f4le accru). PostgreSQL prend en charge \u00e0 la fois les charges de travail relationnelles et JSON, b\u00e9n\u00e9ficie d\u2019une communaut\u00e9 immense et monte en charge jusqu\u2019\u00e0 des volumes importants. Seules des exigences tr\u00e8s sp\u00e9cifiques (par exemple, 100 000 \u00e9critures\/seconde) justifient l\u2019\u00e9valuation d\u2019un moteur sp\u00e9cialis\u00e9.<\/p>\n<\/details>\n Les services g\u00e9r\u00e9s co\u00fbtent 20 \u00e0 40 % plus cher que les co\u00fbts purs de calcul et de stockage d\u2019une instance auto-h\u00e9berg\u00e9e. Cet \u00e9cart est largement compens\u00e9 par la r\u00e9duction des efforts op\u00e9rationnels (patching<\/em>, sauvegardes, surveillance, failover<\/em>). Un administrateur de base de donn\u00e9es (DBA) co\u00fbte 80 000 \u00e0 120 000 \u20ac\/an – tandis que les services g\u00e9r\u00e9s pour une base de donn\u00e9es de production typique se situent entre 300 et 1 000 \u20ac\/mois.<\/p>\n<\/details>\n Les bases de donn\u00e9es serverless sont id\u00e9ales pour les charges de travail variables (environnements de d\u00e9veloppement et de test, SaaS avec une charge impr\u00e9visible) et les sc\u00e9narios n\u00e9cessitant une mise \u00e0 l\u2019\u00e9chelle jusqu\u2019\u00e0 z\u00e9ro (scale-to-zero<\/em>). Pour des charges stables et \u00e9lev\u00e9es, les instances provisionn\u00e9es sont plus \u00e9conomiques, car la tarification serverless devient plus ch\u00e8re que celle des instances r\u00e9serv\u00e9es (Reserved Instances<\/em>) en cas de charge constante.<\/p>\n<\/details>\n Presque. PostgreSQL prend en charge les donn\u00e9es relationnelles, le format JSON (JSONB), la recherche plein texte, les donn\u00e9es g\u00e9ographiques (PostGIS), les s\u00e9ries temporelles (extension TimescaleDB) et m\u00eame la recherche vectorielle (pgvector). Elle suffit pour 80 % des cas d\u2019usage. Ses limites apparaissent face \u00e0 des exigences de latence extr\u00eamement faible (< 5 ms), \u00e0 des d\u00e9bits d\u2019\u00e9criture tr\u00e8s \u00e9lev\u00e9s (> 50 000 \u00e9critures\/seconde) et \u00e0 la r\u00e9plication globale avec coh\u00e9rence forte.<\/p>\n<\/details>\n Gr\u00e2ce \u00e0 la r\u00e9plication continue : la base de donn\u00e9es source est r\u00e9pliqu\u00e9e en continu vers la cible cloud en production. Lorsque la r\u00e9plication est synchronis\u00e9e (retard lag<\/em> < 1 seconde), le basculement peut \u00eatre effectu\u00e9 sans interruption notable. Le d\u00e9lai de basculement d\u00e9pend de la taille du jeu de donn\u00e9es et de la bande passante disponible. Une strat\u00e9gie robuste inclut toujours un plan de retour arri\u00e8re test\u00e9 et valid\u00e9.<\/p>\n<\/details>\n Source de l’image : Pexels \/ Brett Sayles<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<\/span>G\u00e9r\u00e9es vs. Serverless : deux niveaux d\u2019abstraction<\/h2>\n
SQL, NoSQL ou NewSQL ? La matrice d\u00e9cisionnelle<\/h2>\n
Bases de donn\u00e9es \u00ab purpose-built \u00bb : le bon outil pour chaque besoin<\/h2>\n
R\u00e9plication multi-r\u00e9gion : la disponibilit\u00e9 a un prix<\/h2>\n
Migration : la voie s\u00fbre vers la base de donn\u00e9es cloud<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Quelle base de donn\u00e9es cloud convient aux startups ?<\/strong><\/summary>\n
Quel est le co\u00fbt d\u2019une base de donn\u00e9es g\u00e9r\u00e9e compar\u00e9 \u00e0 une solution auto-h\u00e9berg\u00e9e ?<\/strong><\/summary>\n
\u00c0 quel moment une base de donn\u00e9es serverless devient-elle pertinente ?<\/strong><\/summary>\n
Peut-on utiliser PostgreSQL pour tout ?<\/strong><\/summary>\n
Comment minimiser les temps d\u2019indisponibilit\u00e9 lors d\u2019une migration de base de donn\u00e9es ?<\/strong><\/summary>\n