LINUX.ORG.RU

Ответ на: комментарий от gh0stwizard

Просто генерируется почти 100% уникально.

То есть свой костыль в некотором роде будет даже надежнее в плане уникальности? :)

Siado ★★★★★
() автор топика
Ответ на: комментарий от Siado

Зависит от алгоритма шардинга. Нарпример если представить что он просто разбивает 0 to MAX_INT на части последовательных блоков, то равномерно увеличивающийся INT будет последовательно нагружать машины одну за другой, и не факт что дойдет до последних.

Я уверен шардинг в монге не такой тупой, но я думаю ты понял пример

vertexua ★★★★★
()
Ответ на: комментарий от Siado

при использовании кустарного ObjectID?

простой ID типа integer

Y ★★
()
Ответ на: комментарий от vertexua

шардинг в монге не такой тупой, но я думаю ты понял пример

Шардинг в монге не такой тупой. Всё будет норм)

Y ★★
()
Ответ на: комментарий от Siado

Нет. Там и сейчас очень надежно. Стандартный _id состоит из 4 частей: время (4 байта), идентификатор компа (3 байта), ид процесса (2 байта) и локального самоинкрементирующего счетчика для процеса (3 байта). Достаточно 1 раз сдвинуть время и дважды запустить монго с тем же pid, чтобы нарушить уникальность.

Свой ключ может предоставить плюшки и тот уровень уникальности ключа, который тебе требуется. В целом же, дефолтный _id решает поставленную задачу.

gh0stwizard ★★★★★
()
Ответ на: комментарий от gh0stwizard

Свой ключ может предоставить плюшки и тот уровень уникальности ключа, который тебе требуется. В целом же, дефолтный _id решает поставленную задачу.

У меня в задаче стоит сделать уникальный, но короткий ключ - либо INT, либо что-то типа Base 62. Монговский из 24 символов не подходит. Вот и думаю, что лучше - заменить стандартный ObjectId на свое, либо сделать дополнительное уникальное поле.

Siado ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.