Алгоритмы HiLo в основном отображают два целых числа в один целочисленный идентификатор.Это гарантирует, что пара чисел будет уникальной для каждой базы данных.Как правило, следующим шагом является гарантия того, что уникальная пара чисел соответствует уникальному целочисленному идентификатору.
Хорошее объяснение того, как концептуально работает HiLo, дано в в этом предыдущем ответе SO
Изменение max_lo сохранит свойство, что ваша пара чисел будет уникальной.Однако убедится ли он в том, что сопоставленный идентификатор уникален и не содержит коллизий?
Давайте посмотрим на реализацию HiLo в Hibernate.Алгоритм, который они, похоже, используют (исходя из того, что я собрал) таков: (и я мог бы отказаться от технических соображений)
h = high sequence (starting at 0)
l_size = size of low block
l = low sequence (starting at 1)
ID = h*l_size + l
Итак, если ваш низкий блок, скажем, 100, ваш зарезервированныйИдентификационные блоки будут идти 1-100, 101-200, 201-300, 301-400 ...
Ваша последовательность High теперь равна 3. Теперь, что произойдет, если вы вдруг измените свой l_size на 10?Ваш следующий блок, ваш максимум увеличивается, и вы получите 4*10+1 = 41
Упс.Это новое значение определенно попадает в «зарезервированный блок» 1-100.Кто-то с высокой последовательностью 0 подумает: «Ну, у меня зарезервирован диапазон 1-100, поэтому я просто положу один на 41, потому что я знаю, что он безопасен».
Вероятность столкновения определенно очень и очень высока, когда понижает ваш l_max.
Как насчет противоположного случая, поднимая его?
Вернемся к нашему примеру, давайтеувеличьте наш l_size до 500, превратив следующую клавишу в 4*500+1 = 2001, зарезервировав диапазон 2001-2501.
Похоже, что в этой конкретной реализации HiLo будет предотвращено столкновение, когда поднимает your l_max.
Конечно, вы должны выполнить несколько собственных тестов, чтобы убедиться, что это фактическая реализация или близка к ней.Одним из способов было бы установить l_max на 100 и найти первые несколько ключей, затем установить его на 500 и найти следующие.Если есть огромный скачок, как упомянуто здесь, вы могли бы быть в безопасности.
Однако я ни в коем случае не предполагаю, что лучше всего поднять ваш l_max в существующей базе данных.
Используйте свое усмотрение;Алгоритм HiLo не совсем тот, который создан с учетом переменной l_max, и ваши результаты могут оказаться непредсказуемыми в зависимости от вашей конкретной реализации.Возможно, кто-то, кто имел опыт поднятия l_max и обнаружения проблем, может доказать, что этот счет верен.
Итак, в заключение, хотя, теоретически, реализация HiLo в Hibernate, скорее всего, будет избегать коллизий, когда l_max повышается, вероятно,все еще не хорошая практика.Вы должны кодировать, как будто l_max не изменится со временем.
Но если вам повезет ...