Хранилище данных - настройка
Хранилище данных продолжает развиваться, и невозможно предсказать, какой запрос пользователь отправит в будущем. Поэтому становится сложнее настроить систему хранилища данных. В этой главе мы обсудим, как настроить различные аспекты хранилища данных, такие как производительность, загрузка данных, запросы и т. Д.
Трудности при настройке хранилища данных
Настройка хранилища данных - сложная процедура по следующим причинам:
Хранилище данных динамическое; он никогда не остается постоянным.
Очень сложно предугадать, какой запрос пользователь отправит в будущем.
Бизнес-требования меняются со временем.
Пользователи и их профили постоянно меняются.
Пользователь может переключаться из одной группы в другую.
Загрузка данных в хранилище также меняется со временем.
Note - Очень важно иметь полное представление о хранилище данных.
Оценка эффективности
Вот список объективных показателей производительности -
- Среднее время ответа на запрос
- Скорость сканирования
- Время, используемое в день запроса
- Использование памяти на процесс
- Скорость ввода / вывода
Вот что следует помнить.
Необходимо указать меры в соглашении об уровне обслуживания (SLA).
Нет смысла настраивать время отклика, если оно уже лучше, чем требуется.
При оценке эффективности важно иметь реалистичные ожидания.
Также важно, чтобы у пользователей были оправданные ожидания.
Чтобы скрыть сложность системы от пользователя, следует использовать агрегаты и представления.
Также возможно, что пользователь может написать запрос, на который вы не настроились.
Настройка загрузки данных
Загрузка данных - важная часть ночной обработки. Ничто другое не может работать, пока не завершится загрузка данных. Это точка входа в систему.
Note- Если есть задержка в передаче данных или в их поступлении, это сильно влияет на всю систему. Поэтому очень важно сначала настроить загрузку данных.
Существуют различные подходы к настройке загрузки данных, которые обсуждаются ниже -
Очень распространенный подход - вставить данные с помощью SQL Layer. При таком подходе необходимо выполнять обычные проверки и ограничения. Когда данные вставляются в таблицу, запускается код, чтобы проверить, достаточно ли места для вставки данных. Если недостаточно места, возможно, для этих таблиц потребуется выделить больше места. Эти проверки требуют времени и затратны для ЦП.
Второй подход - обойти все эти проверки и ограничения и поместить данные непосредственно в предварительно отформатированные блоки. Эти блоки позже записываются в базу данных. Это быстрее, чем первый подход, но он может работать только с целыми блоками данных. Это может привести к неэффективному использованию пространства.
Третий подход заключается в том, что при загрузке данных в таблицу, которая уже содержит таблицу, мы можем поддерживать индексы.
Четвертый подход гласит, что для загрузки данных в таблицы, которые уже содержат данные, drop the indexes & recreate themкогда загрузка данных завершена. Выбор между третьим и четвертым подходами зависит от того, сколько данных уже загружено и сколько индексов необходимо перестроить.
Проверки целостности
Проверка целостности сильно влияет на производительность нагрузки. Ниже приведены моменты, которые следует запомнить -
Проверки целостности необходимо ограничить, поскольку они требуют большой вычислительной мощности.
В исходной системе следует применять проверки целостности, чтобы избежать снижения производительности загрузки данных.
Настройка запросов
У нас есть два типа запросов в хранилище данных:
- Фиксированные запросы
- Специальные запросы
Фиксированные запросы
Фиксированные запросы четко определены. Ниже приведены примеры фиксированных запросов -
- регулярные отчеты
- Шаблонные запросы
- Общие агрегаты
Настройка фиксированных запросов в хранилище данных такая же, как в системе реляционной базы данных. Единственная разница в том, что объем запрашиваемых данных может быть другим. При тестировании фиксированных запросов рекомендуется сохранять наиболее успешный план выполнения. Сохранение этого плана выполнения позволит нам обнаружить изменение размера данных и перекос данных, поскольку это приведет к изменению плана выполнения.
Note - Мы не можем сделать больше с таблицей фактов, но при работе с таблицами измерений или агрегатами для настройки этих запросов можно использовать обычный набор настроек SQL, механизма хранения и методов доступа.
Специальные запросы
Чтобы понять специальные запросы, важно знать специальных пользователей хранилища данных. Для каждого пользователя или группы пользователей вам необходимо знать следующее:
- Количество пользователей в группе
- Используют ли они специальные запросы через регулярные промежутки времени
- Часто ли они используют специальные запросы
- Используют ли они время от времени специальные запросы с неизвестными интервалами.
- Максимальный размер запроса, который они обычно выполняют
- Средний размер запросов, которые они обычно выполняют
- Требуется ли им детальный доступ к базовым данным
- Прошедшее время входа в систему за день
- Пиковое время ежедневного использования
- Количество запросов, выполняемых в час пик.
Points to Note
Важно отслеживать профили пользователей и определять запросы, которые выполняются на регулярной основе.
Также важно, чтобы выполненная настройка не влияла на производительность.
Определите похожие и специальные запросы, которые часто выполняются.
Если эти запросы будут идентифицированы, база данных изменится, и для этих запросов можно будет добавить новые индексы.
Если эти запросы идентифицированы, то могут быть созданы новые агрегаты специально для тех запросов, которые приведут к их эффективному выполнению.