Agregační rámec je zásadním kolečkem v infrastruktuře MongoDB. Pomáhá vám analyzovat, sumarizovat a agregovat data uložená v MongoDB. Další podrobnosti o agregačním rámci v MongoDB 2.6 najdete v tomto příspěvku na blogu.
Ve verzi 2.6 provedla společnost MongoDB jemnou, ale významnou změnu ve způsobu, jakým se základní agregační kanály provádějí ve sdíleném prostředí. Při práci se sdílenými kolekcemi MongoDB rozděluje potrubí na dvě fáze. První fáze neboli fáze „$match“ probíhá na každém fragmentu a vybírá příslušné dokumenty. Pokud plánovač dotazů určí, že fragment není relevantní na základě fragmentů klíčů, pak se tato fáze na tomto fragmentu neprovede.
Následné fáze probíhají pouze na „primárním“ fragmentu kolekce. Tento fragment sloučí data z ostatních fragmentů a spustí zbytek kanálu. To má za následek podstatně větší zatížení primárního střepu agregované kolekce. Zde je příklad od jednoho z našich zákazníků, který používá tři fragmenty a používá primárně agregační dotazy:
Jak vidíte, zatížení prvního úlomku je konzistentně 3–4krát vyšší než u druhého důvodu. Toto je extrémní příklad, protože v případě, že by byl druhý a třetí střep přidán později, primárním střepem pro všechny sbírky je tedy první střep. Takže v podstatě následující fáze všech našich agregačních úloh běží pouze na Shard1. Pokud prozkoumáte protokoly na primárním datovém fragmentu, uvidíte řadu příkazů „merge“, které načítají data z ostatních datových fragmentů.
Před verzí 2.6 se následující fáze agregačního kanálu používaly na vašich serverech MongoDB, a nikoli na primárním datovém fragmentu.
Jak tedy řešíte toto nerovnoměrné rozložení zatížení? Máte několik možností:
- Pokud spouštíte agregace ve více kolekcích, zajistěte, aby byly „primární úlomky“ kolekcí rovnoměrně rozmístěny ve vašich útržcích.
- Pokud máte vysokou agregační zátěž pouze u jedné kolekce, možná budete muset pro svůj primární datový fragment použít o něco větší počítače.
Jako vždy, pokud máte nějaké dotazy nebo připomínky, napište nám na adresu [email protected].