Обновление большого реплицируемого измерения (SQL Server PDW)

Мы используем устройство SQL Server PDW для нашего хранилища данных. Одна из таблиц на нашем складе - это реплицированная таблица с 20 миллионами строк. В рамках нашего процесса ETL нам нужно удалить старые записи из этого измерения; однако мы видим, что обновление нескольких записей (<100) занимает более 1 часа. Это то, что я хотел бы улучшить, если смогу.

Естественно, одним из вариантов, о котором я подумал, было изменение этого измерения с реплицированного на распределенное. Мои тесты показывают, что это решило бы проблему с процессом ETL, который занял бы много времени (от 1,5 часов до 30 секунд), но это затронет все объединения с распределенной версией этого измерения, поскольку объединения почти никогда не основаны на одном и том же распределении. колонка. Когда я смотрю на план выполнения некоторых из этих запросов, я обычно вижу либо операцию ShuffleMove, либо операцию BroadcastMove .

Итак, мой вопрос к гуру PDW:

Есть ли что-нибудь еще, что можно сделать, чтобы улучшить производительность обновления записей в реплицированной версии этого измерения?

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

Несколько вопросов. 20 миллионов строк не обязательно , что большой.

Какой процесс вы используете для обновления и удаления прямо сейчас?

Является ли измерение индексом CLUSTERED COLUMNSTORE, индексом CLUSTERED или HEAP?

Вы говорите, что есть движение, когда вы обновляете и удаляете эту таблицу, или вы просто видели движение, когда вы меняли таблицу с реплицированной на распределенную?

Если это последнее, что не удивительно. Вы вряд ли будете совместимы и объединены. Если вы делаете что-то, чтобы вызвать движение через обновление / удаление, мы могли бы взглянуть на это - хотя конкретный пример был бы полезен.

В общих чертах, я бы начал с простоты ETL.

Используйте CTAS для измерения, выбирая только те строки, которые вы хотите сохранить, объединяйте в любые новые строки и используйте CASE, чтобы получить любые изменения (преобразование UPDATE в преобразование в CTAS). После завершения вы можете использовать пару команд RENAME OBJECT для переключения с текущей таблицы на новую таблицу. Это дает вам дополнительное преимущество исторического обзора вашего стола, который вы можете оставить на досуге.

Репликация не мешает вам использовать разделы. Разделите ваш стол.

Затем для строк, которые необходимо удалить или обновить, CTAS всего раздела в новую таблицу, используя LEFT JOIN и COALESCE, чтобы получить соответствующие (т.е. новые) значения для обновлений из измененных строк, сохраняя нужные строки и исключая те, которые вы не делаете.

Наконец, раздел переключите новую таблицу со своим старым разделом.

И сделано :)

По моему опыту, PDW не любит обновления и удаления. CTAS и переключатели разделов работают хорошо.

Операторы UPDATE в PDW только частично параллельны, а не полностью параллельны, как CTAS.

Тем не менее, это вполне может быть до индексации. Какой код вы используете? Есть ли у вас индексы, чтобы помочь найти те записи, срок действия которых истекает? Вам все еще нужно применить некоторые стандартные методы настройки, чтобы применить некластеризованные индексы к таблицам хранилища строк. Тот факт, что PDW не поддерживает первичные ключи, часто означает, что люди забывают индексировать свой естественный ключ, поэтому не окажитесь в этой лодке ...