[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-26-sharding-vs-partitionnement-tables-massives":3},{"article":4,"author":59},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":24,"related_articles":39},"d6000000-0000-0000-0000-000000000126","a0000000-0000-0000-0000-000000000065","Deep EVM #26 : Sharding vs partitionnement — Architecture pour tables massives","deep-evm-26-sharding-vs-partitionnement-tables-massives","Comparez le sharding et le partitionnement de bases de données pour la mise à l'échelle horizontale. Couvre le hachage cohérent, les requêtes cross-shard, le resharding et quand choisir chaque approche.","## La différence fondamentale\n\nLe partitionnement et le sharding divisent tous les deux les données en morceaux plus petits, mais opèrent à des niveaux différents. Le partitionnement divise une table sur le même serveur de base de données. Le sharding distribue les données sur plusieurs serveurs. Comprendre quand utiliser chaque approche est essentiel.\n\n## Partitionnement (même serveur)\n\n```\n┌─────────────────────────────┐\n│       Serveur PostgreSQL     │\n│  ┌─────────┐ ┌─────────┐   │\n│  │ Part. 1 │ │ Part. 2 │   │\n│  └─────────┘ └─────────┘   │\n│  ┌─────────┐ ┌─────────┐   │\n│  │ Part. 3 │ │ Part. 4 │   │\n│  └─────────┘ └─────────┘   │\n└─────────────────────────────┘\n```\n\nAvantages : transactions ACID, requêtes cross-partition transparentes, pas de changement d'application.\n\n## Sharding (serveurs multiples)\n\n```\n┌──────────┐  ┌──────────┐  ┌──────────┐\n│ Shard 1  │  │ Shard 2  │  │ Shard 3  │\n│ (PG)     │  │ (PG)     │  │ (PG)     │\n└──────────┘  └──────────┘  └──────────┘\n      ↑              ↑              ↑\n      └──────────────┼──────────────┘\n                     │\n            ┌────────────────┐\n            │ Router\u002FProxy   │\n            └────────────────┘\n```\n\nAvantages : mise à l'échelle horizontale du débit et du stockage, isolation des défaillances.\n\n## Hachage cohérent\n\nPour distribuer les données uniformément entre les shards :\n\n```rust\nuse std::collections::BTreeMap;\n\nstruct ConsistentHash {\n    ring: BTreeMap\u003Cu64, ShardId>,\n    virtual_nodes: u32,\n}\n\nimpl ConsistentHash {\n    fn get_shard(&self, key: &[u8]) -> ShardId {\n        let hash = xxhash(key);\n        \u002F\u002F Trouver le premier nœud >= hash sur l'anneau\n        self.ring.range(hash..)\n            .next()\n            .or_else(|| self.ring.iter().next()) \u002F\u002F Boucler\n            .map(|(_, shard)| *shard)\n            .unwrap()\n    }\n}\n```\n\nLe hachage cohérent minimise la redistribution des données lors de l'ajout\u002Fsuppression de shards.\n\n## Requêtes cross-shard\n\nLe défi principal du sharding : les requêtes qui touchent plusieurs shards.\n\n```rust\nasync fn search_all_shards(\n    shards: &[ShardConnection],\n    query: &str,\n) -> Vec\u003CResult> {\n    \u002F\u002F Exécuter en parallèle sur tous les shards\n    let futures = shards.iter()\n        .map(|shard| shard.query(query));\n\n    let results = futures::future::join_all(futures).await;\n\n    \u002F\u002F Fusionner et trier les résultats\n    results.into_iter()\n        .flat_map(|r| r.unwrap_or_default())\n        .sorted_by_key(|r| r.score)\n        .collect()\n}\n```\n\n## Quand choisir quoi\n\n| Critère | Partitionnement | Sharding |\n|---------|-----------------|----------|\n| Taille des données | \u003C 1 TB | > 1 TB |\n| Débit d'écriture | \u003C 50K\u002Fs | > 50K\u002Fs |\n| Transactions ACID | Oui | Limité |\n| Complexité opérationnelle | Faible | Élevée |\n| Requêtes cross-données | Transparentes | Complexes |\n| Coût | Un serveur | Multiple serveurs |\n\nRègle pratique : commencez par le partitionnement. Passez au sharding seulement quand un seul serveur ne suffit plus, malgré les optimisations.\n\n## Resharding\n\nAjouter des shards à un système existant est l'une des opérations les plus complexes :\n\n1. Ajouter les nouveaux shards\n2. Mettre à jour la fonction de hachage\n3. Migrer les données affectées en arrière-plan\n4. Basculer le routage progressivement\n5. Nettoyer les anciennes données\n\nLe hachage cohérent minimise les données à déplacer — idéalement, seulement 1\u002FN des données quand on passe de N à N+1 shards.\n\n## Conclusion\n\nLe partitionnement est votre premier outil de mise à l'échelle — simple, transparent, pas de changement applicatif. Le sharding est le recours quand un seul serveur atteint ses limites. Planifiez votre clé de sharding soigneusement car en changer est extrêmement coûteux.","\u003Ch2 id=\"la-diff-rence-fondamentale\">La différence fondamentale\u003C\u002Fh2>\n\u003Cp>Le partitionnement et le sharding divisent tous les deux les données en morceaux plus petits, mais opèrent à des niveaux différents. Le partitionnement divise une table sur le même serveur de base de données. Le sharding distribue les données sur plusieurs serveurs. Comprendre quand utiliser chaque approche est essentiel.\u003C\u002Fp>\n\u003Ch2 id=\"partitionnement-m-me-serveur\">Partitionnement (même serveur)\u003C\u002Fh2>\n\u003Cpre>\u003Ccode>┌─────────────────────────────┐\n│       Serveur PostgreSQL     │\n│  ┌─────────┐ ┌─────────┐   │\n│  │ Part. 1 │ │ Part. 2 │   │\n│  └─────────┘ └─────────┘   │\n│  ┌─────────┐ ┌─────────┐   │\n│  │ Part. 3 │ │ Part. 4 │   │\n│  └─────────┘ └─────────┘   │\n└─────────────────────────────┘\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Avantages : transactions ACID, requêtes cross-partition transparentes, pas de changement d’application.\u003C\u002Fp>\n\u003Ch2 id=\"sharding-serveurs-multiples\">Sharding (serveurs multiples)\u003C\u002Fh2>\n\u003Cpre>\u003Ccode>┌──────────┐  ┌──────────┐  ┌──────────┐\n│ Shard 1  │  │ Shard 2  │  │ Shard 3  │\n│ (PG)     │  │ (PG)     │  │ (PG)     │\n└──────────┘  └──────────┘  └──────────┘\n      ↑              ↑              ↑\n      └──────────────┼──────────────┘\n                     │\n            ┌────────────────┐\n            │ Router\u002FProxy   │\n            └────────────────┘\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Avantages : mise à l’échelle horizontale du débit et du stockage, isolation des défaillances.\u003C\u002Fp>\n\u003Ch2 id=\"hachage-coh-rent\">Hachage cohérent\u003C\u002Fh2>\n\u003Cp>Pour distribuer les données uniformément entre les shards :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-rust\">use std::collections::BTreeMap;\n\nstruct ConsistentHash {\n    ring: BTreeMap<u64, ShardId>,\n    virtual_nodes: u32,\n}\n\nimpl ConsistentHash {\n    fn get_shard(&self, key: &[u8]) -> ShardId {\n        let hash = xxhash(key);\n        \u002F\u002F Trouver le premier nœud >= hash sur l'anneau\n        self.ring.range(hash..)\n            .next()\n            .or_else(|| self.ring.iter().next()) \u002F\u002F Boucler\n            .map(|(_, shard)| *shard)\n            .unwrap()\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Le hachage cohérent minimise la redistribution des données lors de l’ajout\u002Fsuppression de shards.\u003C\u002Fp>\n\u003Ch2 id=\"requ-tes-cross-shard\">Requêtes cross-shard\u003C\u002Fh2>\n\u003Cp>Le défi principal du sharding : les requêtes qui touchent plusieurs shards.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-rust\">async fn search_all_shards(\n    shards: &[ShardConnection],\n    query: &str,\n) -> Vec<Result> {\n    \u002F\u002F Exécuter en parallèle sur tous les shards\n    let futures = shards.iter()\n        .map(|shard| shard.query(query));\n\n    let results = futures::future::join_all(futures).await;\n\n    \u002F\u002F Fusionner et trier les résultats\n    results.into_iter()\n        .flat_map(|r| r.unwrap_or_default())\n        .sorted_by_key(|r| r.score)\n        .collect()\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"quand-choisir-quoi\">Quand choisir quoi\u003C\u002Fh2>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Critère\u003C\u002Fth>\u003Cth>Partitionnement\u003C\u002Fth>\u003Cth>Sharding\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Taille des données\u003C\u002Ftd>\u003Ctd>< 1 TB\u003C\u002Ftd>\u003Ctd>> 1 TB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Débit d’écriture\u003C\u002Ftd>\u003Ctd>< 50K\u002Fs\u003C\u002Ftd>\u003Ctd>> 50K\u002Fs\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Transactions ACID\u003C\u002Ftd>\u003Ctd>Oui\u003C\u002Ftd>\u003Ctd>Limité\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Complexité opérationnelle\u003C\u002Ftd>\u003Ctd>Faible\u003C\u002Ftd>\u003Ctd>Élevée\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Requêtes cross-données\u003C\u002Ftd>\u003Ctd>Transparentes\u003C\u002Ftd>\u003Ctd>Complexes\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Coût\u003C\u002Ftd>\u003Ctd>Un serveur\u003C\u002Ftd>\u003Ctd>Multiple serveurs\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>Règle pratique : commencez par le partitionnement. Passez au sharding seulement quand un seul serveur ne suffit plus, malgré les optimisations.\u003C\u002Fp>\n\u003Ch2 id=\"resharding\">Resharding\u003C\u002Fh2>\n\u003Cp>Ajouter des shards à un système existant est l’une des opérations les plus complexes :\u003C\u002Fp>\n\u003Col>\n\u003Cli>Ajouter les nouveaux shards\u003C\u002Fli>\n\u003Cli>Mettre à jour la fonction de hachage\u003C\u002Fli>\n\u003Cli>Migrer les données affectées en arrière-plan\u003C\u002Fli>\n\u003Cli>Basculer le routage progressivement\u003C\u002Fli>\n\u003Cli>Nettoyer les anciennes données\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Le hachage cohérent minimise les données à déplacer — idéalement, seulement 1\u002FN des données quand on passe de N à N+1 shards.\u003C\u002Fp>\n\u003Ch2 id=\"conclusion\">Conclusion\u003C\u002Fh2>\n\u003Cp>Le partitionnement est votre premier outil de mise à l’échelle — simple, transparent, pas de changement applicatif. Le sharding est le recours quand un seul serveur atteint ses limites. Planifiez votre clé de sharding soigneusement car en changer est extrêmement coûteux.\u003C\u002Fp>\n","fr","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:29.343642Z","Sharding vs partitionnement — Architecture pour tables massives","Comparaison sharding et partitionnement pour la mise à l'échelle horizontale. Hachage cohérent, requêtes cross-shard et partitionnement natif PostgreSQL.","sharding vs partitionnement base données",null,"index, follow",[22,27,31,35],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000022","Performance","performance",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000005","PostgreSQL","postgresql",{"id":36,"name":37,"slug":38,"created_at":26},"c0000000-0000-0000-0000-000000000001","Rust","rust",[40,47,53],{"id":41,"title":42,"slug":43,"excerpt":44,"locale":12,"category_name":45,"published_at":46},"d0000000-0000-0000-0000-000000000677","Pourquoi Bali devient le hub impact-tech d'Asie du Sud-Est en 2026","pourquoi-bali-devient-hub-impact-tech-asie-sud-est-2026","Bali se classe 16e parmi les écosystèmes startups d'Asie du Sud-Est. Avec une concentration croissante de bâtisseurs Web3, de startups IA durables et d'entreprises eco-travel tech, l'île se forge une identité de capitale impact-tech de la région.","Ingénierie","2026-03-28T10:44:49.517126Z",{"id":48,"title":49,"slug":50,"excerpt":51,"locale":12,"category_name":45,"published_at":52},"d0000000-0000-0000-0000-000000000676","Le patchwork de la protection des données ASEAN : checklist de conformité pour les développeurs","patchwork-protection-donnees-asean-checklist-conformite-developpeurs","Sept pays de l'ASEAN disposent désormais de lois complètes sur la protection des données, chacune avec des modèles de consentement, des exigences de localisation et des structures de sanctions différents. Voici une checklist pratique de conformité pour les développeurs.","2026-03-28T10:44:49.504560Z",{"id":54,"title":55,"slug":56,"excerpt":57,"locale":12,"category_name":45,"published_at":58},"d0000000-0000-0000-0000-000000000675","La transformation numérique de 29 milliards de dollars d'Indonesia : opportunités pour les éditeurs de logiciels","transformation-numerique-29-milliards-dollars-indonesia-opportunites-editeurs-logiciels","Le marché des services informatiques d'Indonesia devrait atteindre 29,03 milliards de dollars en 2026, contre 24,37 milliards en 2025. L'infrastructure cloud, l'IA, le e-commerce et les centres de données tirent la croissance la plus rapide d'Asie du Sud-Est.","2026-03-28T10:44:49.469231Z",{"id":13,"name":60,"slug":61,"bio":62,"photo_url":19,"linkedin":19,"role":63,"created_at":64,"updated_at":64},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]