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

Question

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

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

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

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

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

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

Спасибо

EDIT

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

парсер SQL Server и время компиляции: процессорного времени = 0 мс, прошедшее время = 0 мс.

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

Таблица "IndexTable1". Число отсчетов 0, логическое чтение 2, физическое чтение 0, чтение вперед 0, логическое считывание логических чисел 0, физическое считывание вободного числа 0, считывание с чтением 0 ...

Таблица «IndexTable2». Число отсчетов 0, логическое чтение 2, физическое чтение 0, чтение вперед 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 Execution Times: Время процессора = 0 мс, прошедшее время = 69 мс.

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

Желаю удачи.

Answer 4

Ответ на этот вопрос может быть усложненной

попытаться выяснить, где это узкое место - это его @ стороне клиента или сервера @.

Какого количество индексов, участвующих в ВСТАВИТЬ, и если есть какая-либо точка доступа на верхней часть таблицы - что очень обычно для однораздельного автоинкремента первичной шпонки таблицы

Есть ли одновременные ВЫБИРАЕТ производится по таблице при вставке в него

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

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

Answer 5

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