в моя случай повечето идентификатори ще бъдат генерирани в рамките на голям брой мобилни клиенти, а не в рамките на ограничен набор от сървъри. Чудя се дали в този случай има основателна загриженост.
Това ми звучи като много лоша архитектура. Използвате ли двустепенна архитектура? Защо мобилните клиенти ще имат директен достъп до db? Наистина ли искате да разчитате на мрежова сигурност?
Както и да е, някои разсъждения относно вероятността от сблъсък:
Нито UUID, нито ObjectId разчитат на своя размер, т.е. и двете не са случайни числа, но следват схема, която се опитва систематично да намали вероятността от сблъсък. В случай на ObjectIds, тяхната структура е:
- 4 байта секунди от епохата на unix
- 3 байтов идентификатор на машината
- 2 байтов идентификатор на процеса
- 3 байтов брояч
Това означава, че за разлика от UUID, ObjectIds са монотонни (освен в рамките на една секунда), което вероятно е най-важното им свойство. Монотонните индекси ще доведат до по-ефективно запълване на B-дървото, позволява пейджинг по идентификатор и позволява „сортиране по подразбиране“ по идентификатор, за да направят курсорите ви стабилни, и разбира се, те носят лесен за извличане времеви печат. Това са оптимизациите, с които трябва да сте наясно и те могат да бъдат огромни.
Както можете да видите от структурата на другите 3 компонента, сблъсъците стават много вероятни, ако правите> 1k вмъквания/сек в един процес (не е възможно, дори от сървър) или ако броят на машините расте след около 10 (вижте проблема за рождения ден) или ако броят на процесите на една машина стане твърде голям (тогава отново, това не са случайни числа, но са наистина уникални на машина, но трябва да бъдат съкратени до два байта ).
Естествено, за да възникне сблъсък, те трябва да съвпадат във всички тези аспекти, така че дори и две машини да имат един и същ машинен хеш, пак ще изисква клиент да вмъкне със същата стойност на брояча в точно същата секунда и същия идентификатор на процеса, но да, тези стойности могат да се сблъскат.
