{"id":15719,"date":"2025-12-01T15:07:49","date_gmt":"2025-12-01T14:07:49","guid":{"rendered":"https:\/\/webhosting.de\/datenbank-sharding-replikation-webhosting-infrastruktur-skalierbar\/"},"modified":"2025-12-01T15:07:49","modified_gmt":"2025-12-01T14:07:49","slug":"base-de-donnees-partitionnement-replication-hebergement-web-infrastructure-evolutive","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/datenbank-sharding-replikation-webhosting-infrastruktur-skalierbar\/","title":{"rendered":"Partitionnement et r\u00e9plication de bases de donn\u00e9es : quand leur utilisation est-elle int\u00e9ressante dans le domaine de l'h\u00e9bergement web ?"},"content":{"rendered":"<p>Je montre quand <strong>h\u00e9bergement de partitionnement de base de donn\u00e9es<\/strong> quand l'h\u00e9bergement web apporte une v\u00e9ritable \u00e9volutivit\u00e9 et quand <strong>R\u00e9plication<\/strong> d\u00e9j\u00e0 atteint tous les objectifs. Je d\u00e9finis des seuils concrets pour le volume de donn\u00e9es, le rapport lecture\/\u00e9criture et la disponibilit\u00e9 afin de pouvoir choisir en toute s\u00e9curit\u00e9 l'architecture appropri\u00e9e.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Je vais r\u00e9sumer bri\u00e8vement les d\u00e9cisions les plus importantes avant d'entrer dans les d\u00e9tails.<\/p>\n<ul>\n  <li><strong>R\u00e9plication<\/strong> Augmente la disponibilit\u00e9 et les performances en lecture, mais reste limit\u00e9 en \u00e9criture.<\/li>\n  <li><strong>Sharding<\/strong> r\u00e9partit les donn\u00e9es horizontalement et adapte la lecture et l'\u00e9criture.<\/li>\n  <li><strong>Hybride<\/strong> Combine les fragments avec des r\u00e9pliques par fragment pour assurer la r\u00e9silience.<\/li>\n  <li><strong>Seuils<\/strong>: forte croissance des donn\u00e9es, parall\u00e9lisme \u00e9lev\u00e9, limites de m\u00e9moire par serveur.<\/li>\n  <li><strong>Co\u00fbts<\/strong> d\u00e9pendent du fonctionnement, de la conception des requ\u00eates et de l'observabilit\u00e9.<\/li>\n<\/ul>\n<p>Ces points m'aident \u00e0 \u00e9tablir des priorit\u00e9s et \u00e0 r\u00e9duire les risques. Je commence par <strong>R\u00e9plication<\/strong>, d\u00e8s que la disponibilit\u00e9 devient importante. En cas de pression continue sur le CPU, la RAM ou les E\/S, je planifie <strong>Sharding<\/strong>. Dans de nombreux cas, une configuration hybride offre le meilleur compromis entre \u00e9volutivit\u00e9 et fiabilit\u00e9. Cela me permet de conserver une architecture claire, facile \u00e0 entretenir et performante.<\/p>\n\n<h2>R\u00e9plication dans l'h\u00e9bergement web : court et clair<\/h2>\n<p>J'utilise <strong>R\u00e9plication<\/strong>, pour conserver des copies de la m\u00eame base de donn\u00e9es sur plusieurs n\u0153uds. Un n\u0153ud principal accepte les op\u00e9rations d'\u00e9criture, tandis que les n\u0153uds secondaires fournissent un acc\u00e8s rapide en lecture. Cela r\u00e9duit consid\u00e9rablement les latences pour les rapports, les flux et les catalogues de produits. Pour les maintenances planifi\u00e9es, je passe de mani\u00e8re cibl\u00e9e \u00e0 une r\u00e9plique et assure ainsi la <strong>Disponibilit\u00e9<\/strong>. Si un n\u0153ud tombe en panne, un autre prend le relais en quelques secondes et les utilisateurs restent connect\u00e9s.<\/p>\n<p>Je distingue deux modes avec des cons\u00e9quences claires. Ma\u00eetre-esclave augmente la <strong>performance de lecture<\/strong>, mais limite la capacit\u00e9 d'\u00e9criture au n\u0153ud principal. Le mode multi-ma\u00eetre r\u00e9partit les \u00e9critures, mais n\u00e9cessite des r\u00e8gles de conflit strictes et des horodatages pr\u00e9cis. Sans une bonne surveillance, je risque des retards dans les journaux de r\u00e9plication. Gr\u00e2ce \u00e0 des param\u00e8tres de validation correctement d\u00e9finis, je contr\u00f4le consciemment la coh\u00e9rence par rapport \u00e0 la latence.<\/p>\n\n<h2>Le sharding expliqu\u00e9 de mani\u00e8re compr\u00e9hensible<\/h2>\n<p>Je partage sur <strong>Sharding<\/strong> les donn\u00e9es horizontalement en fragments, de sorte que chaque n\u0153ud ne contienne qu'une partie du stock. Cela me permet de faire \u00e9voluer simultan\u00e9ment les acc\u00e8s en \u00e9criture et en lecture, car les requ\u00eates sont envoy\u00e9es \u00e0 plusieurs n\u0153uds. Une couche de routage achemine les requ\u00eates vers le fragment appropri\u00e9 et r\u00e9duit la charge par instance. Cela me permet d'\u00e9viter les limites de m\u00e9moire et d'E\/S d'un seul <strong>Serveurs<\/strong>. Si le volume de donn\u00e9es augmente, j'ajoute des shards au lieu d'acheter des machines toujours plus puissantes.<\/p>\n<p>Je choisis la strat\u00e9gie de partitionnement adapt\u00e9e au mod\u00e8le de donn\u00e9es. Le partitionnement hach\u00e9 r\u00e9partit les cl\u00e9s de mani\u00e8re uniforme et prot\u00e8ge contre les points chauds. Le partitionnement par plage facilite les requ\u00eates par plage, mais peut entra\u00eener des points chauds dans les plages \u201e chaudes \u201c. <strong>d\u00e9s\u00e9quilibre<\/strong> . Le partitionnement de r\u00e9pertoire utilise une table de mappage et offre une flexibilit\u00e9 maximale au prix d'une gestion suppl\u00e9mentaire. Une cl\u00e9 claire et de bonnes m\u00e9triques permettent d'\u00e9viter des re-partitionnements co\u00fbteux par la suite.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/datenbank-sharding-webhosting-9374.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quand la r\u00e9plication est-elle utile ?<\/h2>\n<p>Je mets <strong>R\u00e9plication<\/strong> lorsque les acc\u00e8s en lecture pr\u00e9dominent et que les donn\u00e9es doivent rester hautement disponibles. Les blogs, les portails d'actualit\u00e9s et les pages produits en b\u00e9n\u00e9ficient, car de nombreux utilisateurs lisent et peu \u00e9crivent. J'exige que les donn\u00e9es de facturation ou les donn\u00e9es des patients soient conserv\u00e9es de mani\u00e8re redondante. Pour la maintenance et les mises \u00e0 jour, je maintiens les temps d'arr\u00eat aussi proches que possible de z\u00e9ro. Ce n'est que lorsque la file d'attente d'\u00e9criture sur le ma\u00eetre augmente que je recherche des alternatives.<\/p>\n<p>Je v\u00e9rifie au pr\u00e9alable quelques signaux importants. Les latences d'\u00e9criture d\u00e9passent mes objectifs de service. Les retards de r\u00e9plication s'accumulent pendant les pics de charge. Les charges de lecture surchargent certaines r\u00e9pliques malgr\u00e9 la mise en cache. Dans de tels cas, j'optimise les requ\u00eates et les index, par exemple avec une <a href=\"https:\/\/webhosting.de\/fr\/optimisation-de-la-base-de-donnees-charges-elevees-guide-de-performance\/\">Optimisation de la base de donn\u00e9es<\/a>. Si ces mesures ne sont que temporairement efficaces, je pr\u00e9vois de passer aux shards.<\/p>\n\n<h2>Quand le sharding devient n\u00e9cessaire<\/h2>\n<p>Je choisis <strong>Sharding<\/strong>, d\u00e8s qu'un seul serveur ne peut plus supporter la quantit\u00e9 de donn\u00e9es. Cela vaut \u00e9galement lorsque le CPU, la RAM ou le stockage fonctionnent en permanence \u00e0 la limite de leurs capacit\u00e9s. Un parall\u00e9lisme \u00e9lev\u00e9 en lecture et en \u00e9criture n\u00e9cessite une r\u00e9partition horizontale. Les charges transactionnelles avec de nombreuses sessions simultan\u00e9es n\u00e9cessitent plusieurs <strong>Instances<\/strong>. Seul le sharding supprime r\u00e9ellement les limites strictes en mati\u00e8re d'\u00e9criture.<\/p>\n<p>J'observe les d\u00e9clencheurs typiques pendant plusieurs semaines. La croissance quotidienne des donn\u00e9es impose des mises \u00e0 niveau verticales fr\u00e9quentes. Les fen\u00eatres de maintenance deviennent trop courtes pour les r\u00e9indexations n\u00e9cessaires. Les sauvegardes prennent trop de temps, les d\u00e9lais de restauration ne r\u00e9pondent plus aux objectifs. Si deux ou trois de ces facteurs sont r\u00e9unis, je planifie pratiquement imm\u00e9diatement l'architecture de partitionnement.<\/p>\n\n<h2>Comparaison des strat\u00e9gies de partitionnement<\/h2>\n<p>Je choisis d\u00e9lib\u00e9r\u00e9ment la cl\u00e9, car elle d\u00e9termine <strong>Mise \u00e0 l'\u00e9chelle<\/strong> et les points d'acc\u00e8s. Le partitionnement par hachage offre la meilleure r\u00e9partition \u00e9quitable pour les identifiants utilisateur et les num\u00e9ros de commande. Le partitionnement par plage convient aux axes temporels et aux rapports tri\u00e9s, mais n\u00e9cessite un r\u00e9\u00e9quilibrage en cas de changements de tendance. Le partitionnement par r\u00e9pertoire r\u00e9sout les cas particuliers, mais entra\u00eene une charge suppl\u00e9mentaire. <strong>Recherche<\/strong>. Pour les charges mixtes, je combine le hachage pour une r\u00e9partition uniforme et la plage au sein d'un fragment pour les rapports.<\/p>\n<p>Je pr\u00e9vois le re-sharding d\u00e8s le premier jour. Un hachage coh\u00e9rent avec sharding virtuel r\u00e9duit les d\u00e9placements. Les m\u00e9triques par shard indiquent rapidement les surcharges. Les tests avec des cl\u00e9s r\u00e9alistes r\u00e9v\u00e8lent les cas limites. Je peux ainsi calculer la restructuration pendant le fonctionnement.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/sharding_replikation_meeting_4198.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Combinaison : partitionnement + r\u00e9plication<\/h2>\n<p>Je combine <strong>Sharding<\/strong> pour la mise \u00e0 l'\u00e9chelle avec r\u00e9plication dans chaque fragment pour la r\u00e9silience. Si un n\u0153ud tombe en panne, la r\u00e9plique du m\u00eame fragment prend le relais. Les perturbations globales n'affectent ainsi qu'une partie des utilisateurs au lieu de tous. Je r\u00e9partis \u00e9galement les charges de lecture sur les r\u00e9pliques, augmentant ainsi la <strong>D\u00e9bit<\/strong>-R\u00e9serves. Cette architecture convient aux boutiques, aux plateformes d'apprentissage et aux applications sociales.<\/p>\n<p>Je d\u00e9finis des SLO clairs pour chaque fragment. Les objectifs de r\u00e9cup\u00e9ration par classe de donn\u00e9es \u00e9vitent les conflits en cas d'urgence. Le basculement automatis\u00e9 \u00e9vite les erreurs humaines dans les moments critiques. Les sauvegardes s'ex\u00e9cutent plus rapidement pour chaque fragment et permettent des restaurations parall\u00e8les. Cela r\u00e9duit les risques et garantit des d\u00e9lais pr\u00e9visibles pendant le fonctionnement.<\/p>\n\n<h2>Co\u00fbts et exploitation \u2013 r\u00e9alistes<\/h2>\n<p>Je calcule <strong>Co\u00fbts<\/strong> non seulement dans le mat\u00e9riel, mais aussi dans l'exploitation, la surveillance et l'assistance t\u00e9l\u00e9phonique. La r\u00e9plication facilite la mise en \u0153uvre, mais entra\u00eene des co\u00fbts de stockage plus \u00e9lev\u00e9s en raison des copies. Le partitionnement r\u00e9duit la m\u00e9moire par n\u0153ud, mais augmente le nombre de n\u0153uds et les co\u00fbts d'exploitation. Une bonne observabilit\u00e9 \u00e9vite les erreurs en cas de retards de r\u00e9plication ou de points chauds de partitionnement. Un tableau sobre r\u00e9sume les cons\u00e9quences.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Crit\u00e8re<\/th>\n      <th>R\u00e9plication<\/th>\n      <th>Sharding<\/th>\n      <th>Impact sur l'h\u00e9bergement web<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>\u00c9crire<\/strong><\/td>\n      <td>Peu \u00e9volutif, ma\u00eetre limit\u00e9<\/td>\n      <td>\u00c9volutivit\u00e9 horizontale via des fragments<\/td>\n      <td>Le sharding \u00e9limine les goulots d'\u00e9tranglement en \u00e9criture<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Lire<\/strong><\/td>\n      <td>Bonne \u00e9volutivit\u00e9 via les r\u00e9pliques<\/td>\n      <td>Bonne \u00e9volutivit\u00e9 par fragment et r\u00e9plique<\/td>\n      <td>Flux rapides, rapports, caches<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>M\u00e9moire<\/strong><\/td>\n      <td>Plus de copies = plus de co\u00fbts<\/td>\n      <td>Donn\u00e9es r\u00e9parties, moins par n\u0153ud<\/td>\n      <td>Le montant mensuel en \u20ac diminue par instance<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Complexit\u00e9<\/strong><\/td>\n      <td>Facilit\u00e9 d'utilisation<\/td>\n      <td>Plus de n\u0153uds, conception des cl\u00e9s importante<\/td>\n      <td>Une automatisation accrue est n\u00e9cessaire<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Tol\u00e9rance aux erreurs<\/strong><\/td>\n      <td>Basculement rapide<\/td>\n      <td>Erreur isol\u00e9e, sous-ensemble d'utilisateurs concern\u00e9s<\/td>\n      <td>L'hybride offre le meilleur \u00e9quilibre<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Je fixe des seuils en euros par demande, pas seulement par <strong>Serveur<\/strong>. Si le prix par 1 000 requ\u00eates diminue sensiblement, cette mesure est rentable. Si des n\u0153uds suppl\u00e9mentaires augmentent la charge d'astreinte, je compense cela par l'automatisation. Ainsi, l'architecture reste \u00e9conomique, et pas seulement techniquement propre. Des co\u00fbts clairs par niveau de trafic \u00e9vitent les surprises ult\u00e9rieures.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/datenbank-sharding-replikation-7384.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Migration vers les shards : une approche par \u00e9tapes<\/h2>\n<p>Je vais \u00e0 <strong>\u00c9tapes<\/strong> au lieu de d\u00e9couper la base de donn\u00e9es pendant la nuit. Je commence par nettoyer le sch\u00e9ma, les index et les requ\u00eates. Ensuite, j'introduis un routage via une couche de service neutre. Puis, je transf\u00e8re les donn\u00e9es par lots vers de nouveaux shards. Pour finir, je change le chemin d'\u00e9criture et observe les latences.<\/p>\n<p>J'\u00e9vite les pi\u00e8ges gr\u00e2ce \u00e0 un plan solide. Un bon mod\u00e8le de donn\u00e9es s'av\u00e8re tr\u00e8s rentable par la suite. Un aper\u00e7u des \u00e9l\u00e9ments suivants me fournit une base d\u00e9cisionnelle utile <a href=\"https:\/\/webhosting.de\/fr\/sql-vs-nosql-bases-de-donnees-comparaison-hebergement-web-mise-a-lechelle\/\">SQL vs NoSQL<\/a>. Certaines charges de travail b\u00e9n\u00e9ficient d'un stockage bas\u00e9 sur des documents, d'autres de contraintes relationnelles. Je choisis ce qui soutient r\u00e9ellement les mod\u00e8les de requ\u00eate et le savoir-faire de l'\u00e9quipe.<\/p>\n\n<h2>Surveillance, SLO et tests<\/h2>\n<p>Je d\u00e9finis <strong>SLOs<\/strong> pour la latence, le taux d'erreur et le d\u00e9calage de r\u00e9plication. Les tableaux de bord affichent \u00e0 la fois la vue cluster et la vue shard. Les alarmes se d\u00e9clenchent en fonction de la tendance, et non pas seulement en cas de panne totale. Des tests de charge proches de la production valident les objectifs. Des exercices de chaos r\u00e9v\u00e8lent les faiblesses du basculement.<\/p>\n<p>Je mesure chaque goulot d'\u00e9tranglement en chiffres. Les taux d'\u00e9criture, les verrous et les longueurs de file d'attente indiquent les risques \u00e0 un stade pr\u00e9coce. Les plans de requ\u00eate r\u00e9v\u00e8lent les lacunes. <strong>Indices<\/strong>. Je teste r\u00e9guli\u00e8rement et \u00e0 intervalles pr\u00e9cis les sauvegardes et les restaurations. Sans cette discipline, la mise \u00e0 l'\u00e9chelle reste un v\u0153u pieux.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/sharding_replikation_techoffice_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sc\u00e9narios pratiques selon le trafic<\/h2>\n<p>Je classe les projets selon <strong>Niveau<\/strong> Jusqu'\u00e0 environ quelques milliers de visiteurs par jour : la r\u00e9plication et la mise en cache suffisent dans la plupart des cas. Entre dix mille et cent mille : r\u00e9plication avec davantage de n\u0153uds de lecture et optimisation des requ\u00eates, ainsi qu'un premier partitionnement. Au-del\u00e0 : planifier le partitionnement, identifier les points chauds d'\u00e9criture, mettre en place une couche de routage. \u00c0 partir de plusieurs millions : configuration hybride avec des shards et deux r\u00e9plicas par shard, avec basculement automatique.<\/p>\n<p>Je proc\u00e8de par petites \u00e9tapes dans le processus de migration. Chaque \u00e9tape r\u00e9duit les risques et la pression temporelle. Le budget et la taille de l'\u00e9quipe d\u00e9terminent le rythme et <strong>Automatisation<\/strong>. Les phases de gel des fonctionnalit\u00e9s prot\u00e8gent la restructuration. Des \u00e9tapes claires garantissent des progr\u00e8s fiables.<\/p>\n\n<h2>Cas particulier des donn\u00e9es chronologiques<\/h2>\n<p>Je traite <strong>s\u00e9ries chronologiques<\/strong> s\u00e9par\u00e9ment, car elles ne cessent de cro\u00eetre et sont tr\u00e8s volumineuses. Le partitionnement par fen\u00eatres temporelles all\u00e8ge les index et les sauvegardes. La compression permet d'\u00e9conomiser de l'espace de stockage et des E\/S. Pour les m\u00e9triques, les capteurs et les journaux, il est int\u00e9ressant d'utiliser un moteur capable de traiter nativement les s\u00e9ries chronologiques. Un bon point de d\u00e9part est fourni par <a href=\"https:\/\/webhosting.de\/fr\/timescaledb-gestion-des-donnees-de-series-chronologiques-hebergement-web\/\">Donn\u00e9es chronologiques TimescaleDB<\/a> avec gestion automatique des chunks.<\/p>\n<p>Je combine le partitionnement par plage par p\u00e9riode avec des cl\u00e9s hach\u00e9es dans la fen\u00eatre. Cela me permet d'\u00e9quilibrer la r\u00e9partition uniforme et l'efficacit\u00e9. <strong>Requ\u00eates<\/strong>. Les politiques de r\u00e9tention suppriment les anciennes donn\u00e9es de mani\u00e8re planifiable. Les agr\u00e9gats continus acc\u00e9l\u00e8rent les tableaux de bord. Il en r\u00e9sulte des co\u00fbts d'exploitation clairs et des temps de r\u00e9ponse courts.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/entwickler_sharding_setup_2847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seuils concrets pour la d\u00e9cision<\/h2>\n<p>Je prends mes d\u00e9cisions en fonction de crit\u00e8res mesurables plut\u00f4t que de mon intuition. Les r\u00e8gles empiriques suivantes ont fait leurs preuves :<\/p>\n<ul>\n  <li><strong>Volume de donn\u00e9es<\/strong>: \u00c0 partir d'environ 1 \u00e0 2 To de donn\u00e9es actives ou &gt;5 To de donn\u00e9es totales, j'envisage le partitionnement. Si la croissance est sup\u00e9rieure \u00e0 101 TP3T par mois, je planifie plus t\u00f4t.<\/li>\n  <li><strong>\u00c9crire<\/strong>: &gt;2\u20135k op\u00e9rations d'\u00e9criture\/s avec des exigences transactionnelles surchargent rapidement un ma\u00eetre. \u00c0 partir de 70% CPU pendant des heures malgr\u00e9 le r\u00e9glage, le sharding est n\u00e9cessaire.<\/li>\n  <li><strong>Lire<\/strong>: &gt;50-100k requ\u00eates de lecture\/s justifient des r\u00e9pliques suppl\u00e9mentaires. Si le taux de r\u00e9ussite du cache &lt;90% Malgr\u00e9 les optimisations, je proc\u00e8de \u00e0 une mise \u00e0 l&#039;\u00e9chelle horizontale.<\/li>\n  <li><strong>Stockage\/E\/S<\/strong>: Un stockage lent et satur\u00e9 de plus de 801 TP3T IOPS ou 751 TP3T g\u00e9n\u00e8re des pics de latence. Les shards r\u00e9duisent la charge d'E\/S par n\u0153ud.<\/li>\n  <li><strong>D\u00e9calage de r\u00e9plication<\/strong>: &gt;1\u20132 s p95 en cas de pics de charge, le read-after-write est compromis. Je redirige alors les sessions vers le writer ou je proc\u00e8de \u00e0 un scaling par shard.<\/li>\n  <li><strong>RTO\/RPO<\/strong>: Si les sauvegardes\/restaurations ne peuvent pas respecter les SLO (par exemple, restauration &gt; 2 h), je divise les donn\u00e9es en fragments pour une restauration parall\u00e8le.<\/li>\n<\/ul>\n<p>Ces chiffres sont des points de d\u00e9part. Je les calibre en fonction de ma charge de travail, des profils mat\u00e9riels et de mes SLO.<\/p>\n\n<h2>Contr\u00f4ler consciemment la consistance<\/h2>\n<p>Je choisis consciemment entre <strong>asynchrone<\/strong> et <strong>synchrone<\/strong>R\u00e9plication. L'asynchrone minimise la latence d'\u00e9criture, mais risque un d\u00e9calage de quelques secondes. Le synchrone garantit une perte de donn\u00e9es nulle en cas de basculement, mais augmente les temps de validation. Je d\u00e9finis les param\u00e8tres de validation de mani\u00e8re \u00e0 respecter les budgets de latence et \u00e0 ce que le d\u00e9calage reste observable.<\/p>\n<p>Pour <strong>Lecture apr\u00e8s \u00e9criture<\/strong> route je session-sticky vers le Writer ou j'utilise \u201e fenced reads \u201c (lecture uniquement si la r\u00e9plique confirme le statut du journal correspondant). Pour <strong>lectures monotones<\/strong> Je m'assure que les demandes suivantes lisent \u2265 la derni\u00e8re version vue. Ainsi, je maintiens les attentes des utilisateurs stables sans \u00eatre toujours strictement synchronis\u00e9.<\/p>\n\n<h2>Cl\u00e9 de partitionnement, contraintes globales et conception de requ\u00eates<\/h2>\n<p>Je choisis le <strong>cl\u00e9 de partitionnement<\/strong> de sorte que la plupart des requ\u00eates restent locales. Cela \u00e9vite les requ\u00eates en \u00e9ventail co\u00fbteuses. Globale <strong>clart\u00e9<\/strong> (par exemple, une adresse e-mail unique) \u00e0 l'aide d'une table de r\u00e9pertoire d\u00e9di\u00e9e et l\u00e9g\u00e8re ou par normalisation d\u00e9terministe mapp\u00e9e sur le m\u00eame fragment. Pour les rapports, j'accepte souvent la coh\u00e9rence \u00e9ventuelle et je pr\u00e9f\u00e8re les vues mat\u00e9rialis\u00e9es ou les t\u00e2ches d'agr\u00e9gation.<\/p>\n<p>J'\u00e9vite les anti-mod\u00e8les d\u00e8s le d\u00e9but : \u00e9pingler un grand tableau \u201e clients \u201c sur un fragment cr\u00e9e des points chauds. Je r\u00e9partis les grands clients sur <em>fragments virtuels<\/em> ou segmenter par sous-domaines. Je traduis les index secondaires qui effectuent des recherches sur plusieurs fragments dans des services de recherche ou j'\u00e9cris de mani\u00e8re s\u00e9lective des doublons dans un magasin de rapports.<\/p>\n\n<h2>Identifiants, heure et points d'acc\u00e8s<\/h2>\n<p>Je cr\u00e9e <strong>IDs<\/strong>, qui \u00e9vitent les collisions et \u00e9quilibrent les fragments. Les cl\u00e9s monotones, purement ascendantes, entra\u00eenent des partitions chaudes dans le cas du partitionnement par plage. J'utilise donc des identifiants \u201e temporels \u201c avec randomisation int\u00e9gr\u00e9e (par exemple k-sorted), ou je s\u00e9pare l'ordre temporel de la r\u00e9partition des fragments. Ainsi, les insertions restent largement r\u00e9parties sans que les s\u00e9ries chronologiques ne deviennent inutilisables.<\/p>\n<p>Pour mettre de l'ordre dans les flux, je combine le tri c\u00f4t\u00e9 serveur avec la pagination par curseur, au lieu d'utiliser l'offset\/la limite via des shards. Cela r\u00e9duit la charge et maintient les latences stables.<\/p>\n\n<h2>Les transactions inter-fragments dans la pratique<\/h2>\n<p>Je d\u00e9cide t\u00f4t comment je vais <strong>Cross-Shard<\/strong>-trajectoires d'\u00e9criture. Le commit en deux phases apporte une grande coh\u00e9rence, mais entra\u00eene une latence et une complexit\u00e9 suppl\u00e9mentaires. Dans de nombreuses charges de travail Web, je mise sur <strong>Sagas<\/strong>: Je divise la transaction en plusieurs \u00e9tapes avec des compensations. Pour les \u00e9v\u00e9nements et les chemins de r\u00e9plication, un mod\u00e8le de bo\u00eete d'envoi m'aide \u00e0 \u00e9viter la perte de messages. Des op\u00e9rations idempotentes et des transitions d'\u00e9tat clairement d\u00e9finies emp\u00eachent les doublons.<\/p>\n<p>Je limite les cas de cross-shard en d\u00e9coupant le mod\u00e8le de donn\u00e9es localement (Bounded Contexts). Lorsque cela n'est pas possible, je cr\u00e9e une petite couche de coordination qui g\u00e8re proprement les d\u00e9lais d'attente, les r\u00e9essais et les messages rejet\u00e9s.<\/p>\n\n<h2>Sauvegardes, restauration et r\u00e9\u00e9quilibrage dans le cluster de shards<\/h2>\n<p>Je s\u00e9curise <strong>par fragment<\/strong> et coordonnez les instantan\u00e9s \u00e0 l'aide d'un marqueur global afin de documenter un \u00e9tat coh\u00e9rent. Pour <strong>Point-in-Time-Recovery<\/strong> Je synchronise les heures de d\u00e9marrage afin de pouvoir ramener l'ensemble du r\u00e9seau au m\u00eame moment. Je limite les E\/S de sauvegarde par le throttling afin que le fonctionnement normal n'en p\u00e2tisse pas.<\/p>\n<p>\u00c0 l'adresse suivante : <strong>r\u00e9\u00e9quilibrage<\/strong> Je d\u00e9place des fragments virtuels plut\u00f4t que des partitions physiques enti\u00e8res. Je commence par copier en lecture seule, puis je passe \u00e0 une br\u00e8ve synchronisation delta et enfin, je proc\u00e8de \u00e0 la conversion. Des alertes signalant les retards et l'augmentation des taux d'erreur accompagnent chaque \u00e9tape. La conversion reste ainsi pr\u00e9visible.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/server-sharding-hosting-7184.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exploitation : mises \u00e0 niveau, sch\u00e9mas et d\u00e9ploiements de fonctionnalit\u00e9s<\/h2>\n<p>Je pr\u00e9vois <strong>mises \u00e0 niveau progressives<\/strong> par fragments, afin que la plateforme reste en ligne. J'effectue les modifications de sch\u00e9ma selon le mod\u00e8le Expand\/Contract : d'abord les champs additifs et les chemins d'\u00e9criture doubles, puis les backfills, et enfin la suppression de l'ancienne structure. Je surveille les budgets d'erreurs et peux rapidement revenir en arri\u00e8re \u00e0 l'aide d'un indicateur de fonctionnalit\u00e9 si les m\u00e9triques basculent.<\/p>\n<p>Pour les valeurs par d\u00e9faut et les t\u00e2ches de migration importantes, je travaille de mani\u00e8re asynchrone en arri\u00e8re-plan. Chaque modification est mesurable : dur\u00e9e d'ex\u00e9cution, taux, erreurs, impact sur les chemins d'acc\u00e8s fr\u00e9quents. Ainsi, je ne suis pas surpris par des effets secondaires pendant les pics d'activit\u00e9.<\/p>\n\n<h2>S\u00e9curit\u00e9, localisation des donn\u00e9es et s\u00e9paration des clients<\/h2>\n<p>Je fais attention <strong>Localisation des donn\u00e9es<\/strong> et conformit\u00e9 d\u00e8s le d\u00e9part. Les fragments peuvent \u00eatre s\u00e9par\u00e9s par r\u00e9gion afin de respecter les exigences l\u00e9gales. Je crypte les donn\u00e9es au repos et en transit et respecte des <em>least privilege<\/em>-Politiques pour les comptes de service. Pour <strong>Mandants<\/strong> Je d\u00e9finis les identifiants de locataire comme premier \u00e9l\u00e9ment de la cl\u00e9. Les audits et les journaux conformes aux normes de r\u00e9vision sont ex\u00e9cut\u00e9s par fragment afin que je puisse fournir rapidement des r\u00e9ponses en cas d'urgence.<\/p>\n\n<h2>Mise en cache avec r\u00e9plication et fragments<\/h2>\n<p>J'utilise les caches de mani\u00e8re cibl\u00e9e. Les cl\u00e9s contiennent le <strong>Contexte de fragment<\/strong>, afin d'\u00e9viter toute collision. Gr\u00e2ce au hachage coh\u00e9rent, le cluster de cache s'adapte en cons\u00e9quence. J'utilise le write-through ou le write-behind en fonction des budgets de latence ; pour les chemins critiques en mati\u00e8re d'invalidations, je pr\u00e9f\u00e8re le <strong>\u00e9criture directe<\/strong> plus des TTL plus courts. Contre <em>Ru\u00e9e vers le cache<\/em> aident \u00e0 r\u00e9duire la gigue avec TTL et <em>fusion des requ\u00eates<\/em>.<\/p>\n<p>En cas de retard de r\u00e9plication, je donne la priorit\u00e9 aux lectures du cache plut\u00f4t qu'aux lectures de r\u00e9pliques l\u00e9g\u00e8rement obsol\u00e8tes, si le produit le permet. Pour <strong>Lecture apr\u00e8s \u00e9criture<\/strong> Je marque bri\u00e8vement les cl\u00e9s concern\u00e9es comme \u201e fra\u00eeches \u201c ou contourne le cache de mani\u00e8re cibl\u00e9e.<\/p>\n\n<h2>Planification des capacit\u00e9s et contr\u00f4le des co\u00fbts<\/h2>\n<p>Je pr\u00e9vois la croissance des donn\u00e9es et le QPS chaque trimestre. Je planifie les utilisations sup\u00e9rieures \u00e0 60-70% comme \u201e pleines \u201c et je garde une marge de 20-30% pour les pics et le r\u00e9\u00e9quilibrage. Je <strong>redimensionnement<\/strong>Je mesure r\u00e9guli\u00e8rement les instances et calcule le co\u00fbt par 1 000 requ\u00eates et par Go\/mois par fragment. Si la r\u00e9plication engendre des co\u00fbts de stockage suppl\u00e9mentaires, mais n'est que rarement utilis\u00e9e, je r\u00e9duis le nombre de n\u0153uds de lecture et investis dans l'optimisation des requ\u00eates. Si le fragmentage g\u00e9n\u00e8re une charge trop importante, j'automatise syst\u00e9matiquement les basculements, les sauvegardes et les r\u00e9\u00e9quilibrages.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/datenbank-sharding-webhosting-9374.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref<\/h2>\n<p>J'utilise <strong>R\u00e9plication<\/strong> Tout d'abord, lorsque les performances de lecture et la disponibilit\u00e9 sont importantes. Si les volumes de donn\u00e9es et la charge d'\u00e9criture augmentent de mani\u00e8re constante, le partitionnement est incontournable. Une approche hybride offre le meilleur compromis entre \u00e9volutivit\u00e9 et fiabilit\u00e9. Des m\u00e9triques claires, un sch\u00e9ma propre et des tests permettent de prendre une d\u00e9cision en toute s\u00e9curit\u00e9. C'est ainsi que j'utilise le partitionnement de base de donn\u00e9es de mani\u00e8re cibl\u00e9e et que je garantis la fiabilit\u00e9 de la plateforme.<\/p>","protected":false},"excerpt":{"rendered":"<p>D\u00e9couvrez quand l'h\u00e9bergement avec partitionnement de base de donn\u00e9es et la r\u00e9plication de base de donn\u00e9es sont utiles. Guide complet sur la mise \u00e0 l'\u00e9chelle des bases de donn\u00e9es pour les infrastructures d'h\u00e9bergement modernes.<\/p>","protected":false},"author":1,"featured_media":15712,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-15719","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"2083","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"database sharding hosting","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"15712","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/15719","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=15719"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/15719\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/15712"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=15719"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=15719"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=15719"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}