Оптимизация структуры базы данных

Направления оптимизации работы с базой данных.

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

Оптимизация зависит от многих факторов, которые можно разбить на три группы:

• оптимизация структуры базы данных;

• оптимизация запросов;

• оптимизация клиентского приложения.

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

Для обеспечения оптимального доступа к информации в базе данных при проектировании физической и логической структуры следует учитывать ряд факторов:

· нормализация таблиц;

· методы доступа к данным;

· физическая характеристика базы данных.

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

Кроме того, на практике высокая степень нормализации таблиц приводит к большому количеству таблиц, в результате чего структура информации в базе данных не воспринимается разработчиком целостно. Невозможность целостного представления структуры данных в базе данных является одним из "человеческих факторов", способных внести серьезные ошибки в структуру базы данных уже на стадии ее разработки, что впоследствии может иметь самые серьезные – и всегда негативные – последствия.

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

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

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

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

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

Решением указанных проблем является периодическое создание резервной копии и восстановление из нее базы данных. При этом:

· собирается "мусор", т.е. версии записей, которые далее не будут востребованы;

· устраняются "дыры" на страницах базы данных, образовавшиеся после удаления записей;

· каждая таблица размещается в непрерывном блоке страниц.

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

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

Дата добавления: 2014-01-04