Přeskočit na obsah
_CORE
AI & agentní systémy Podnikové informační systémy Cloud & Platform Engineering Datová platforma & integrace Bezpečnost & compliance QA, testování & observabilita IoT, automatizace & robotika Mobilní & digitální produkty Bankovnictví & finance Pojišťovnictví Veřejná správa Obrana & bezpečnost Zdravotnictví Energetika & utility Telco & média Průmysl & výroba Logistika & e-commerce Retail & věrnostní programy
Reference Technologie Blog Know-how Nástroje
O nás Spolupráce Kariéra
CS EN DE
Pojďme to probrat

MongoDB sharding

26. 06. 2021 Aktualizováno: 27. 03. 2026 1 min čtení advanced
Tento článek byl publikován v roce 2021. Některé informace mohou být zastaralé.

Sharding distribuuje data přes více serverů.

Architektura

  • Shard — replica set s daty
  • Config server — metadata
  • mongos — router

Setup

sh.enableSharding(‘mydb’) sh.shardCollection(‘mydb.orders’,{userId:’hashed’}) sh.status()

Shard key

  • Hashed — rovnoměrná distribuce
  • Ranged — range queries efektivní
  • Compound — balancovaná distribuce

Volba shard key

Správná volba shard key je nejdůležitější rozhodnutí při shardingu MongoDB. Špatný shard key vede k hotspotům — kdy jeden shard přijímá většinu zápisů, zatímco ostatní jsou nevyužité. Ideální shard key má vysokou kardinalitu, rovnoměrně distribuuje zápisy a podporuje vaše nejčastější dotazy.

Hashed shard key zajistí rovnoměrnou distribuci, ale znemožní efektivní range queries. Compound shard key (například {tenant_id: 1, created_at: 1}) je často nejlepší kompromis — distribuuje data podle tenantu a umožňuje efektivní časové dotazy uvnitř tenantu. Jakmile zvolíte shard key, nelze ho změnit bez migrace dat. Balancer automaticky přesouvá chunky mezi shardy pro rovnoměrné rozložení, ale tento proces spotřebovává I/O a síťovou kapacitu.

Shard key je kritický

Špatný shard key = hotspots.

mongodbshardingškálování
Sdílet:

CORE SYSTEMS tým

Stavíme core systémy a AI agenty, které drží provoz. 15 let zkušeností s enterprise IT.