Оптимизация структур данных
Правильно построенная модель БД позволяет избежать проблем со скоростью доступа к информации, а также обеспечивает возможность дальнейшего масштабирования БД и подключения дополнительных источников данных. Хорошо построенная модель данных может сделать систему быстрой, гибкой и функциональной. Критериями оптимальности модели БД являются скорость поиска, уменьшение числа связей таблиц, стандартизация структур данных.
Главными задачами системы мониторинга БД является [4]:
обнаружение неполадок и отказов;
гибкие возможности оповещения;
автоматическое исправление неполадок;
настройка на новые (нестандартные) показатели.
Как можно улучшить структуру БД?
Оптимизация структур данных
Правильно построенная модель БД позволяет избежать проблем со скоростью доступа к информации, а также обеспечивает возможность дальнейшего масштабирования БД и подключения дополнительных источников данных. Хорошо построенная модель данных может сделать систему быстрой, гибкой и функциональной. Критериями оптимальности модели БД являются скорость поиска, уменьшение числа связей таблиц, стандартизация структур данных. Модель БД должна содержать структуры таблиц, отражающие измерения во времени или жизненный цикл объекта хранения в БД, а также статические свойства объектов (атрибуты метаданных). Избегайте добавления новых полей в БД, иначе рано или поздно экран ввода информации будет представлять собой форму с множеством полей. А главное никто не будет заполнять все поля этой формы. Модели данных должны быть построены для физического уровня хранения данных, усвоения данных на уровне бизнес-логики и для презентационного уровня, рис.1.
Рисунок 1 - Схема уровней представления данных [12]
Физический уровень отвечает за сбор информации из используемых источников данных, их очистку, агрегацию и загрузку в БД. На проектирование физической модели БД влияют следующие параметры СУБД:
размер табличных пространств для хранения таблиц, индексов, полей BLOB;
кластеры и их параметры;
размер словаря данных, включая все хранимые процедуры, функции, триггеры, пакеты, команды SQL;
управляющие файлы;
файлы журнала работы процессов;
интенсивность потока запросов, модифицирующих данные и индексы;
файлы временных табличных пространств (для хранения временных таблиц, которые строятся, например, при выполнении group by, а также других временных объектов);
интенсивность потока запросов, инициирующих создание временных таблиц;
потоки транзакций read-write, read-only, объем модифицируемых и считываемых ими данных, характеристики параллельной работы транзакций (какие и сколько их);
количество приложений, работающих параллельно с БД;
количество соединений с БД для каждого приложения;
файлы параметров старта ядра СУБД;
загрузочные модули ядра и утилиты СУБД;
входные и выходные данные, генерируемые пользовательскими программами;
скрипты управления СУБД.
Уровень бизнес-логики преобразует данные из структур физического уровня в структуры, предназначенные для решения конкретных задач. Здесь происходит вычисление показателей и индикаторов, строятся иерархии, и для каждой предметной области связываются в схемы, используемые в ней таблицы фактов и метаданных. Правильно построенная модель бизнес-логики обеспечивает конечных пользователей полноценным для решения поставленных задач набором показателей, а также позволяет добавлять новые предметные области и описывать дополнительные объекты [2,3].
Модель бизнес-логики является самым сложным объектом БД. Модель бизнес-логики должна быстро адаптироваться под требования бизнеса, повышать в конечном итоге его успешность. Модель должна позволять оперативно создавать и изменять сотни показателей, измерений. Аналитик должен достаточно быстро выбрать список необходимых показателей и затем очень долго подбирать набор условий, которыми он хочет ограничить выборку и в разрезе которых рассчитать эти показатели. Причем сначала он использует одно условие, затем, увидев результат, накладывает дополнительное условие и т.д. Таким образом, оптимальность модели во многом зависит от того, насколько быстро аналитик сможет определить набор условий в виде списка показателей, которыми он хочет ограничиться. Для каждой задачи рекомендуется создать отдельное view-представление показателей и индикаторов, действительно необходимых для ее решения [6]. На уровне модели бизнес-логики можно проводить расчет показателей, алгоритм вычисления которых может изменяться. Такой подход позволяет избежать проблем с показателями, которые в разных случаях должны рассчитываться по-разному, а также повысить скорость и удобство работы конечного пользователя, предоставляя ему действительно необходимый для поддержки решения набор атрибутов.
Презентационный уровень содержит показатели, переведенные в понятия конкретной предметной области. На этом уровне подготовленные и рассчитанные на уровне бизнес-логики показатели проецируются в соответствующие отчеты для конечных пользователей.
Рекомендации. Создавайте стабильные и легко поддерживаемые структуры. Сведение нескольких таблиц к view-представлению означает, что большинство изменений затронет только одну таблицу. Рекомендации по использованию структур данных [1]:
храните множество используемых классификаторов в одной таблице за счет добавления нового атрибута «Идентификатор классификатора»;
используйте счетчики повторяющихся групп в иерархических структурах данных;
применяйте многомерные структуры при необходимости создания множества таблиц для родственных объектов и словари атрибутов для обозначения свойств атрибутов;
создавайте каталоги данных для организации хранения и поиска объектных файлов (документов, графических файлов, др.);
типизируйте структуры данных для временных рядов, сеточных данных, каталогов;
разрабатывайте обобщенные атрибуты данных, например, вместо создания для каждого произведенного товара своего имени атрибута (количество компьютеров, ТВ, холодильников, др.), используйте следующие атрибуты: Товар: тип, Товар: объем, Товар: единица измерений;
не детализируйте сущности, а создавайте общую концепцию и выделяйте основные сущности;
описываемые сущности храните в XML-схемах, что позволяет добавлять объекты и атрибуты без вероятности потери ранее записанных данных и без необходимости глубоко изучать предметную область;
для всех сущностей выделяйте общие поля (идентификатор, дата/время создания, дата/время редактирования, автор, в том числе поля для организации связи между сущностями и т.д.);
пользовательский интерфейс создавайте в виде синхронизированных атрибутов на основе их значений в БД.
Какие методы оптимизации можно применить?
Основными направлениями повышения эффективности работы БД являются: оптимизация производительности БД, оптимизация кода, оптимизация работы СУБД, оптимизация структур данных, автоматизация мониторинга работы БД.
Оптимизация производительности БД
Производительность СУБД оценивается:
временем выполнения запросов;
скоростью поиска информации в неиндексированных полях;
временем выполнения операций импортирования БД из других форматов;
скоростью создания индексов и выполнения таких массовых операций, как обновление, вставка, удаление данных;
максимальным числом параллельных обращений к данным в многопользовательском режиме;
временем генерации отчетов.
Оптимизация кода запросов
Ресурсоемкие операции это запросы, содержащие операторы DISTINCT, UNION, MINUS, INTERSECT, ORDER BY или GROUP BY, которые заставляют СУБД выполнять операцию сортировки. Оператор DISTINCT требует выполнить одну операцию сортировки, другие операторы заставляют ядро выполнить как минимум две операции сортировки. Всегда следует искать другие пути выполнения подобных запросов. Большинство запросов, содержащих UNION, MINUS и INTERSECT, могут быть выполнены иными способами. Не делайте ненужных объединений (joins).
Первым шагом в оптимизации запроса должно быть исключение полного сканирования таблицы. Для первоначальной оптимизации запросов рекомендуется использовать команду EXPLAIN PLAN. Использование индексов в запросах оправдано, если запрос извлекает меньше 15% строк из таблицы. Во всех остальных случаях полный просмотр таблицы (Full Table Scan FTS) будет работать быстрее.
Одна из наиболее медленных команд в SQL это команда UPDATE. Это является следствием того, что большинство согласованных изменений в таблицах требуют полного просмотра таблиц. В результате этого эти операции являются ресурсоемкими и очень медленными, когда таблицы слишком большие.
Оптимизация работы СУБД
Для оптимизации работы СУБД существует несколько способов, это:
блокировка доступа к данным при наличии конфликтующих одновременных обращений;
использование серверов приложений;
эффективное использование оперативной памяти и памяти на дисках;
правильный выбор размера буфера ввода/вывода;
кэширование данных;
повышение эффективности работы сети;
работа с объектными файлами.