Быстрые вставки;BulkCopy с реляционными данными

Question

У меня есть большое количество постоянно поступающих данных (примерно 10000 в минуту и ​​растущих), которые я хочу вставить в базу данных как можно более эффективно. В данный момент я использую подготовленные операторы вставки, но думаю об использовании класса SqlBulkCopy для импорта данных большими кусками.

Проблема в том, что я не вставляю в одну таблицу - элементы элемента данных вставляются в многочисленные таблицы, а их столбцы идентификаторов используются в качестве внешних ключей в других строках, которые вставляются одновременно. Я понимаю, что массовые копии не предназначены для более сложных вставок, подобных этой, но мне интересно, стоит ли менять мои столбцы идентификаторов (в данном случае bigints) на столбцы uniqueidentifier. Это позволит мне сделать несколько массовых копий для каждой таблицы, и, поскольку я могу определить идентификаторы перед вставкой, мне не нужно проверять что-либо вроде SCOPE_IDENTITY, которое мешает мне использовать массовое копирование.

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

Спасибо.

Answer 1

uniqueidentifier, вероятно, ухудшит ситуацию: разделение страниц и расширение. Смотри это

Если ваша загрузка / может быть дозирована, один из вариантов:

• Вы загружаете промежуточный стол
• загрузка реальных таблиц за один раз как хранимая процедура
• использовать уникальный идентификатор в промежуточной таблице для каждой партии

Мы имеем дело с пиками около 50 тыс. Строк в секунду (и таким образом увеличиваем). На самом деле мы используем отдельную промежуточную базу данных, чтобы избежать двойной записи в журнал транзакций)

Answer 2

Похоже, вы планируете обменяться «SQL назначает суррогатный ключ [столбец bigint identity ()]» с «подпрограммой подготовки данных, использующей суррогатный ключ GUID».Другими словами, ключ будет назначаться не в SQL, а извне SQL.Учитывая ваши объемы, если процесс генерирования данных может назначить суррогатный ключ, я бы определенно согласился с этим.

Тогда возникает вопрос, должны ли вы использовать GUID или ваши данныепроцесс генерации производить автоинкрементные целые числа?Создать такой процесс, который работает последовательно и безошибочно, сложно (одна из причин, по которой вы платите $$$ за SQL Server), но компромисс между меньшими и более удобочитаемыми ключами в базе данных может стоить этого.