CQRS и первичный ключ: гид или нет? - PullRequest
Новая
       7

CQRS и первичный ключ: гид или нет?

11 голосов
/ 02 августа 2011

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

service.SubmitCommand(new AddUserCommand() { UserId = key, ... });

Очевидно, что я не могу использовать int для первичного ключа, поэтому Guid - это логичный выбор - за исключением того, что я везде читаю овлияние на производительность, которое меня пугает:)

Но потом я также прочитал о COMB Guids и о том, как они обеспечивают преимущества Guid, сохраняя при этом хорошую производительность.Я также нашел здесь реализацию: Последовательный GUID в Linq-to-Sql? .

Итак, прежде чем я приму это важное решение: есть ли у кого-то опыт в этом вопросе, советы?

Большое спасибо!

Люд

Ответы [ 3 ]

7 голосов
/ 03 августа 2011

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

Большинство тестов Sequential GUID vs INT as primary key работает с пакетной вставкой и выбирает данные из неактивной базы данных.Но в реальной жизни выбор и обновления происходят в то же время.

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

Кроме того, асинхронность, которая обеспечивает обмен сообщениями,позволяет вашим приложениям масштабироваться намного лучше, чем системы с блокирующими вызовами RPC.

Учитывая вышесказанное, выбор GUIDs vs INTs кажется мне как пенни и глупо.

6 голосов
/ 02 августа 2011

Вы не указали, какой механизм базы данных вы используете, но, поскольку вы упомянули LINQ to SQL, я полагаю, это MS SQL Server. Если да, то Кимберли Трипп дает несколько советов по этому поводу:

Суммируем две ссылки в нескольких словах:

  • последовательные идентификаторы GUID работают лучше, чем случайные идентификаторы GUID, но все же хуже, чем числовые ключи автоинкремента
  • очень важно выбрать правильный кластеризованный индекс для вашей таблицы, особенно когда ваш первичный ключ - GUID
4 голосов
/ 03 августа 2011

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

  1. Когда вы создаете пользователя, вы знаете имя пользователя, потому что вы отправили его как часть команды.
  2. Когда выВы вошли в систему, вы знаете имя пользователя, потому что пользователь отправил его как часть команды входа в систему.

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

Если вы используете DDD, вам нужно сосредоточиться на поддержании чистоты домена, чтобы код был легким для понимания и отражал реальные бизнес-процессы.Внедрение искусственного ключа противоречит этой цели, но если вы уверены, что оно обеспечивает реальную ценность для бизнеса, тогда продолжайте.

...