Что такое последовательный GUID?

#sql #база_данных #терминология

Кроме обычных GUID существуют также последовательные (sequential) GUID.

В частности, они могут использоваться как ключи в базах данных.

Что они из себя представляют?
Какие у них достоинства и недостатки по сравнению с обычными?
    

Ответы

Ответ 1

Мой вольный перевод GUID vs.Sequential GUID

Классическим паттерном является использование Guid в качестве первичного ключа (PK),
но, как упоминается в различных дискуссиях see Advantages and disadvantages of GUID
/ UUID database keys есть некоторые проблемы с производительностью.

Это обычная последовательность Guid

f3818d69-2552-40b7-a403-01a6db4552f7
7ce31615-fafb-42c4-b317-40d21a6a3c60
94732fc7-768e-4cf2-9107-f0953f6795a5


Проблемы такого типа данных:


Широкий диапазон значений
Практически случайные значения
Трудности с использованием индексов
"A lot of leaf moving" *Я полагаю, автор имеет ввиду структуру индексов в базе. Когда
много рандомных значений, 
древо индексов получается слишком плоским, с большим количеством терминальных узлов(не
имеющих дочерних узлов). Такие индексы ухудшают производительность.
Почти каждый PK должен иметь как минимум некластеризованный индекс.
Проблема возникает как на Oracle, так и на SQL Server.


Возможное решение - использовать Sequential Guid, который генерируется следующим образом:

cc6466f7-1066-11dd-acb6-005056c00008
cc6466f8-1066-11dd-acb6-005056c00008
cc6466f9-1066-11dd-acb6-005056c00008


Как сгенерировать их из кода C #:

[DllImport("rpcrt4.dll", SetLastError = true)]
static extern int UuidCreateSequential(out Guid guid);

public static Guid SequentialGuid()
{
    const int RPC_S_OK = 0;
    Guid g;
    if (UuidCreateSequential(out g) != RPC_S_OK)
        return Guid.NewGuid();
    else
        return g;
}


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


Лучшая производительность индексов
Допускается использование кластерных индексов
Меньшая загрузка накопителя
20-25% прироста производительности при минимальных затратах


Измерение в реальной жизни.
Сценарий:

Guid хранится как UniqueIdentifier types на SQL Server. 
Guid хранится как CHAR(36) на Oracle. 
Много insert операций, объединённых в одну транзакцию. 
От 1 до 100 вставок в зависимости от таблицы. 
Некоторые таблицы имеют > 10 миллионов строк. 

Лабораторный тест - SQL Server

VS2008 test, 10 одновременных пользователей, без задержки, тестовый процесс с 600
вставками в листовую таблицу(не имеющую дочерних таблиц)  

Обычный Guid
Avg. Process duration: 10.5 sec
Avg. Request for second: 54.6
Avg. Resp. Time: 0.26  

Sequential Guid
Avg. Process duration: 4.6 sec
Avg. Request for second: 87.1
Avg. Resp. Time: 0.12  

Результат на Oracle 1.327.613 вставок в таблицу с Guid PK

Обычный Guid, 0.02 сек. требуется для одной вставки, 2.861 сек. времени процессора,
всего 31.049 сек. потребовалось

Sequential Guid, 0.00 сек. требуется для одной вставки, 1.142 сек. времени процессора,
всего 31.049 сек. потребовалось

Последовательное чтения файла из BD.
Было: 6.4 миллионов задержек и 62.415 секунд.
Стало: 1.2 миллиона задержек и 11.063 секунд.

Важно понимать, что все Sequential Guid могут быть угаданы, не используйте их если
вам важна безопасность.