Оптимальное решение для большого количества запросов на одну таблицу базы данных

Question

У нас есть система, в которой клиенты распределяют продукт по принципу «первым пришел - первым обслужен».

Наша таблица продуктов содержит инкрементный первичный ключ, который начинается с нуля, который мы используем для отслеживания того, сколько продуктов было выделено, т.е. пользователь резервирует продукт и получает 1, следующий пользователь получает 2 и т. Д.

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

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

Мы обеспокоены узким местом, которым является время обработки каждого запроса, поступающего в SQL Server 2008 Enterprise Edition , и блокировкой строки.

Мы не можем использовать несколько серверов, поскольку нам нужно обеспечить целостность первичного ключа, чтобы все, что требует репликации, не работало.

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

Немного больше информации:
По сути, эта таблица содержит только два поля - ID и CustomerID. Решение заключается в бесплатной раздаче миллиона продуктов - отсюда ожидание высокого спроса и почему использование увеличивающегося первичного ключа в качестве ключа имеет смысл для нас - как только ключ достигнет миллиона, больше клиентов не смогут зарегистрироваться. Кроме того, все продукты разные, поэтому важно правильно подобрать ключ, например, первые 100 введенных клиентов получают продукт с более высокой стоимостью, чем следующие 100 и т. д.

Answer 1

Во-первых, чтобы снять проблему генерации ключей, я бы сгенерировал их все заранее. Это всего 1м строк, и это означает, что вам не нужно беспокоиться об управлении процессом генерации ключей. Это также означает, что вам не нужно беспокоиться о случайном генерировании слишком большого количества строк, поскольку после заполнения таблицы вы будете выполнять только ОБНОВЛЕНИЯ, а не ВСТАВКИ.

Здесь один важный вопрос: все элементы 1м одинаковы или нет? Если это так, то не имеет значения, в каком порядке находятся ключи (или даже если у них есть заказ), поэтому, когда клиенты отправляют запросы, вы просто «пытаетесь» ОБНОВИТЬ таблицу примерно так:

UPDATE TOP(1) dbo.Giveaway -- you can use OUTPUT to return the key value here
SET CustomerID = @CurrentCustomerID
WHERE CustomerID IS NULL

IF @@ROWCOUNT = 0 -- no free items left
PRINT 'Bad luck'
ELSE
PRINT 'Winner'

Если, с другой стороны, 1м предметов отличаются, вам нужно другое решение, например, пункт 1 - это X, элементы 2-10 - это Y, 11-50 - это Z и т. д. В этом случае важно назначать клиентов ключам в том порядке, в котором отправляются запросы, поэтому вам, вероятно, следует рассмотреть какую-нибудь систему очередей, возможно, используя Service Broker. Каждый клиент добавляет запрос в очередь, затем хранимая процедура обрабатывает их по одному и присваивает им максимальный свободный ключ, а затем возвращает сведения о том, что он выиграл.