Генерация идентификатора для защищенной базы данных (база данных объединения Azure)

Question

Я искал некоторые статьи или рекомендации по передовой практике создания идентификаторов (для федеративного / первичного ключа) для федеративных баз данных Azure и не нашел ничего убедительного. Объединенные таблицы не поддерживают столбцы идентификаторов, поэтому мне кажется, что единственный практический тип идентификатора - это GUID, поскольку попытка централизованно создать и использовать BigInt создает единую точку отказа в приложении. Моя главная проблема - это влияние на производительность использования GUID над BigInts (особенно для индексации таблиц).

Есть ли рекомендуемые / лучшие практики (или существующие библиотеки) для создания уникальных BigInts для распределенной системы (или мне не следует беспокоиться о влиянии производительности на использование GUID?).

[Update]

Прочитав об этом больше после публикации вопроса, мне кажется, что генерация ключей будет проблемой в Azure. Согласно этому сообщению blog от Microsoft, рекомендуется использовать GUID в качестве федеративного ключа. Однако они не упоминают, что все индексы (включая кластерные индексы) в таблицах объединения должны содержать ключ объединения. Это означает, что все эти индексы будут содержать GUID, который снизит производительность вставки.

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

Я бы подумал, что от Microsoft было бы больше уверенности в этом, поскольку наверняка с этой проблемой столкнутся все, кто создает федеративные таблицы!

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

Answer 1

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

В зависимости от расписания вашего проекта вы можете использовать SQL 2012 SEQUENCE и поместить все свои последовательности в небольшую не федеративную базу данных. ПОСЛЕДОВАТЕЛЬНОСТЬ пока недоступна в SQL Azure.

Answer 2

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

Когда дело доходит до уникального идентификатора строки, необходимо учитывать, что сущности будут храниться в разных базах данных и по этой причине генерация идентификаторов или последовательностейнедоступны, ознакомьтесь с публикацией в блоге Cihan Biyikoglu на этом - его рекомендация - использовать uniqueidentifier или datetimeoffset

Answer 3

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

Ваш следующий вопрос, я думаю о том, чтобы иметь там службу ID Generator, именно такую, как вы думали, но да, это может быть узким местом. Я думал, можем ли мы иметь пул идентификаторов, который использует некоторый кеш распределения для хранения идентификаторов, сгенерированных этим сервисом. Так что для использования кому угодно нужен идентификатор, который он будет получать из пула, а не генерировать по требованию. Таким образом, Генератор идентификаторов будет продолжать выдвигать идентификаторы в этом пуле, и потребители будут извлекать из него идентификатор. Это может быть полезно, но опять же, я никогда не реализовывал таким образом, поэтому я не могу сказать, является ли это наилучшей практикой или нет.

Надеюсь, это поможет.

Answer 4

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

Таблицы SQL Azure do нужен кластеризованный индекс. Мое предложение состоит в том, чтобы иметь кластеризованный индекс на основе диапазона значений (например, datetime) и использовать некластеризованный индекс для первичного ключа, который будет GUID.