Хранилище данных — Тюнинг

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

Трудности в настройке хранилища данных

Настройка хранилища данных является сложной процедурой по следующим причинам:

• Хранилище данных является динамичным; оно никогда не остается постоянным.

• Очень сложно предсказать, какой запрос пользователь отправит в будущем.

• Бизнес-требования меняются со временем.

• Пользователи и их профили постоянно меняются.

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

• Загрузка данных на склад также меняется со временем.

Хранилище данных является динамичным; оно никогда не остается постоянным.

Очень сложно предсказать, какой запрос пользователь отправит в будущем.

Бизнес-требования меняются со временем.

Пользователи и их профили постоянно меняются.

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

Загрузка данных на склад также меняется со временем.

Примечание. Очень важно иметь полное представление о хранилище данных.

Оценка эффективности

Вот список объективных показателей эффективности —

• Среднее время ответа на запрос
• Скорость сканирования
• Время, использованное на запрос дня
• Использование памяти на процесс
• Пропускная способность ввода / вывода

Ниже приведены моменты, которые нужно помнить.

• Необходимо указать меры в соглашении об уровне обслуживания (SLA).

• Бесполезно пытаться настроить время отклика, если оно уже лучше, чем требуется.

• Важно иметь реалистичные ожидания при оценке эффективности.

• Также важно, чтобы у пользователей были реальные ожидания.

• Чтобы скрыть сложность системы от пользователя, следует использовать агрегаты и представления.

• Также возможно, что пользователь может написать запрос, который вы не настроили.

Необходимо указать меры в соглашении об уровне обслуживания (SLA).

Бесполезно пытаться настроить время отклика, если оно уже лучше, чем требуется.

Важно иметь реалистичные ожидания при оценке эффективности.

Также важно, чтобы у пользователей были реальные ожидания.

Чтобы скрыть сложность системы от пользователя, следует использовать агрегаты и представления.

Также возможно, что пользователь может написать запрос, который вы не настроили.

Настройка загрузки данных

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

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

Существуют различные подходы настройки загрузки данных, которые обсуждаются ниже —

• Самым распространенным подходом является вставка данных с использованием уровня SQL . При таком подходе необходимо выполнять обычные проверки и ограничения. Когда данные вставляются в таблицу, запускается код, чтобы проверить, достаточно ли места для вставки данных. Если недостаточно места, возможно, потребуется больше места для этих таблиц. Эти проверки требуют времени для выполнения и являются дорогостоящими для процессора.

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

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

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

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

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

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

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

Проверка целостности

Проверка целостности сильно влияет на производительность нагрузки. Ниже приведены моменты, которые нужно помнить —

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

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

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

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

Настройка запросов

У нас есть два вида запросов в хранилище данных —

• Фиксированные запросы
• Специальные запросы

Фиксированные Запросы

Фиксированные запросы четко определены. Ниже приведены примеры фиксированных запросов:

• регулярные отчеты
• Консервированные запросы
• Общие скопления

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

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

Специальные запросы

Чтобы понять специальные запросы, важно знать специальных пользователей хранилища данных. Для каждого пользователя или группы пользователей необходимо знать следующее:

• Количество пользователей в группе
• Используют ли они специальные запросы через регулярные промежутки времени
• Часто ли они используют специальные запросы
• Используют ли они специальные запросы иногда с неизвестными интервалами.
• Максимальный размер запроса, который они склонны выполнять
• Средний размер запроса, который они склонны выполнять
• Требуют ли они детализированного доступа к базовым данным
• Истекшее время входа в день
• Пиковое время ежедневного использования
• Количество запросов, которые они запускают в час пик

Указывает на заметку

Важно отслеживать профили пользователей и определять запросы, которые выполняются на регулярной основе.

Также важно, чтобы выполненная настройка не влияла на производительность.

Определите похожие и специальные запросы, которые часто выполняются.

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

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