SQL Design: большая таблица, сериализация доступа к потокам

Question

У меня есть один БОЛЬШОЙ стол (90 тыс. Строк, размер около 60 Мб), который содержит информацию о свободных номерах примерно для 50 отелей. Эта таблица имеет очень мало обновлений / вставок в час. Мое приложение отправляет асинхронные запросы в эту (и соединенные таблицы) со скоростью не более 30 раз в секунду.

Когда я запускаю 30 потоков (с классом AppPool по умолчанию в .NET 3.5 C #) одновременно (со случайной допустимой строкой запроса sql), только немногие (cca 4) обрабатываются асинхронно, и другие потоки ждут. Зачем? Это из-за блокировки таблиц SQL SERVER 2008 или из-за ядра .NET? Или что-то еще?

Если это проблема SQL, могу ли я помочь, если я разделю эту большую таблицу на одну таблицу для каждой модели отеля? Моя цель - создать как минимум 10 потоков одновременно.

Answer 1

Эта таблица крошечная. Это даже не квалифицируется как стол среднего размера. Это тривиально.

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

Если ваши данные помещаются в оперативную память, базы данных работают быстро. Если вы не находите это, вы делаете что-то ДЕЙСТВИТЕЛЬНО НЕПРАВИЛЬНОЕ. Поэтому я также думаю, что все проблемы на стороне клиента.

Answer 2

Вместо того, чтобы спрашивать, измерьте. Каждый из ваших SQL-запросов, которые фактически отправляются вашим приложением, создает запрос на сервере, а sys.dm_exec_requests DMV показывает состояние каждого запроса. Когда запрос заблокирован, столбец wait_type показывает непустое значение. Исходя из этого, вы можете судить, заблокированы ли ваши запросы. Если они заблокированы, вы также узнаете причину, по которой они заблокированы.

Answer 3

Вы пытались изменить уровень изоляции транзакции?

Даже при чтении из таблицы Sql Server заблокирует таблицу

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

но учтите, что возможно, что вы будете читать «грязные» данные, убедитесь, что понимаете последствия, если это решение

эта ссылка объясняет, что это такое.

текст ссылки

Answer 4

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