Несколько вставок в одну таблицу

Question

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

У меня есть один веб-сервис, который выполняет некоторую бизнес-логику и, наконец, вставляет результат в таблицу. Это прекрасно работает, если мое приложение находится в минимальной загрузке.

Теперь, когда нагрузка велика, мой INSERT оператор SQL истек. Я увеличил время ожидания подключения и время ожидания команды. Но проблема в том, что слишком много потоков вызывают один и тот же веб-метод. Просто, чтобы дать подсказку, мое число OPEN sql-соединения при большой нагрузке превышает 500+. К вашему сведению, я закрывал соединение после каждой команды.

Теперь, что я должен сделать здесь, чтобы оптимизировать эту вещь здесь?

Я планирую сохранить данные INSERT в таблице данных и сохранить эту таблицу данных в переменной APPLICATION. И каждые две минуты вставляйте данные из этой таблицы данных в базу данных.

У вас, ребята, есть еще какие-нибудь идеи, которые могут сгладить мою жизнь здесь?

Спасибо

EDIT

Вот более подробная информация, когда я запускаю запрос вставки в Management Studio

SQL Server анализирует и компилирует время: Время ЦП = 0 мс, прошедшее время = 0 мс.

Разбор SQL Server и время компиляции: Время ЦП = 0 мс, прошедшее время = 11 мс.

Таблица «IndexTable1». Сканирование счетчик 0, логическое чтение 2, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

Таблица «IndexTable2». Сканирование счетчик 0, логическое чтение 2, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

Таблица «fulltext_index_docidstatus_171147655». Сканирование счетчик 0, логическое чтение 11, физическое чтение 0, чтение с опережением 0, логическое чтение с 0, физическое чтение с 0, чтение с опережением 0.

Таблица ' MAINTABLE '. Сканирование счетчик 0, логическое чтение 28, физическое чтение 4, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.

(затронут 1 ряд)

(затронут 1 ряд)

Время выполнения SQL Server: Время ЦП = 0 мс, прошедшее время = 69 мс.

SQL Server анализирует и компилирует время: Время ЦП = 0 мс, прошедшее время = 0 мс.

Время выполнения SQL Server: Время ЦП = 0 мс, прошедшее время = 0 мс

Answer 1

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

Answer 2

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

Answer 3

Ответ Ильи Когана кажется разумным и совпадает с вашим.В основном делать массовые вставки по расписанию.Просто имейте в виду, что это будет работать только в том случае, если информация, которую вы вводите, сама по себе не используется в бизнес-логике для ответа на новые запросы.Когда вы отправляете ответ, клиент будет предполагать, что любое изменение состояния на сервере уже произошло, когда он решит сделать второй запрос, здесь возникают 2 проблемы: 1) что произойдет, если после ответа клиенту по какой-либо причине вы могли быне вставить результат этого запроса позже?2) что произойдет, если после получения ответа клиент выдаст новый запрос таким образом, что результаты первого запроса все еще не будут сохранены?что приложение будет использовать в качестве данных для обработки этого второго запроса.Как видите, это простое решение может привести к другим проблемам, но все зависит от того, как устроен ваш веб-сервис, особенно, если для обработки дальнейших запросов требуются какие-либо постоянные данные для каждого запроса.

Answer 4

Ответ на такой вопрос может быть слишком сложным

Попытайтесь выяснить, ГДЕ узкое место - это на стороне клиента или на стороне сервера.

Какое количество индексов задействовано для INSERT, и если есть какая-либо точка доступа в верхней части таблицы - что очень обычно для однораздельной автоинкрементной таблицы первичных ключей

Есть ли какие-либо одновременные операции SELECT, выполняемые над таблицей при вставке в нее

Вам следует рассмотреть все эти и многие другие причины, чтобы выяснить, в чем проблема.

Постарайтесь предоставить более ценную информацию в вашем вопросе

Answer 5

Я не знаю простых ответов на этот вопрос.Во-первых, в вашем плане возникнут проблемы с параллелизмом, вы, возможно, попытаетесь заблокировать данные, и т. Д., И это может вызвать проблемы.

Как правило, я бы рекомендовал не сохранять постоянную связь между приложением и базой данных.сервера.Но с другой стороны, число открытых соединений, превышающее 500, не должно происходить.Я думаю, что это то, на чем вы должны сосредоточиться.Я полагаю, что ваша транзакция крупная и выполняется более пары секунд.Попробуйте уменьшить его.Я могу предложить записать ваши данные в очень простую необработанную таблицу базы данных, такую ​​как запись журнала.И в задании SQL, которое выполняется периодически, считывайте из этой таблицы и обрабатывайте их параллельно.Вы даже можете администрировать систему, в которой, когда она обнаруживает загрузку, она задерживает обработку.

Если у вас есть несколько похожих запросов на вставку в одной данной точке, вы должны учитывать класс System.Data.SqlClient.SqlBulkCopy, независимо от того,из моих заявлений выше.

Желаю удачи.