Переход к последовательным (гребенчатым) направляющим - как насчет существующих данных?

Question

У нас есть база данных с 500+ таблицами, в которой почти все таблицы имеют кластеризованную PK с типом guid (uniqueidentifier).

Мы находимся в процессе тестирования перехода от «обычных» «случайных» направляющих, генерируемых с помощью метода .NETs Guid.NewGuid (), к последовательным направляющим, генерируемым с помощью NHibernate guid.comb . Кажется, это работает хорошо, но как насчет клиентов, у которых уже есть миллионы строк со «случайными» значениями первичного ключа?

• Получат ли они выгоду от того, что новые идентификаторы, генерируемые с этого момента, будут последовательными?
• Может ли / должно ли быть что-либо сделано с их существующими данными?

Заранее благодарим за любые указания на это.

Answer 1

Это зависит от того, сгруппированы ли таблицы по первичному индексу или по другому индексу. Например, если вы создаете большое количество новых записей в таблице с GUID PK и датой создания, обычно имеет смысл кластеризовать по дате создания для оптимизации операции вставки.

С другой стороны, в зависимости от выполненных запросов кластер с GUID может быть лучше, и в этом случае использование последовательных идентификаторов GUID может повысить производительность вставки. Я бы сказал, что невозможно дать окончательный ответ на ваш вопрос без глубоких знаний об использовании.

Answer 2

Я сталкиваюсь с подобной проблемой, я думаю, что было бы возможно обновить существующие данные, написав приложение для обновления существующих ключей с использованием алгоритма NHibernate guid.comb. Чтобы распространить новые ключи на связанные таблицы внешних ключей, возможно, можно было бы временно каскадно обновлять? Выполнение этого с помощью кода .NET будет медленнее, чем сценария SQL, другой вариант может заключаться в дублировании логики guid.comb в SQL, но не уверен, возможно ли это.

Если вы решите сохранить существующие данные, использование алгоритма guid.comb должно привести к некоторому улучшению производительности, при вставках будет происходить разбиение страницы, но поскольку новые направляющие являются последовательными, а не полностью случайными, это будет по меньшей мере несколько уменьшено. , Другой вариант, который следует рассмотреть, - это удалить кластеризованный индекс в первичном ключе GUID, хотя я не уверен, насколько это повлияет на производительность существующих запросов.

Answer 3

Вы могли бы сделать это, но я не уверен, что вы захотите. Я не вижу никакой выгоды в использовании последовательных направляющих, фактически использование направляющих не рекомендуется в качестве первичного ключа, если нет причин для распределения / репликации. Вы используете кластерный индекс?

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

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

Я не думаю, что это стоит того, если вы вообще не уходите от гидов, чтобы сказать целочисленную систему.