Ако имате множество уеб сървъри с множество процеси, тогава наистина няма нещо, което можете да премахнете със загуба на уникалност.
Ако погледнете естеството на ObjectId :
- 4-байтова стойност, представляваща секундите от епохата на Unix,
- 3-байтов идентификатор на машината,
- 2-байтов идентификатор на процеса и
- 3-байтов брояч, започващ с произволна стойност.
Ще видите, че там няма много неща, които можете безопасно да премахнете. Тъй като първите 4 байта са време, би било предизвикателство да се приложи алгоритъм, който премахва части от времевия печат по чист и безопасен начин.
Идентификаторът на машината и идентификаторът на процеса се използват в случаите, когато има множество сървъри и/или процеси, действащи като клиенти на сървъра на базата данни. Ако изпуснете някое от тях, може да се окажете с дубликати отново. Произволната стойност като последните 3 байта се използва, за да се гарантира, че два идентификатора на една и съща машина, в рамките на един и същи процес са уникални, дори когато се изискват често.
Ако сте го използвали като id на поръчка , и искате гарантирана уникалност, не бих отрязал нищо от 12-байтовото число, тъй като то беше внимателно проектирано да осигури стабилен и ефективен разпределен механизъм за генериране на уникални числа, когато има много свързани клиенти на база данни.
Ако сте взели последните 5 знака от ObjectId ... и в даден период, каква е вероятността за конфликт?
- ID на процеса
- брояч
Вероятността за конфликт евисока . Идентификационният номер на процеса може да остане същият през целия период, а другото число е само нарастващо число, което ще се повтори след 4095 поръчки. Но ако процесът се рециклира, тогава също имате шанса да има конфликт с по-стари поръчки и т.н. И ако говорите за множество клиенти на база данни, шансовете също се увеличават. Просто не бих се опитал да отрежа номера. Не си струва недоволните клиенти да се опитват да правят поръчки.
Дори клеймото за време и произволната начална стойност не са достатъчни, когато има множество клиенти на база данни, генериращи ObjectIds . Когато започнете да разглеждате различните части, особено в контекста на група от клиенти на бази данни, трябва да разберете защо частите са там и защо премахването им може да доведе до срив в ObjectId поколение.
Предлагам ви да приложите алгоритъм за създаване на уникален номер и съхраняването му в базата данни. Достатъчно лесно е да се направи. Влияе малко на производителността, но е безопасно.
Написах това
отговори преди малко за предизвикателствата при използването на ObjectId в URL адрес. Включва връзка към това как да създадете уникално автоматично нарастващо число с помощта на MongoDB.
