Преимущества и недостатки ключей базы данных GUID / UUID

Question

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

Кто-нибудь интенсивно работал с GUID в базе данных? Какие преимущества я получу, пройдя этот путь, и каковы возможные подводные камни?

Answer 1

Преимущества:

• Может генерировать их в автономном режиме.
• Делает репликацию тривиальной (в отличие от int, что делает ее действительно трудной)
• ORM обычно нравятся им
• Уникальный для разных приложений. Таким образом, мы можем использовать ПК из нашей CMS (guid) в нашем приложении (также guid) и знать, что мы НИКОГДА не получим столкновение.

Недостатки:

• Пространство больше, но пространство дешевое (er)
• Невозможно заказать по идентификатору, чтобы получить заказ на вставку.
• Может выглядеть уродливо в URL, но на самом деле, WTF вы делаете, вставляя РЕАЛЬНЫЙ ключ DB в URL!?
• Труднее выполнять ручную отладку, но не так сложно.

Лично я использую их для большинства ПК в любой системе приличного размера, но я "обучен" системе, которая была воспроизведена повсеместно, поэтому мы ДОЛЖНЫ иметь их. YMMV.

Я думаю, что дублирование данных - это чушь - вы можете получить дубликаты данных, как бы вы это ни делали. Суррогатные ключи обычно не одобряются, где бы я ни работал. Мы действительно используем WordPress-подобную систему, хотя:

• уникальный идентификатор строки (GUID / что угодно). Никогда не виден пользователю.
• открытый идентификатор генерируется ОДИН РАЗ из некоторого поля (например, заголовок - сделать его заголовком статьи)

UPDATE: Так что этот получает +1, и я подумал, что должен указать на большой недостаток PK GUID: кластерные индексы.

Если у вас много записей и кластеризованный индекс по GUID, ваша производительность вставки снизится, так как вы вставляете вставки в случайных местах в списке элементов (вот и все), а не в конце (то есть быстрый)

Так что, если вам нужно вставить производительность, возможно, используйте auto-inc INT и сгенерируйте GUID, если вы хотите поделиться им с кем-то еще (то есть показать его пользователю в URL)

Answer 2

@ Мэтт Шеппард:

Скажем, у вас есть таблица клиентов. Конечно, вы не хотите, чтобы клиент присутствовал в таблице более одного раза, иначе в ваших отделах продаж и логистики возникнет путаница (особенно если несколько строк о клиенте содержат разную информацию).

Таким образом, у вас есть идентификатор клиента, который уникально идентифицирует клиента, и вы удостоверяетесь, что этот идентификатор известен клиенту (в счетах), так что клиент и сотрудники службы поддержки клиентов имеют общую ссылку на случай, если им нужно будет связаться , Чтобы гарантировать отсутствие дублированных записей о клиентах, вы добавляете в таблицу ограничение уникальности либо через первичный ключ идентификатора клиента, либо через ограничение NOT NULL + UNIQUE для столбца идентификатора клиента.

Затем, по какой-то причине (о которой я не могу думать), вас просят добавить столбец GUID в таблицу клиентов и сделать его первичным ключом. Если столбец идентификатора клиента теперь оставлен без гарантии уникальности, вы просите о будущих проблемах во всей организации, поскольку идентификаторы GUID всегда будут уникальными.

Некоторые «архитекторы» могут сказать вам, что «о, но мы обрабатываем ограничение real уникальности клиентов в нашем уровне приложения!». Правильно. Мода на эти языки программирования общего назначения и (особенно) среды среднего уровня постоянно меняется и, как правило, никогда не превзойдет вашу базу данных. И есть очень хороший шанс, что в какой-то момент вам понадобится получить доступ к базе данных без прохождения настоящего приложения. == Проблема. (Но, к счастью, вы и «архитектор» давно ушли, поэтому вас не будет там, чтобы навести порядок.) Другими словами: сохраняйте очевидные ограничения в базе данных (и на других уровнях, если у вас есть) время).

Другими словами: могут быть веские причины для добавления столбцов GUID в таблицы, но, пожалуйста, не поддавайтесь искушению сделать так, что это снизит ваши амбиции для согласованности в пределах real (== GUID) информация.

Answer 3

Основным преимуществом является то, что вы можете создавать уникальные идентификаторы без подключения к базе данных. А идентификаторы глобально уникальны, поэтому вы можете легко объединять данные из разных баз данных. Это кажется небольшим преимуществом, но в прошлом я сэкономил много работы.

Основные недостатки: немного больше места для хранения (это не проблема в современных системах), а идентификаторы не читаются человеком. Это может быть проблемой при отладке.

Есть некоторые проблемы с производительностью, такие как фрагментация индекса. Но это легко решаемо (расчёты от Джимми Ниллсона: http://www.informit.com/articles/article.aspx?p=25862)

Редактировать объединил два моих ответа на этот вопрос

@ Мэтт Шеппард Я думаю, он имеет в виду, что вы можете дублировать строки с разными идентификаторами GUID в качестве первичных ключей. Это проблема любого суррогатного ключа, а не только GUID. И, как он сказал, это легко решается добавлением значимых уникальных ограничений в неключевые столбцы. Альтернативой является использование естественного ключа, и у него есть реальные проблемы.

Answer 4

Почему никто не упоминает производительность? Когда у вас есть несколько объединений, все на основе этих неприятных GUID, производительность будет проходить через этаж, там: (

Answer 5

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

Answer 6

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

Answer 7

первичные ключи-идентификаторы Версус * GUID, 1002 *

Стоимость GUID в качестве первичных ключей (SQL Server 2000)

Мифы, GUID и автоинкремент (MySQL 5)

Это действительно то, что вы хотите.

UID Pros

• Уникальный для каждой таблицы, каждой базы данных, каждого сервера
• Позволяет легко объединять записи из разных баз данных
• Позволяет легко распределять базы данных по нескольким серверам
• Вы можете генерировать идентификаторы где угодно, вместо того, чтобы обращаться к базе данных туда и обратно
• В большинстве сценариев репликации все равно требуются столбцы GUID

GUID Минусы

• Это в 4 раза больше, чем у традиционного 4-байтового значения индекса; это может иметь серьезные последствия для производительности и хранения, если вы не будете осторожны
• громоздкий для отладки (где userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• Сгенерированные GUID должны быть частично последовательными для лучшей производительности (например, newsequentialid () в SQL 2005) и для возможности использования кластерных индексов

Answer 8

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

RDBM обычно обеспечивают уникальность первичных ключей и обеспечивают поиск по ключу в структуре, называемой BTree, которая представляет собой дерево поиска с большим коэффициентом ветвления (двоичное дерево поиска имеет коэффициент ветвления 2). Теперь последовательный целочисленный идентификатор может привести к тому, что вставки будут происходить только на одной стороне дерева, оставляя большинство листовых узлов нетронутыми. Добавление случайных UUID приведет к тому, что вставки разделят конечные узлы по всему индексу.

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