Existují nějaké výhody použití vlastního

Výhody s generováním vlastního _id s:

Můžete je učinit přívětivějšími pro člověka přiřazením zvyšujících se čísel:1 , 2 , 3 , ...
Nebo je můžete učinit lidštějšími pomocí náhodných řetězců:t3oSKd9q

(To nezabere příliš mnoho místa na obrazovce, lze jej vybrat ze seznamu a v případě potřeby jej lze zkopírovat ručně. Je však třeba, aby byl dostatečně dlouhý, aby se předešlo tajným dohodám.)
Pokud použijete náhodně generované řetězce, budou mít přibližně rovnoměrnou distribuci shardingu, na rozdíl od standardních mongo ObjectId, které má tendenci seskupovat záznamy vytvořené ve stejnou dobu do stejného fragmentu. (Zda je to užitečné nebo ne, závisí na vaší strategii sdílení.)
Nebo si můžete vygenerovat vlastní _id s, které seskupují související objekty do jednoho fragmentu, např. podle vlastníka, zeměpisné oblasti nebo kombinace. (Opět, zda je to žádoucí nebo ne, závisí na tom, jak máte v úmyslu dotazovat se na data a/nebo jak rychle je vytváříte a ukládáte. Můžete to také provést zadáním shard key namísto _id sám. Viz diskuze níže.)

Výhody použití ObjectId s:

ObjectId velmi dobře zabraňují kolizím. Pokud si vygenerujete vlastní _id s náhodně nebo souběžně, pak musíte riziko kolize řídit sami.
ObjectId obsahují čas jejich vytvoření. To může být levný a snadný způsob, jak zachovat datum vytvoření dokumentu a chronologicky seřadit dokumenty. (Na druhou stranu, pokud nechcete prozradit/prozradit datum vytvoření dokumentu, pak nesmíte odhalit jeho ObjectId!)

nanoid modul vám může pomoci generovat krátká náhodná ID. Poskytují také kalkulátor což vám může pomoci vybrat vhodnou délku ID v závislosti na tom, kolik dokumentů/ID generujete každou hodinu.

Případně jsem napsal mongoose-generate-unique-key pro generování velmi krátká náhodná id (za předpokladu, že používáte knihovnu mongoose).

Strategie sdílení

Nebudu tvrdit, že jsem odborníkem na to, jak nejlépe sdílet data, ale zde jsou některé situace, které bychom mohli zvážit:

Astronomická observatoř nebo urychlovač částic zvládne gigabajty dat za sekundu. Když je zjištěna zajímavá událost, může chtít uložit obrovské množství dat během několika sekund. V tomto případě pravděpodobně chtějí rovnoměrné rozložení dokumentů mezi úlomky, takže každý úlomek bude pracovat stejně tvrdě na uložení dat a žádný útržek nebude zahlcen.
Máte obrovské množství dat a občas je potřebujete všechny zpracovat najednou. V tomto případě (ale v závislosti na algoritmu) může být opět žádoucí rovnoměrné rozložení, takže všechny úlomky mohou pracovat stejně tvrdě na zpracování své části dat, než na konci výsledky zkombinují. (I když v tomto scénáři se můžeme pro rovnoměrnou distribuci spolehnout na balancer MongoDB, spíše než na náš shard klíč. Balancér běží na pozadí po uložení dat. Po shromáždění velkého množství dat budete možná muset nechte přes noc znovu rozdělit kousky.)
Máte aplikaci pro sociální média s velkým množstvím dat, ale tentokrát mnoho různých uživatelů zadává mnoho lehkých dotazů související především s jejich vlastními daty, nebo jejich konkrétními přáteli či tématy. V tomto případě nemá smysl zapojovat každý střípek, kdykoli uživatel udělá malý dotaz. Může mít smysl provést fragmentaci podle userId (nebo podle tématu nebo podle geografické oblasti), takže všechny dokumenty patřící jednomu uživateli budou uloženy na jednom datovém fragmentu, a když tento uživatel zadá dotaz, musí pracovat pouze jeden fragment. To by mělo ponechat ostatním datovým fragmentům volnost pro zpracování dotazů pro jiné uživatele, takže může být obsluhováno mnoho uživatelů najednou.
Sdílení dokumentů podle času vytvoření (které vám poskytnou výchozí ObjectId) může být žádoucí, pokud máte mnoho lehkých dotazů na data za podobná časová období. Například mnoho různých uživatelů dotazujících se na různé historické grafy.

Ale nemusí být tak žádoucí, pokud většina vašich uživatelů dotazuje pouze na nejnovější dokumenty (běžná situace na platformách sociálních médií), protože by to znamenalo, že většinu práce by dostal jeden nebo dva úlomky. Distribuce podle tématu nebo možná podle regionu by mohla poskytnout plošší celkovou distribuci a zároveň umožnit shlukování souvisejících dokumentů na jeden útržek.

Možná si budete chtít přečíst oficiální dokumenty na toto téma:

Existují nějaké výhody použití vlastního _id pro dokumenty v MongoDB?

Strategie sdílení