Создание GUID с помощью ASP iiS
В этой статье приводится информация о создании нескольких страниц примера с помощью различных форм GUID для ASP страниц ASP. Эти значения можно использовать для создания уникальных записей данных в базе данных или в любом другом месте, где требуется уникальное поле данных.
Оригинальная версия продукта: службы IIS
Исходный номер КБ: 320375
Поскольку в этих примерах не используются переменные сеанса, эти примеры также работают на веб-серверах, отключенных в состоянии сеанса.
Создание простого GUID на основе времени
В этом примере создается простой GUID на основе времени 14 символов с помощью текущего года, месяца, дня, часа, минуты и секунд. Это позволяет сортировать данные на основе GUID.
Выберите Начните, указать на программы, выберите аксессуары, а затем выберите Блокнот, чтобы открыть Блокнот.
Введите или введите следующий код ASP в Блокнот:
- В меню Файл нажмите Сохранить.
- Найдите корневую папку для веб-сайта, которая обычно является папкой C:\InetPub\Wwwroot для веб-сайта по умолчанию.
- Назови файл GuidTest0.asp.
- Нажмите Сохранить.
- В меню Файл выберите Выход.
Найдите страницу с помощью Internet Explorer. Вы видите GUID. При обновлении страницы вы увидите приращение GUID.
Создание простого GUID с смещением времени
В этом примере создается GUID на основе времени в 20 символов с помощью смещения в секундах с 12:00 полуночи 1 января 2000 г. Это позволяет сортировать данные на основе GUID и может быть обновлено, чтобы использовать любую другую дату в качестве базы.
Выберите Начните, указать на программы, выберите аксессуары, а затем выберите Блокнот, чтобы открыть Блокнот.
Введите или введите следующий код ASP в Блокнот:
- В меню Файл нажмите Сохранить.
- Найдите корневую папку для веб-сайта, которая обычно является папкой C:\InetPub\Wwwroot для веб-сайта по умолчанию.
- Назови файл GuidTest1.asp.
- Нажмите Сохранить.
- В меню Файл выберите Выход.
Найдите страницу с помощью Internet Explorer. Вы видите GUID. При обновлении страницы вы увидите приращение GUID.
В этом примере допускается уникальность только в том случае, если функция не называется два раза в одной секунде. Любые два вызова к функции в одно и то же время вызывают столкновение. Это может не вызывать проблем в зависимости от того, как код использует функцию, но вы можете использовать уникальный пример GUID с смещением времени, чтобы разрешить уникальные значения, которые возникают в ту же секунду.
Создание более уникального GUID с смещением времени
В этом примере, например в примере Create a simple time-offset GUID, создается GUID на основе времени, но он составляет 25 символов. В этом примере создается значение 20 символов из смещения в секундах с 12:00 полуночи 1 января 2000 г., а к концу этого приложения добавлено еще пять случайных чисел. Это позволяет сортировать данные на основе GUID, но позволяет значительно большей уникальности. Это может быть обновлено, чтобы использовать любую другую дату в качестве базы.
Выберите Начните, указать на программы, выберите аксессуары, а затем выберите Блокнот, чтобы открыть Блокнот.
Введите или введите следующий код ASP в Блокнот:
- В меню Файл нажмите Сохранить.
- Найдите корневую папку для веб-сайта, которая обычно является папкой C:\InetPub\Wwwroot для веб-сайта по умолчанию.
- Назови файл GuidTest2.asp.
- Нажмите Сохранить.
- В меню Файл выберите Выход.
Найдите страницу с помощью Internet Explorer. Вы видите GUID. При обновлении страницы вы увидите первые 20 символов приращения GUID, а последние пять символов случайны.
Этот пример и простой пример GUID с смещением времени создаются для сериализации вызовов к функции на основе CreateGUID времени. Если сортировка данных в зависимости от времени не является требованием, для создания случайного GUID можно использовать простой случайный пример GUID.
Создание простого случайного GUID
Выберите Начните, указать на программы, выберите аксессуары, а затем выберите Блокнот, чтобы открыть Блокнот.
Введите или введите следующий код ASP в Блокнот:
- В меню Файл нажмите Сохранить.
- Найдите корневую папку для веб-сайта, которая обычно является папкой C:\InetPub\Wwwroot для веб-сайта по умолчанию.
- Назови файл GuidTest3.asp.
- Нажмите Сохранить.
- В меню Файл выберите Выход.
Найдите страницу с помощью Internet Explorer. Вы видите случайный GUID с 20-символами. Обновив страницу, вы увидите случайное изменение значения.
В этом примере создается случайный GUID фиксированной длины. Чтобы создать GUID переменной длины, используйте пример Create a variable-length random GUID.
Создание случайного GUID с переменной длиной
Выберите Начните, указать на программы, выберите аксессуары, а затем выберите Блокнот, чтобы открыть Блокнот.
Введите или введите следующий код ASP в Блокнот:
- В меню Файл нажмите Сохранить.
- Найдите корневую папку для веб-сайта, которая обычно является папкой C:\InetPub\Wwwroot для веб-сайта по умолчанию.
- Назови файл GuidTest4.asp.
- Нажмите Сохранить.
- В меню Файл выберите Выход.
Найдите страницу с помощью Internet Explorer. Вы видите 10-символ, 25-символ и 50-символ случайный GUID. При обновлении страницы вы увидите, как значения изменяются случайным образом.
В этом примере и в примере Создания простого случайного GUID создаются строки сконструированных случайных символов. Пример GUID в стиле Windows расширяет эту функцию, чтобы создать GUID, форматированный как Windows GUID.
Создание случайного GUID в стиле Windows
Windows использует GUID,когда регистрирует ID класса для компонентов и других объектов, но GUID можно использовать для чего угодно. Windows GUID — это длинные строки форматируемых hexadecimal символов, что означает, что они используют числа от 0 до 9 и буквы A через F. (Microsoft Access также имеет встроенный ID репликации в том же формате.) В этом примере показано, как использовать код, аналогичный коду Create a variable-length random GUID example code to create a GUID like a Windows GUID.
Выберите Начните, указать на программы, выберите аксессуары, а затем выберите Блокнот, чтобы открыть Блокнот.
Введите или введите следующий код ASP в Блокнот:
- В меню Файл нажмите Сохранить.
- Найдите корневую папку для веб-сайта, которая обычно является папкой C:\InetPub\Wwwroot для веб-сайта по умолчанию.
- Назови файл GuidTest5.asp.
- Нажмите Сохранить.
- В меню Файл выберите Выход.
Найдите страницу с помощью Internet Explorer. Вы видите случайный GUID, форматированный как Windows GUID. Обновив страницу, вы увидите случайное изменение значения.
Создание более сильного случайного GUID в стиле Windows
Поскольку Windows GUID используют шестиугольные числа для каждого символа, для каждого символа в GUID можно использовать 16 значений. Если расширить значения, включив весь алфавит, можно получить 36 значений для каждого символа в GUID. В этом примере используется функция из примера GUID переменной длины для создания GUID в том же формате, что и Windows GUID.
Выберите Начните, указать на программы, выберите аксессуары, а затем выберите Блокнот, чтобы открыть Блокнот.
Введите или введите следующий код ASP в Блокнот:
- В меню Файл нажмите Сохранить.
- Найдите корневую папку для веб-сайта, которая обычно является папкой C:\InetPub\Wwwroot для веб-сайта по умолчанию.
- Назови файл GuidTest6.asp.
- Нажмите Сохранить.
- В меню Файл выберите Выход.
Найдите страницу с помощью Internet Explorer. Вы видите случайный GUID, форматированный как Windows GUID. Обновив страницу, вы увидите случайное изменение значения.
Эффективная генерация сортируемых GUID для первичных ключей БД на клиенте
Использовать Guid.NewGuid() в качестве первичного ключа в базе данных — плохая с точки зрения производительности идея. Это связано с тем, что в SQL Server, MySQL и некоторых других БД для первичных ключей создаются кластерные индексы, которые определяют, как строки будут храниться на диске. GUID — это по сути случайное значение, поэтому новая строка может попасть в начало, середину или конец таблицы. Серверу БД в этом случае придётся перемещать другие строки, что приведёт к фрагментации данных, а их извлечение может занять больше времени, если вам нужно извлечь несколько добавленных последовательно записей (например, когда вы добавляете набор связанных сущностей, которые потом будут извлекаться вместе — БД понадобится прочитать данные из разрозненных страниц вместо последовательного чтения набора данных).
Поэтому, чаще всего, лучше пользоваться сгенерированными БД первичными ключами. В SQL Server, например, есть функция NEWSEQUENTIALID() , которая генерирует последовательные GUIDы. Зачем может понадобиться генерировать ключи именно на клиенте и как это правильно сделать?
Проблема
Для создания первичных ключей сущности большинство людей прибегают к одному из следующих подходов:
Использование в качестве первичного ключа int и генерация таких ключей базой данных при вставке новой строки.
Использование GUID и опции генерации на уровне БД.
Самостоятельная генерация GUID в своём приложении и вставка строки с этим идентификатором.
Чтобы дать немного контекста и выяснить, почему вам могут понадобиться последовательные GUID, рассмотрим плюсы и минусы каждого из вышеперечисленных подходов к созданию первичных ключей.
Генерируемый БД Integer в качестве идентификатора
Первый вариант, позволяющий базе данных автоматически генерировать целочисленный первичный ключ, является очень заманчивым подходом; долгое время, особенно в монолитных системах, это было подходом по умолчанию, который удобно интегрировался с ORM. Одна из его приятных особенностей — первичные ключи получают красивые, монотонно возрастающие (и обычно последовательные) идентификаторы.
Это упрощает работу с тестовыми данными и поддержку, когда идентификаторы используюстя в URL-адресах: можно запомнить ID нужной сущности, быстро получить её в коде или по адресу, вбив нужный идентификатор:
Какие недостатки у таких ключей?
Во-первых, подход с генерацией ключей в базе данных затрудняет или делает невозможным использование некоторых паттернов проектирования. Например, общий подход к идемпотентности заключается в создании идентификатора на клиенте и отправке его в запросе. Это позволяет легко устранять дублирование и гарантирует, что вы не вставите один и тот же объект дважды, так как легко обнаружить повторяющиеся запросы на вставку. Такой подход обычно невозможен с идентификаторами, сгенерированными базой данных.
Во-вторых, это усложняет код INSERT, поскольку вы должны убедиться, что возвращаете сгенерированные идентификаторы. EntityFramework под капотом назначает ID сущностям после вставки, но в случае с Dapper вам придётся делать это самим.
Третья проблема возникает только в высоконагруженных приложениях — при вставке большого количества строк БД должна блокировать генератор идентификаторов чтобы избежать использования одного ID несколькими сущностями, это может стать узким местом в приложении. Если БД масштабируется и используется master-master репликация, то всё становится ещё сложнее — в разных БД существуют разные настройки, которые могут генерировать записи с пропусками (например, первый сервер будет генерировать только нечетные идентификаторы, а второй только четные) или генерировать идентификаторы из разных подмножеств.
Резимуруя этот подход:
Читаемые и запоминаемые URL.
Проблемы с идемпотентностью.
В некоторых случаях нужно дополнительно озаботиться возвращением идентификаторов при вставке.
Снижение производительности в высококонкурентной среде.
Генерируемый БД GUID в качестве идентификатора
При использовании сгенерированных БД гуидов мы можем избавиться от части проблем — например, NEWSEQUENTIALID() использует для генерации значений данные оборудования (MAC-адрес сетевой карты и «идентификатор часов»), поэтому сгенерированный с помощью неё иденитфикатор остается глобально уникальным. Это избавляет от необходимости дополнительной настройки генерации последовательности иденификаторов при репликации.
Функция генерирует корректно сортируемые последовательности, так что данные будут вставляться последовательно, а при слиянии данных с нескольких реплик эти данные так же будут локально последовательными.
В MySQL функция UUID() генерирует UUID версии 1, что делает их так же частично сортируемыми.
Стоит сразу заметить, что в PostgreSQL данные хранятся иначе, поэтому использование непоследовательных GUID не влияет катастрофически на производительность базы данных.
В случае генерируемых БД идентификаторов мы всё ещё вынуждены мириться с сложностью реализации идемпотентности в запросах и необходимостью заботиться о возвращении идентификаторов при вставке. Также тот факт, что гуиды являются 128-битными значениями по сравнению с 32-битными целыми числами, приводит к увеличению общего размера данных.
Генерируемый клиентом GUID в качестве идентификатора
Решение проблем генеририуемых БД первичных ключей заключается в использовании созданных клиентом идентификаторов. У этого подхода тоже есть различные плюсы и минусы!
Одним из преимуществ является то, что это просто. Все современные языки имеют доступные генераторы GUID; в .NET это метод Guid.NewGuid() , который возвращает случайный 128-битный идентификатор.
Вы можете установить это значение в качестве ID для добавляемой сущности, и вам не нужно беспокоиться о проверке, с каким идентификатором она была добавлена в БД. Используете ли вы EF Core или Dapper, Postgres или SqlServer, код будет одинаковым. Данные при запросе на вставку перемещаются только в одном направлении, от клиента к базе данных, а не в двух направлениях, как в случае с генерируемым БД первичным ключом.
Если вы создаете идентификаторы в своем клиентском коде, у вас теперь есть доступ к различным шаблонам идемпотентности. Например, представьте, что вы включаете GUID в запрос, но запрос завершается сбоем из-за ошибки сервера. Вы можете просто отправить тот же запрос еще раз, зная, что сервер сможет идентифицировать его как «дубликат», поэтому ему нужно только повторить часть действия, которое привело к ошибке или просто вернуть ответ об успешном создании сущности. Таким образом, вы можете избежать создания дубликатов.
Уникальность гуидов — это и их сильные стороны, и их слабость. С точки зрения разработчика и пользователя, с /book/55DE358F-45F1-E311-93EA-00269E58F20D работать не так просто, как с /book/1 .
Тип Guid в .NET реализует UUID версии 4, то есть генерируемый полностью случайным образом идентификатор. С точки зрения базы данных эта случайность может вызвать большие проблемы. Случайность идентификаторов может привести к серьезной фрагментации индекса, что увеличивает размер вашей базы данных и влияет на общую производительность.
Если подводить итог для опции генерируемого на клиенте GUID, то получится следующее:
Легко использовать и код остаётся универсальным при переходе между разными БД.
Позволяет сделать запросы идемпотентными без дополнительного уровня абстракции.
Нет необходимости читать значения из БД после вставки.
Больший объем данных по сравнению с целочисленными идентификаторами.
Могут вызвать проблемы с производительностью БД из-за фрегментации индекса.
Преимущества сортируемого GUID
У гуидов есть несколько преимуществ, и, кроме проблем с человекочитаемостью, один большой недостаток с фрагментацией индекса, вызванной их полной случайностью. А нам всего-то и нужен сортируемый последовательно-возрастающий глобально-уникальный идентификатор чтобы использовать его в качестве ключа. Где его взять?
Самый простой ответ — нам нужен тот самый UUID версии 1, который используется функциями БД для генерации идентификаторов. Но есть несколько проблем. В BCL нет полной реализации RFC 4211, и, судя по комментариям в github дотнета, такую поддержку прямо сейчас добавлять не планируется. Если поискать по nuget-пакетам, то какого-то одного стандарта де-факто, который бы активно использовался и поддерживался сообществом тоже нет. Я нашёл библиотеку Vlingo.Xoom.UUID, которая завляет поддержку RFC 4211. Ещё один способ из хабростатьи про GUID в качестве первичных ключей предлагает использовать DllImport к библиотеке, которая используется SQL Server для генерации идентификаторов — такой способ вызовет очевидную проблему с переносимостью.
Но у UUID версии 1 на мой взгляд есть недостатки на уровне самого стандарта. Во-первых, для метки времени используется количество 100-наносекундных интервалов, прошедших с 15 октября 1582 года. Это совсем не то, как мы привыкли думать о timestamp в нашем повседневном программировнии. Во-вторых, в случае с UUID версии 1 метка времени внутри идентификатора частично перевернута, то есть старшие биты таймстампа сдвинуты к младшим битам в самом UUID. Это объясняет тот факт, что в примере с NEWSEQUENTIALID() менялись именно старшие разряды идентификатора. Такой порядок делает лексикографическое упорядочивание немного бессмысленным.
Мы могли бы просто переставить биты внутри UUID и вернуть время и упорядоченность к изначальному виду от старших бит к младшим, но это дополнительное усложение, которое всё ещё предполагает использовать непривычный timestamp совсеместно с дополнительной логикой защиты от коллизий (в случае, если в 100нс интервал генерируется несколько идентификаторов). Хочется чего-то более нативного.
Отличные новости — для решения этой задачи 31 марта 2022 года на сайте IETF был официально размещен текст рабочего документа с новыми форматами UUID, специально предназначенными для использования в высоконагруженных приложениях и базах данных — возрастающие по времени, создержащие timestamp, счетчик с инициализацией его сегментов нулем и псевдослучайным значением, а также собственно псевдослучайное значение. Стандарт ещё не принят, но уже сейчас можно найти первые реализации библиотек для UUID версии 7.
Ещё одна хорошая новость — есть библиотека NewId, которая позволяет генерировать лексикографически упорядоченные по времени создания идентификаторы и тоже создана как раз для первичных идентификаторов. Сама библиотека основана на Snowflake_ID, который разработан специально для использования в распределенных системах, и Flake, который развивает идеи UUID версии 1. Самый простой способ понять, что это значит, — показать, как выглядят идентификаторы, сгенерированные NewId.
Пример результата работы программы:
NewId использует в качестве данных для создания идентификатора 3 источника:
Worker/process ID, который отвечает за уникальность между процессами/сервером — именно он отвечает за общую для всех идентификаторов часть, а идентификатор конкретного процесса можно включить дополнительно для избежания коллизий между процессами в рамках одной машины.
Timestamp, который обеспечивает сортируемость идентификатора.
Последовательно возрастающий идентификатор.
Объединив 3 части вместе, вы можете получить идентификатор, который будет частично отсортированным благодаря компоненту метки времени. Включив идентификатор процесса, можно избежать коллизий при генерации идентификаторов несколькими процессами. А использование части с последовательно возрастающим идентификатором позволяет генерировать 2^16-1 идентификаторов в миллисекунду в рамках одного процесса:
Иллюстрация «Flake» ID из поста об этом идентификаторе. NewId основан на том же подходе.
На сколько же NewId снижает фрагментацию индекса?
Сравнение фрагментации индекса при использовании разных генераторов UUID
В сравнительном эксперементе я решил сравнить степень фрагментации и плотность данных от несколько генераторов UUID в качестве первичных ключей:
[DllImport(«rpcrt4.dll», SetLastError = true)]
Vlingo.UUID.TimeBasedGenerator.GenerateGuid c опцией GuidGenerationMode.WithUniquenessGuarantee
В тесте для простой таблицы с идентификатором и текстовым полем будет добавляться 10 тысяч записей, каждая с случайной задержкой 100-500 миллисекунд, таким образом в идентификаторе будут участвовать таймштампы за 50 минут одного дня.
NewId, по-видимому, в значительной степени ориентирован на сервер SQL Server. Поэтому, и потому, что для MySQL я не нашёл понятного способа измерить фрагментацию данных и эффективность использования дискового пространства, тесты проводились именно на SQL Server.
Развернем Docker-образ SQL Server:
Создадим 5 простых таблиц для разных типов сгенерированных идентификаторов:
Создадим в таблицах тестовые данные при помощи старого-доброго ADO.NET:
Чтобы посмотреть размер каждого индекса и его фрагментацию, используем стащенный из этой статьи запрос:
Полученные данные легко объяснить из информации, которую мы уже знаем. Во-первых, сгенерированные случайно идентификаторы приводят к большой фрагментации данных поскольку новые элементы вставляются на случайную позицию. NewId вызвали только 5-процентную фрагментацию, а Vlingo.UUID всего 3-процентную фрагментацию. Ещё при использовании Guid остается больше пустого места на каждый странице с данными (возможно, из-за постоянных перемещений данных во время вставки), поэтому вам нужно больше страниц для хранения того же объема данных (81 против 59). Это тоже станет источником некоторого снижения производительности при использовании гуидов. Что касается UUID версии 7, то остается только думать, что способ, которым SQL Server сортирует ключи не совсем совместим с новым форматом.
Но на самом деле влияние фрагментации при чтении данных совсем не так велико, как может представляться — скорее можно назвать его незначительным. Вот пример замера производительности при чтении 10.000 записей и 100.000 записей в запросе:
Настоящая проблема c производительностью гуидов начинается в больших таблицах при вставке данных — потому что индекс перестраивается случайным образом, а сервер БД не может сделать предсказания для следующего набора данных. Один из бенчмарков сравнивает производительность добавления 5 миллионов записей батч-запросами по 100.000 записей каждая в таблицу c автоинкрементным целым ключом, UUID версии 1, 4 или подхаченной «последовательной» версии 4 после манипуляции с битами. По результатам видно, что после полутора миллионов записей UUID версии 4 начинает деградировать, а время вставки быстро растет:
В другом бенчмарке сравнивается добавление записей в БД, где ключи генерируются разными функциями SQL: uuid_generate_v4() , uuid_time_nextval() и uuid_sequence_nextval() с разным набором параметров. Тесты проводятся в трёх условиях: на изначально пустой таблице, помещающейся в оперативную память таблице и явно не влезающей в оперативную память таблице. С ростом объёма данных тоже видно значительное снижение скорости добавления новых данных:
Выводы
Библиотеки NewId и Vlingo.UUID явно делают свою работу. Первая создана и развивается специально для решения проблемы с первичными ключами в базах данных, где данные строк хранятся в кластерных индексах. Вторая — утилитарный пакет платформы XOOM компании Vlingo и не имеет даже публичной документации.
Стоит ли его использовать? Ответ, как обычно — «зависит». Но это точно хорошая альтернатива, если вам нужно генерировать первичные ключи на клиенте и работать с MySQL или MS SQL Server.
Как создать уникальный идентификатор в C#?
Уникальные идентификаторы используются довольно при разработке программного обеспечения. Например, в URL различных сервисов, для индексирования каких-либо данных и так далее. При этом, практически каждый программист использует свой собственный подход к созданию идентификатора в зависимости от того, какие цели преследуются. Например, идентификатор может содержать какие-либо полезные данные (дата создания элемента, другие идентификаторы и т.д.). Здесь я рассмотрю несколько вариантов создания уникальных идентификаторов с использованием C#.
Как в C# сгенерировать уникальный идентификатор?
Создание идентификатора с использованием GUID
GUID (Globally Unique Identifier) — статистически уникальный 128-битный идентификатор. Его главная особенность — уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов.
Это, по-видимому, самый простой и первый приходящий на ум способ сгенерировать уникальный идентификатор в C#. Реализация способа также довольно простая:
Сгенерирует идентификатор следующего вида: 646f7719-74a5-47af-a2b9-3e99665e0000
также можно применить к строке идентификатора формат, например,
в результате чего сформируется уникальный идентификатор вида: 6fcede5dfacf4ec2aa49ee9d3f0976d9
Создание идентификатора с использованием DateTime.Tiks
Способ менее надежный и не гарантирует, что полученный идентификатор будет иметь строго определенную длину, но, тем не менее, тоже может использоваться.
Суть использования этого способа — посчитать число тактов от какого-либо события. Например, код:
сгенерирует числовой идентификатор вида: 656710825752
Можно также придумать различные вариации этого способа, например, рассчитывать не количество тактов, а количество секунда, наносекунд и т.д.
Использование возможностей LINQ для создания уникального идентификатора
Представленный ниже код генерирует уникальный идентификатор по типу идентификаторов YouTube:
Этот код сгенерирует уникальный 12-тизначный идентификатор вида: UcBKmq2XE5aА. Количество символов можно отрегулировать, изменив значение параметра Take(). По утверждению автора этого кода создается 0,001% дубликатов на 100 миллионов вызовов.