Улучшение производительности вставки SQL

Question

Я пишу приложение, которое записывает обновления состояния (местоположения GPS) с устройств в базу данных. Обновления происходят с установленным интервалом для каждого устройства, который в настоящее время каждые 3 секунды. Я использую простую таблицу в SQL Server 08 для хранения каждого обновления.

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

Обновления статуса поступают из асинхронного потока Socket. В моей текущей реализации вызов вставки базы данных выполняется из этого потока. Я думаю, что могу создать очередь для хранения данных обновления, к которой поток Socket может быстро добавить свое обновление и затем продолжить свой веселый путь. Тогда будет отдельный поток, единственной обязанностью которого будет проверка очереди обновлений и вставка обновлений в базу данных.

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

Вот как база данных записывается в:

Я использую LinqToSQL в C #, поэтому для каждой вставки я сначала создаю экземпляр DataContext. Затем из объекта DataContext я вызываю хранимую процедуру, которая вставляет обновление местоположения. Таблица индексируется по дате и времени на момент обновления.

Answer 1

Посмотрите на класс SqlBulkCopy - это позволяет вам использовать BCP для очень быстрой вставки фрагментов данных.

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

Answer 2

Да, вставка в пакетах, как правило, будет быстрее, чем отдельные вставки с учетом вашего описания. Каждая вставка требует установки соединения и передачи пакетов. Если у вас есть одна небольшая вставка, которая принимает один пакет, и вы выпускаете три из них, но у вас есть три небольших вставки, которые могут вместить один пакет, тогда это поможет.

Оценить это сложно, основываясь только на вашем описании - для этого вам нужно будет провести тестирование. Например, если вы все равно всегда оставляете выделенное соединение открытым, как предполагает hova, то вы можете увидеть меньшее влияние.

Answer 3

Вы смотрели MSMQ (Microsoft Message Queuing (MSMQ))? Мне кажется, это возможность посмотреть.

Answer 4

Не боитесь ли вы потерять данные во время сбора данных для пакетного копирования?

Я пишу приложение, делающее то же самое. При запуске мне придется записывать данные с 3,5 тыс. GPS-устройств. Одно устройство должно отправлять данные каждую минуту, но оно может отправлять быстрее. Целевое количество устройств - 10,5 тыс.

Мне тоже интересно узнать производительность. На данный момент я сохраняю полученные данные в db для каждого пакета, используя чистый ADO.NET ICommand и хранимую процедуру. На моем тестовом сервере (Xeon 3,4 ГГц и один жесткий диск 1 ТБ - обычный рабочий стол;) сейчас требуется 1 мс или меньше.

@ GRIMUS - интересно, будет ли больше устройств?

Answer 5

На стороне SQL вы бы хотели убедиться, что вы используете параметризованные запросы.

Кроме того, пакетные операторы INSERT, безусловно, увеличат производительность.

Управление соединением также является ключевым, конечно, это зависит от того, как построено приложение и зависит ли оно от наличия соединения.

Answer 6

Звучит как хорошая идея. Почему бы не попробовать и посмотреть, как это работает?

Answer 7

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

Вам также понадобится как можно меньше индексов в таблице.