Архитектура сервиса больших данных

Question

Каждый день компания отправляет текстовый файл с потенциально большим количеством записей (350 000) на наш защищенный FTP.Мы создали службу Windows, которая запускается рано утром, чтобы читать текстовый файл в наших таблицах БД SQL Server 2005.Мы не выполняем BULK-вставку, потому что данные являются реляционными, и нам нужно сравнить их с тем, что уже есть в нашей БД, чтобы убедиться, что данные остаются нормализованными и согласованными.

Проблема в том, что службазаймет очень много времени (часов).Это проблематично, потому что это вставка и обновление в таблицы, которые постоянно должны запрашиваться и сканироваться нашим приложением, что может повлиять на производительность БД и приложения.

Одним из решений, которое мы подумали, является запусксервис на отдельной БД с теми же таблицами, что и у нашей живой БД.Когда служба закончена, мы можем сделать BCP в действующей БД, чтобы она отражала все новые записи, созданные службой.

Я никогда раньше не работал с миллионами записей в БД, и я 'Я не уверен, что стандартный подход к чему-то подобному.Это подходящий способ делать такие вещи?Есть предложения?

Answer 1

Один механизм, который я видел, состоит в том, чтобы вставить значения во временную таблицу - с той же схемой, что и таблица назначения. Нулевые идентификаторы обозначают новые записи, а заполненные идентификаторы - обновленные записи. Затем используйте команду SQL Merge, чтобы объединить ее с основной таблицей. Слияние будет работать лучше, чем отдельные вставки / обновления.

Делая это индивидуально, вы возьмете на себя обслуживание индексов в таблице - может быть дорогостоящим, если его настроить для выбора. Я считаю, слияние это массовое действие.

Это затронуто здесь: Какая хорошая альтернатива 368 раз запускать хранимую процедуру для обновления базы данных?

Существуют статьи MSDN о слиянии SQL, поэтому Googling поможет вам в этом.

Обновление: оказывается, что вы не можете объединить (вы можете в 2008 году). Ваша идея иметь другую базу данных обычно обрабатывается репликацией SQL. Опять же, я видел в производстве копию текущей базы данных, которая использовалась для выполнения длительного действия (создание отчетов и агрегация данных в этом случае), однако это не было объединено обратно. Я не знаю, какие возможности объединения доступны в репликации SQL - но это было бы хорошее место, чтобы посмотреть.

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

Обновление 2: , как упоминалось в комментариях, вы можете придерживаться идеи временной таблицы, чтобы получить данные в базу данных, а затем вставить / обновить соединение в эту таблицу, чтобы заполнить вашу основную таблицу. Разница в том, что теперь SQL работает с набором, поэтому может соответствующим образом настроить любые перестроения индекса - должно быть быстрее, даже с присоединением.

Обновление 3: Вы можете удалить проверку данных из процесса вставки и перенести ее в службу. Если вы можете остановить вставки в таблицу, пока это происходит, то это позволит вам решить проблему, не позволяющую вам массово вставлять данные (т. Е. Вы проверяете дубликаты на основе значений столбцов, поскольку у вас еще нет такой роскоши, как Я БЫ). В качестве альтернативы для идеи временной таблицы вы можете добавить условие WHERE, чтобы сначала увидеть, существует ли строка в базе данных, что-то вроде:

INSERT INTO MyTable (val1, val2, val3)
SELECT val1, val2, val3 FROM #Tempo 
WHERE NOT EXISTS 
( 
    SELECT * 
    FROM MyTable t 
    WHERE t.val1 = val1 AND t.val2 = val2 AND t.val3 = val3
)

Answer 2

Мы делаем гораздо больший импорт, чем это все время.Создайте пакет SSIS для выполнения этой работы.Лично я предпочитаю создать промежуточную таблицу, очистить ее, а затем выполнить обновление или импорт.Но SSIS может выполнить всю очистку в памяти, если вы хотите, прежде чем вставлять.

Answer 3

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

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