Параллельная массовая загрузка с использованием переключения секций индексированной таблицы в SQL Server 2008

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

Несмотря на то, что это кажется лучшим способом, его недостаточно, чтобы действительно удовлетворить требование, позволяющее нескольким (‹ 5) пользователям выполнять массовую вставку одновременно, индексировать новые данные и отображать их в индексированных представлениях (не обязательно настоящие индексированные представления, просто выбираются те, которые полагаются на индексы).

Идея секционирования заключалась в том, что каждый раздел и поддерево индекса с корнем в разделе можно было параллельно блокировать как доступ только для чтения, копировать в рабочую таблицу, вставлять/обновлять новые данные и перестраивать индексы, а затем переключать обратно в основную таблицу. чтобы читатели не пострадали.

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

До сих пор я столкнулся с несколькими стенами, пытаясь обойти это узкое место:

  1. Я попытался разделить рабочую таблицу, используя ту же функцию разделения. Это не работает, потому что вы не можете отключить индексы для отдельных разделов, чтобы вставлять их в один при перестроении индекса в другом.
  2. Создание временной таблицы в качестве рабочей таблицы. Это не работает, потому что, хотя вы можете использовать одни и те же имена индексов, вы не можете легко динамически создавать ограничения и в любом случае не можете их переключать.
  3. У вас есть фиксированный набор именованных рабочих таблиц? Как я могу выбрать один и работать с ним под псевдонимом, чтобы у меня был только один сохраненный процесс?
  4. Динамический SQL? Я очень старался не идти по этому пути. Это сложно, как это.

Большая проблема, но есть ли у кого-нибудь идеи, прежде чем я приму узкое место? Sql 2012 поможет? Как с этим справляются правильные хранилища данных?


sql-server data-warehouse bulkinsert indexing data-partitioning
person Chris Woodward    schedule 19.10.2012    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Как с этим справляются правильные хранилища данных? Найдите компромисс и установите реалистичные цели для EDW. Хранилище данных не может быть всем для всех. Убедитесь, что то, что вы внедряете, является лучшим решением для бизнеса (а не только для техников/аналитиков). Реалистичны ли ваши цели, если вы не можете найти решения у опытных коллег и экспертов?

Свяжите стоимость со всеми обручами, через которые вы прыгаете. Действительно ли данные должны быть актуальными? Что если я скажу вам, что нам нужно потратить еще 200 000 долларов на хранилище, потому что мы постоянно дублируем разделы и перестраиваем индексы, а текущее решение не может удовлетворить спрос на IOPS? В какой-то момент они поймут, что это не бесплатно. Хотя вам не нужно просто говорить «нет», вы должны быть реалистичными и прямолинейными в отношении связанных с этим затрат. Кроме того, администратор хранилища поблагодарит вас.

Что касается 2012 года, существует новый индекс columnstore, который может сократить или заменить все текущие некластеризованные индексы, которые вы используете, чтобы охватить все поисковые запросы, которые вы выполняете в качестве аналитиков. Он сильно сжат, охватывает очень широкий спектр аргументов поиска и использует новый пакетный режим выполнения. Он лучше всего работает с запросами с низкой избирательностью, такими как те, которые часто выполняются для таблиц фактов. Одна загвоздка в том, что вы не можете напрямую делать обновления. Вам придется переключить раздел на промежуточную таблицу, удалить столбец в промежуточной таблице, обновить промежуточную таблицу, снова добавить столбец, а затем переключить раздел обратно в таблицу фактов. Звучит много, но может быть значительно быстрее и требовать меньше операций ввода-вывода, чем поддержка всех этих некластеризованных.

Мой вопрос всегда был: «Действительно ли это таблица фактов, если она постоянно меняется?». Это не OLTP? Попробуйте компенсировать транзакции или, по крайней мере, перенести все обновления на запланированное непиковое время. Обновление таблиц фактов уходит в прошлое. Все большие мальчики переходят к столбцово-ориентированной архитектуре для данных складирование. PowerPivot и табличная модель служб Analysis Services основаны на технологии columnstore.

Наконец, просмотрите книги Kimballs DW Toolkit. У него есть несколько примеров, в которых излагаются передовые практики и рассматриваются крайние случаи. От них я узнал, что разработка хранилищ данных — это не просто разработка баз данных на стероидах. Это также включает в себя политику и сосредоточение ресурсов на том, что лучше для бизнеса.

person brian    schedule 20.10.2012