LINUX.ORG.RU

История изменений

Исправление Manhunt, (текущая версия) :

2. если случилась коллизия, берёшь X+1, X+2 и т.д.

Точнее, результат выглядит так, будто бы алгоритм рассматривал поочередно X+1, X-1, X+2, X-2 и так далее до нахождения первого незанятого GUID-а. Как этот результат получается на самом деле — это уже деталь реализации хранилища, предлагаю вернуться к устройству хранилища когда других вопросов не останется.

1. генерируешь случайный
2. если случилась коллизия, берёшь X+1, X+2 и т.д.
зачем это надо, и какой в этом профит?

1. То, что сперва берется случайный GUID — это эвристика, которая пытается устремить распределение занятых GUID к равномерному.
2. Взятие ближайшего свободного GUID — это способ разрешить коллизию за одно обращение к хранилищу.

Как уже выше намекнули, если хранилище почти заполнено, время создания будет очень большим.

<Время на создание> = <время на генерацию случайного GUID (константа)> + <время за которое хранилище выполнит запрос по поиску ближайшего свободного GUID>. Верно?

Исходная версия Manhunt, :

2. если случилась коллизия, берёшь X+1, X+2 и т.д.

Точнее, результат выглядит так, будто бы алгоритм рассматривал поочередно X+1, X-1, X+2, X-2 и так далее до нахождения первого незанятого GUID-а. Как этот результат получается на самом деле — это уже деталь реализации хранилища, предлагаю вернуться к устройству хранилища когда других вопросов не останется.

1. генерируешь случайный
2. если случилась коллизия, берёшь X+1, X+2 и т.д.
зачем это надо, и какой в этом профит?

1. То, что сперва берется случайный GUID — это эвристика, которая пытается устремить распределение занятых GUID к равномерному.
2. Взятие ближайшего свободного GUID — это способ разрешить коллизию за одно обращение к хранилищу.

Как уже выше намекнули, если хранилище почти заполнено, время создания будет очень большим.

Это зависит от устройства хранилища.