Вставка большого BLOB занимает много времени

Я создаю сложное приложение. Частью этого приложения является агент, который работает на других серверах и отправляет данные в веб-службу (ASP MVC) -> JSON. В контроллере я конвертирую данные в XML и вызываю хранимую процедуру, которая сохраняет их в таблице. Задание агента SQL собирает данные и выполняет необходимые операции создания, обновления и удаления для некоторых таблиц.

Все идет нормально...

Проблема здесь в скорости. Сгенерированный XML имеет размер в несколько мегабайт. В настоящее время это ~ 16 МБ. Вставка строки XML в новую строку БД занимает 5-6 секунд.

Что я пробовал:

  • Изменен столбец БД на XML. Тот же результат!
  • Я думал, что проблема в Entity Framework. Я заменил этот код хранимой процедурой. Тот же результат!
  • Удалены все операторы из SP -> пустая хранимая процедура. Тот же результат!
  • Тип параметра изменен с string/nvarchar(max) на byte[]/varbinary(max). Это принесло некоторое улучшение. Теперь это на 50% быстрее. Но все равно медленно.

Кажется, что передача этой большой строки или массива байтов на сервер SQL занимает очень много времени!

Что я могу сделать, чтобы получить это быстрее?

Я подумал о следующем: - Поместите данные в файловую систему и проинструктируйте SQL-сервер обработать их с помощью SELECT FROM OPENROWSET.

Есть ли альтернативы?


person AcidJunkie    schedule 20.04.2016    source источник
comment
Каково определение таблицы? Вы сохраняете в виде текста или используете поддержку XML в SQL Server для его анализа?   -  person Richard    schedule 20.04.2016
comment
Вы можете хранить данные на диске и иметь указатель/путь к файлу в базе данных. В большинстве ситуаций это лучший подход. Это позволяет уменьшить размер вашей базы данных, снизить ее фрагментацию, повысить производительность и упростить сохранение изменений в данных. Я уверен, что есть статьи о плюсах хранения (больших) BLOB-объектов вне базы данных.   -  person Igor    schedule 20.04.2016
comment
Это может вас заинтересовать: Stackexchange для программистов. Не рекомендуется ли хранить большие файлы в базе данных? в частности второй ответ о FILESTREAM, если вы хотите продвигаться вперед.   -  person Igor    schedule 20.04.2016
comment
@Игорь Согласен. Это означало бы, что на сервере должны быть размещены как веб-сервер, так и SQL-сервер. Я также подумал о том, чтобы включить хранилище в файловой системе в транзакцию, используя TransactionScope и транзакционные функции NTFS.   -  person AcidJunkie    schedule 20.04.2016
comment
@ Ричард Я пробовал оба. Но это не имеет значения. В моем случае это сортировка больших данных по параметру SQL, что требует времени...   -  person AcidJunkie    schedule 20.04.2016
comment
Вы проверили функцию FileStream? ? Это даст вам лучшее из обоих миров. Файлы хранятся на диске, но указываются в базе данных, и все они управляются под эгидой Sql Server, и кажется, что он должен обеспечивать производительность, хотя вам придется это проверить.   -  person Igor    schedule 20.04.2016
comment
@ Игорь Да, я сделал. Это несколько быстрее. Я думаю, что я использую подход, который я объяснил ранее: TransactionScope и транзакционные версии файловых функций Win32, такие как CreateFileTransacted и т. д. ... это также позволяет мне иметь быстрый файловый ввод-вывод и согласованность.   -  person AcidJunkie    schedule 22.04.2016


Ответы (1)


Попробуйте выполнить операцию SQL асинхронно. Надеюсь, вам не нужен немедленный результат.

Threading.ThreadPool.QueueUserWorkItem(new Threading.WaitCallback(InsertBLOB), MyBLOB);

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

person Alex Kudryashev    schedule 20.04.2016