v mém případě bude většina ID generována v rámci velkého počtu mobilních klientů, nikoli v rámci omezené sady serverů. Zajímalo by mě, zda v tomto případě existuje oprávněná obava.
To mi přijde jako hodně špatná architektura. Používáte dvouvrstvou architekturu? Proč by mobilní klienti měli přímý přístup do databáze? Opravdu se chcete spolehnout na síťové zabezpečení?
Každopádně pár úvah o pravděpodobnosti kolize:
UUID ani ObjectId se nespoléhají na svou pouhou velikost, to znamená, že obě nejsou náhodná čísla, ale řídí se schématem, které se snaží systematicky snižovat pravděpodobnost kolize. V případě ObjectId je jejich struktura:
- 4 byte sekundy od epochy unixu
- 3bajtové ID stroje
- 2bajtové ID procesu
- 3bajtové počítadlo
To znamená, že na rozdíl od UUID jsou ObjectId monotónní (kromě jediné sekundy), což je pravděpodobně jejich nejdůležitější vlastnost. Monotónní indexy způsobí, že se B-Strom vyplní efektivněji, umožní stránkování podle id a umožní „výchozí řazení“ podle id, aby byly vaše kurzory stabilní, a samozřejmě nesou snadno extrahovatelné časové razítko. Toto jsou optimalizace, kterých byste si měli být vědomi a mohou být obrovské.
Jak můžete vidět ze struktury ostatních 3 komponent, kolize se stávají velmi pravděpodobnými, pokud provádíte> 1 000 vložení/s v jednom procesu (ve skutečnosti to není možné, dokonce ani ze serveru), nebo pokud roste počet strojů. kolem 10 (viz narozeninový problém), nebo pokud se počet procesů na jednom počítači příliš zvětší (pak to opět nejsou náhodná čísla, ale jsou skutečně jedinečná na počítači, ale musí být zkrácena na dva bajty ).
Aby ke kolizi došlo, musí se přirozeně shodovat ve všech tyto aspekty, takže i když dva stroje mají stejný hash stroje, stále by to vyžadovalo, aby klient vložil stejnou hodnotu čítače do přesně stejné sekundy a stejného ID procesu, ale ano, tyto hodnoty by mohly kolidovat.