Těžko říct, jaká je optimální hromadná vložka – to částečně závisí na velikosti objektů, které vkládáte, a dalších neměřitelných faktorech. Můžete vyzkoušet několik rozsahů a zjistit, co vám poskytne nejlepší výkon. Jako alternativu někteří lidé rádi používají mongoimport, což je docela rychlé, ale vaše importovaná data musí být json nebo csv. Samozřejmě existuje mongodrestore, pokud jsou data ve formátu BSON.
Mongo si snadno poradí s miliardami dokumentů a může mít miliardy dokumentů v jedné kolekci, ale nezapomeňte, že maximální velikost dokumentu je 16 MB . V MongoDB je mnoho lidí s miliardami dokumentů a je o tom spousta diskuzí na Uživatelská skupina MongoDB Google . Zde je dokument o používání velkého počtu sbírek, které byste si rádi přečetli, pokud změníte názor a chcete mít místo toho několik sbírek. Čím více kolekcí máte, tím více budete mít také indexů, což pravděpodobně není to, co chcete.
Zde je prezentace z Craigslist o vkládání miliard dokumentů do MongoDB a chlapíkovi příspěvek na blogu .
Vypadá to, že sharding by pro vás byl dobrým řešením, ale typicky se sharding používá pro škálování na více serverech a mnoho lidí to dělá, protože chtějí škálovat své zápisy nebo nejsou schopni zachovat svou pracovní sadu (data a indexy). v RAM. Je naprosto rozumné začít s jedním serverem a poté přejít na fragment nebo sadu replik, jakmile budou vaše data růst nebo budete potřebovat extra redundanci a odolnost.
Existují však i jiní uživatelé, kteří používají více mongodů, aby obešli zamykací limity jednoho mongoda se spoustou zápisů. Je to zřejmé, ale stále stojí za zmínku, ale nastavení více mongodů je složitější na správu než jeden server. Pokud zde váš IO nebo CPU není na maximum, vaše pracovní sada je menší než RAM a vaše data lze snadno udržovat v rovnováze (dost náhodně distribuovaná), měli byste zaznamenat zlepšení (se shardováním na jediném serveru). Pro informaci existuje potenciál pro spory o paměť a IO. S verzí 2.2 má vylepšenou souběh s db zamykání , mám podezření, že pro takové nasazení bude mnohem méně důvodů.
Svůj přechod na sharding si musíte správně naplánovat, tj. výběr vašeho shard klíče si dobře promyslete. Pokud půjdete tímto způsobem, pak je nejlepší předrozdělit a vypnout balancer. Přesouvat data, aby byly věci vyvážené, bude kontraproduktivní, což znamená, že se budete muset předem rozhodnout, jak je rozdělit. Kromě toho je někdy důležité navrhovat dokumenty s myšlenkou, že některé pole bude užitečné pro sdílení nebo jako primární klíč.
Zde je několik dobrých odkazů -
- Výběr Shard Key
- Příspěvek na blogu o fragmentech klíčů
- Přehled prezentace o shardingu
- Prezentace o doporučených postupech sdílení