Quantcast
Channel: SQL.ru: Microsoft SQL Server
Viewing all articles
Browse latest Browse all 7251

Update большого числа записей при импорте - выбор оптимального пути

$
0
0
Собственно задача простая. Есть много документов около 100 тык в день из внешней системы А со своими уникальными ID, нужно загружать их в систему B . К сожалению документы в системе A могут меняться и их необходимо будет перегружать, измененные документы будут приходить через шину. Т.е. на входе могут быть как новые документы, так и те которые грузились раньше, но измененные. Для скорости документы можно разделить на пакеты фиксированного размера (учитывая память) и обрабатывать параллельно, можно в пакете сразу понять какие документы изменены а какие новые .
Новые вставить скажем через Bulk Insert а измененные

Вопрос - какой наиболее эффективный способ Update для пакета из 10000 тыс записей например (размер пакета фиксированный), что бы при импорте совершать минимальное количество действий. Предположим что ID в разных заданиях не пересекаются

Хелп говорит что мы можем использовать переменную типа


DECLARE @Y table
запихнуть туда 10000 записей
далее сделать Update
UPDATE x -- cte is referenced by the alias.
SET Value = y.Value
FROM cte AS x -- cte is assigned an alias.
INNER JOIN @y AS y ON y.ID = x.ID;

Вроде все хорошо но хелп утверждает что
https://msdn.microsoft.com/ru-ru/library/ms175010.aspx
"ременные Table не имеют статистики распределения. Они не запускают повторных компиляций. Поэтому во многих случаях оптимизатор построит план запроса в предположении, что у табличной переменной нет строк. По этой причине следует проявлять осторожность относительно использования табличной переменной, если ожидается большое число строк (больше 100)"

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

Т.е. хелп толкает нас к использованию временных таблиц так как соединение без индекса это не очень хорошо
Однако временные таблицы TempDb
а) хранятся на диске б ) tempdb общий ресурс его используют разные задачи
Можно конечно его поместить в ОЗУ но так как это общий ресурс - ОЗУ может не хватить для других задач.

P S Я конечно могу эту задачу решить без update при импорте, храня не документы а их версии, но не хотелось бы усложнять структуру данных

Viewing all articles
Browse latest Browse all 7251

Trending Articles