Может ли использование последовательного Guid в качестве первичного ключа в SQL Server привести к снижению производительности для больших данных?

Question

Самая большая база данных, с которой я сталкивался, была база данных SQL Server, в которой одна из таблиц содержала 200 000 строк.Я использовал Guid в качестве первичного ключа в этой базе данных, а НЕ в качестве последовательного руководства.У меня не было проблем с производительностью в этой системе, в которой было около 30 одновременно работающих пользователей.

Недавно я спроектировал и разработал среду разработки корпоративных приложений.Чтобы воспользоваться преимуществом шаблона «Единица работы», я использовал последовательный гид в качестве первичного ключа, чтобы записи были упорядочены физически.Поскольку мой опыт работы с большими базами данных ограничен тем, что я только что упомянул, я серьезно обеспокоен, буду ли я использовать эту среду для разработки корпоративного приложения для большой организации с 1000 одновременно работающих пользователей, которые будут хранить миллионы записей.данных с использованием последовательного руководства в качестве первичного ключа приведет к проблемам с производительностью?

Если да, то в какой степени?И еще раз, если да, можно ли решить эту проблему путем улучшения аппаратного обеспечения сервера базы данных (процессора и ОЗУ), а затем еще раз до какой степени?

Заранее благодарим за то, что поделились своим опытом и знаниями

Answer 1

Проблема последовательного идентификатора GUID в сравнении с «обычными» идентификаторами GUID возникает в следующих случаях:

• Столбец GUID является частью первичного или кластерного индекса (особенно единственного ключа в индексе).
• В вашей базе данных имеется "множество" вставок.

Для кластеризованного индекса SQL Server добавляет новые записи в таблицу "по порядку".Таким образом, большие значения идут в конце таблицы, в данном случае на последней странице данных.Это удобно для столбцов идентификаторов, поскольку они гарантированно будут больше любого предыдущего значения.И последняя страница данных - по определению - не фрагментирована.

GUID не имеют этого свойства.В итоге они вставляются «посередине», вызывая фрагментацию.

Почему вы не видите в этом проблемы?Причины могут быть разными:

• Ваше приложение выполняет мало операций вставки.
• Вы регулярно дефрагментируете таблицу.
• Таблица такая маленькаячто это почти не имеет значения.

Что касается последнего пункта, если записи достаточно малы, то на каждой странице может появиться более тысячи.С 200 страницами данных фрагментация не может быть существенной проблемой.

При 30 одновременных пользователях вы можете просто не перекрывать транзакции.Если каждый пользователь изменяет базу данных один раз в минуту, это дает вам 2 секунды для завершения транзакции - обычно вполне достаточно времени.

Тем не менее, я рекомендую использовать последовательный GUID или столбец идентификаторов.Это сохранит чистоту базы данных.Тем не менее, регулярная дефрагментация базы данных является еще одним вариантом, который может работать.

Answer 2

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

Вам действительно нужно разделить две проблемы:

1. Первичный ключ представляет собой логическую конструкцию - один из ключей-кандидатов, который однозначно и надежно идентифицирует каждыйстрока в вашей таблице.На самом деле это может быть что угодно - INT, GUID, строка - выберите наиболее подходящий для вашего сценария.

2. Ключ кластеризации (столбец или столбцы, которые определяют «кластеризованный индекс» в таблице) - это физическая вещь, связанная с хранением, и здесь ваш маленький, стабильный, постоянно увеличивающийся тип данных - ваш лучший выбор -INT или BIGINT как вариант по умолчанию.

По умолчанию первичный ключ в таблице SQL Server также используется в качестве ключа кластеризации, но это не обязательно должно быть так!Я лично наблюдал значительное увеличение производительности, когда разбивал предыдущий первичный / кластеризованный ключ на основе GUID на два отдельных ключа - первичный (логический) ключ на GUID и ключ кластеризации (упорядочения) на отдельном INT IDENTITY(1,1)колонка.

Как Кимберли Трипп - Королева индексации - и другие неоднократно заявляли - GUID, поскольку ключ кластеризации не является оптимальным, посколькуиз-за своей случайности это приведет к массовой фрагментации страниц и индексов и в целом к ​​плохой производительности.

Да, я знаю - в SQL Server 2005 и более поздних версиях newsequentialid(), но даже это не совсем и полностьюпоследовательный и, следовательно, также страдает от тех же проблем, что и GUID - чуть менее заметно.

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

Быстрый расчет - использование INT против GUID в качестве основного и кластерного ключа:

• Базовая таблица с 1 000 000 строк (3,8 МБ против 15,26 МБ)
• 6 некластеризованных индексов (22,89 МБ против 91,55 МБ)

ИТОГО: 25 МБ против 106 МБ - и это только на одной таблице!

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

Еще немного пищи для размышлений - отличноматериал Кимберли Трипп - читай, читай снова, переваривай!На самом деле это Евангелие для индексирования SQL Server.

• Идентификаторы GUID в качестве PRIMARY KEY и / или кластеризованного ключа
• Обсуждение кластерного индекса продолжается
• Постоянно увеличивающийся ключ кластеризации - дебаты по кластерному индексу .......... снова!
• Дисковое пространство дешево - это не точка!