Используется как внешняя память для хранения базы данных

Обновлено: 07.07.2024

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

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

Что необходимо для организации системы хранения данных

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

На создание системы уходит от одного месяца до полугода.

Локальные и сетевые СХД: отличия и особенности

Еще несколько лет назад проблема хранения информации решалась наращиванием емкости СХД с архитектурой DAS : устройств внешней памяти, подключаемых к серверу и используемых им. При создании множества DAS-систем появляется большое количество СХД, разобщенных по сети компании, затратных в обслуживании. Данные системы не способны совместно использовать емкости хранения разных серверов и распределять данные между ними: емкость хранения задействуется лишь на 40 %. Поэтому увеличение количества систем DAS не способно решить проблему хранения информации.

Пересмотр подходов к построению СХД привел к появлению концепции сетевого хранения данных в централизованных хранилищах. В ее рамках стали развиваться две технологии: сети хранения SAN и сетевые хранилища NAS.

· СХД с архитектурой NAS − это системы, которые подключаются к локальной вычислительной сети. Оптимальны для организации надежных хранилищ информации в центрах обработки данных среднего и малого звена с необходимостью доступа большого числа рабочих станций и разнородных серверов. Пропускная способность СХД при пиковой нагрузке не должна быть более 150−200 Мбайт/с.

· СХД с архитектурой SAN позволяют хранилищам обмениваться данными между собой и с компьютерными системами на высокой скорости. Фактическим стандартом является FC-технология Fibre Channel с блочным доступом к данным со скоростью передачи данных по сети 1−2 Гбит/с на расстояния до 100 км по медному кабелю или оптоволокну. К высокоскоростной сети может быть подключено множество серверов приложений. Высокомасштабируемые СХД с архитектурой SAN на основе технологии Fibre Channel используются для центров обработки информации с высокопроизводительными серверами приложений и базами данных.

Основные требования, предъявляемые к современным СХД

Современные СХД должны отвечать следующим требованиям:

· высокая производительность. Достаточное число внутренних и внешних интерфейсов, объем кеш-памяти, гибкие настройки, конфигурирование системы;

· надежность и отказоустойчивость. Резервирование всех компонентов, мощная система мониторинга и своевременное оповещение о проблемах;

· доступность информации. Функции сохранения целостности данных, а также обновление ПО и оборудования в функционирующую СХД без остановки комплекса;

· управляемость и контролируемость. Управление СХД через командную строку или web-интерфейс, полный мониторинг системы и др.;

· масштабируемость. Наращивание объема кеш-памяти и функционала без потерь производительности.

Системы хранения данных Huawei: особенности и преимущества

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

• OceanStor Dorado V3: флеш-система хранения на базе NVMe, для коммерческого использования. Применение Huawei FlashlinkTM позволило повысить производительность системы до 7 млн. операций ввода-вывода/сек. при задержке 0,5 мс и ускорить работу приложений в 3 раза. Коэффициент сжатия данных 3:1 обеспечивает сокращение эксплуатационных расходов на 75 %. Высокопроизводительное, быстродействующее решение для поддержки критически важных приложений с доступностью на уровне 99,9999 %.

• OceanStor 5300/5500/5600/5800 V3 : конвергентные СХД среднего класса. Обеспечивают одновременную бесперебойную работу множества приложений, консолидацию ресурсов хранения и восстановление после ошибок. Оптимальное решение для крупных баз данных OLTP/OLAP, обмена файлами и облачных вычислений в различных отраслях.

• OceanStor 18500/18800 V5: гибридные флеш-системы с интеллектуальной архитектурой SmartMatrix 2.0. Оптимизируют обработку и хранение информации важных корпоративных приложений, ускоряют переход на работу в гибридном облаке. Подходят для реализации проектов крупных баз данных OLTP/OLAP и облачных вычислений, хранения информации во всех секторах экономики.

• FusionStorage: масштабируемая, полностью распределенная ОС. Встроенное ПО объединяет диски стандартных серверов x86 в пул хранения, обеспечивает доступ верхнего уровня к объектам объектного, блочного и файлового хранения. Производительность − до 10 млн IOPS и емкость до эксабайтного уровня.

• OceanStor SNS5604/SNS5608 : специализированные коммутаторы для сетевой инфраструктуры для поддержки критически важных приложений в ЦОДах. Стандартные протоколы Fiber Channel версии Gen 6, технологии Fabric Vision и IO Insight определяют производительность устройства до 32 Гбит/с, а также расширенные возможности масштабирования.

• OceanStor DJ – ПО для сервис-ориентированного управления СХД. Повышает эффективность работы ЦОДов благодаря поддержке гибкой оркестровки сервисных каталогов, унифицированного сервис-ориентированного управления ресурсами хранения, а также автоматическому развертыванию сервисов и приложений хранения и обработки данных.

Продуктами СХД от Huawei пользуются более 8000 компаний из 150 стран мира.

Более точно, к числу функций СУБД принято относить следующие:

1. Непосредственное управление данными во внешней памяти

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

2. Управление буферами оперативной памяти

СУБД обычно работают с БД значительного размера; по крайней мере, этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти . Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX ), этого недостаточно для целей СУБД , которая располагает гораздо большей информацией о полезности буферизации той или иной части БД . Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.

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

3. Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое.

Либо транзакция успешно выполняется, и СУБД фиксирует изменения БД , произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД .

Понятие транзакции необходимо для поддержания логической целостности БД . Приведем пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД ). Но понятие транзакции гораздо более важно в многопользовательских СУБД .

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

4. Журнализация

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД ( по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.

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

Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД ), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД . Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД . Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД , выполненных в этой транзакции, и производить откат транзакции, путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).

5. Поддержка языков БД

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

язык определения схемы БД (SDL - Schema Definition Language) и
язык манипулирования данными ( DML - Data Manipulation Language ).

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

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД , начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык запросов SQL (Structured Query Language ).

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

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

Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL . Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь , создавший таблицу БД , обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.

Функциональные возможности СУБД

По степени универсальности различают два класса СУБД :

системы общего назначения - реализованные как программный продукт, способный функционировать на ЭВМ в определённой операционной системе и поставляемый пользователям как коммерческое изделие;
специализированные системы - создаваемые в случаях невозможности или не целесообразности использования СУБД общего назначения.

СУБД общего назначения - это сложные программные комплексы, предназначенные для выполнения всей совокупности функций, связанных с созданием и эксплуатацией БД информационной системы.

Рынок программного обеспечения ПК располагает большим числом разнообразных по своим функциональным возможностям коммерческих систем СУБД общего назначения.

СУБД - лидеры на рынке программ:

dBASE IV, компании Borland International;
Microsoft Access 2007;
Microsoft FoxPro 2.6 for DOS;
Microsoft FoxPro for Windows, Microsoft Corp:
Paradox for DOS 4.5:
Paradox for Windows, версия 4.5 Borland.

Производительность СУБД оценивается:

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

На производительность СУБД оказывают влияния 2 фактора:

правильное проектирование
построения БД.

СУБД , которые следят за соблюдением целостности данных, несут дополнительную нагрузку, которую не испытывают другие программы;

Целостность данных подразумевает наличие средств, позволяющих удостовериться, что информация в БД всегда остаётся корректной и полной.

Операции , обеспечивающие безопасность :

шифрование прикладных программ;
шифрование данных;
защита паролем;
ограничение уровня доступа

Хороший уровень безопасности в СУБД dBase IV, Access

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

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

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

Краткие итоги

Рассмотрены вопросы классификации БД и СУБД .

По технологии обработки данных БД делятся на централизованные БД и распределённые БД . Централизованные БД могут быть с сетевым доступом. Архитектуры систем централизованных БД с сетевым доступом подразделяются на файл-сервер и клиент- сервер . Распределённая БД разделяется по способу доступа к данным БД с локальным и удаленным доступом.

СУБД - классифицируются по языкам общения и по выполняемым функциям.

Для системы управления базой данных сложились три языка: язык описания данных (ЯОД), язык манипулирования данными (ЯМД), язык запросов .

Основные функции СУБД : непосредственное управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями , журнализация , поддержка языков БД .

По степени универсальности различают два класса СУБД : системы общего назначения , специализированные системы.

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

Хранение данных во внешней памяти в известных СУБД (Oracle, IBM DB2, Microsoft SQL Server, CA-OpenIngres, решения от Sybase и Informix и др.) организовано очень похожим образом.

Организация хранения

Основными единицами физического хранения являются блок данных, экстент, файл (либо раздел жесткого диска). Логический уровень представления информации включает пространства (либо табличные пространства). Блок данных (block) или страница (page) является единицей обмена с внешней памятью. Размер страницы фиксирован для базы данных (Oracle) или для ее различных структур (DB2, Informix, Sybase) и устанавливается при создании. Очень важно сразу правильно выбрать размер блока: в работающей базе изменить его практически невозможно (для этого часто проводят ряд испытаний базы данных-прототипа).

Администратор отводит пространство для базы данных на внешних устройствах большими фрагментами: файлами и разделами диска. В первом случае доступ к диску осуществляется операционной системой, что дает определенные преимущества, например, работа с файлами средствами ОС. Во втором случае с внешним устройством работает сам сервер. При этом достигается более высокая производительность; кроме того, использование дисков необходимо в случае, если кэш ОС не может работать в режиме сквозной (write-through) записи. Диски особенно эффективны для ускорения операций записи данных (подобный механизм поддерживается Oracle, DB2 и Informix; например, в DB2 данная единица размещения называется контейнером).

Пространством внешней памяти, отведенным ему администратором, сервер управляет с помощью экстентов (extent), т.е. непрерывных последовательностей блоков. Информация о наличии экстентов для объекта схемы данных находится в специальных управляющих структурах, реализация которых зависит от СУБД. На управление экстентами (выделение пространства, освобождение, слияние) тратятся определенные ресурсы, поэтому для достижения эффективности нужно правильно определять их параметры. СУБД от Oracle, IBM, Informix позволяют определять параметры этих структур, а в Sybase экстенты имеет постоянный размер, равный 8 страницам. Уменьшение размера экстента будет способствовать более эффективному использованию памяти, однако при этом возрастают накладные расходы на управление большим количеством экстентов, что может замедлить операции вставки большого количества строк в таблицу. Кроме того, сервер может иметь ограничение на максимальное количество экстентов для таблицы. При слишком большом размере экстентов могут возникнуть проблемы с выделением для них необходимого количества памяти. Обычно определяется размер начального экстента, размер второго и правило определения размеров следующих экстентов. На рис. 2 иллюстрируется взаимосвязь блоков, экстентов и файлов баз данных.

В Informix существует еще одна единица физического хранения, промежуточная между файлом (или разделом диска) и экстентом, — это «чанк» (от английского chunk, что дословно переводится как «емкость»). Чанк позволяет более гибко управлять очень большими массивами внешней памяти. В одном разделе диска или файле администратор может создать несколько чанков. Чанк также служит единицей зеркалирования.

Общим для СУБД Oracle, DB2 и Informix является понятие пространства (для Oracle и DB2 это табличное пространство). Различные логические структуры данных, такие как таблицы и индексы, временные таблицы и словарь данных размещены в табличных пространствах. В DB2 и Informix дополнительно можно устанавливать размер страницы отдельно для каждой из этих структур. Группировка хранимых данных по пространствам производится по ряду признаков: частота изменения данных, характер работы с данными (преимущественно чтение или запись и т.п.), скорость роста объема данных, важность и т.п. Таким образом, например, только читаемые таблицы помещаются в одно пространство, для которого установлены одни параметры хранения, таблицы транзакций размещаются в пространстве с другими параметрами и т.д. (рис. 3).

Одна логическая единица данных (таблица или индекс) размещается точно в одном пространстве, которое может быть отображено на несколько физических устройств или файлов. При этом физически разнесены (располагаться на разных дисках) могут не только логические единицы данных (таблицы отдельно от индексов), но и данные одной логической структуры (таблица на нескольких дисках). Такой способ хранения называется горизонтальной фрагментацией: таблица делится на фрагменты по строкам. В Oracle вместо термина «фрагментация» используется «секционирование» (partitioning). Фрагментация — один из способов повышения производительности.

Могут применяться различные схемы записи данных во фрагментированные таблицы. Одна из них — круговая (round-robin), когда некоторая часть вставляемых в таблицу строк записывается в первый фрагмент, другая часть — в следующий и так далее по кругу. В данном случае за счет распараллеливания может быть увеличена производительность операций модификации данных и запросов. Существует и другая схема, включающая логическое разделение строк таблицы по ключу («кластеризация»). Данная схема позволяет избежать перерасхода процессорного времени и уменьшить общий объем операций ввода/вывода. Ее суть в том, что при создании таблицы все пространство значений ключа таблицы разбивается на несколько интервалов, а строкам с ключами, принадлежащими разным интервалам, назначаются различные месторасположения. Впоследствии, при обработке запроса, данная информация учитывается оптимизатором. Если производится поиск по ключу, то оптимизатор может удалять из рассмотрения фрагменты таблицы, не удовлетворяющие условию выборки. Например, создание кластеризованной таблицы будет выглядеть следующим образом (этот и все остальные SQL-скрипты приведены для Oracle):

Здесь создаются два раздела part1 и part2, каждый из которых размещен в своем табличном пространстве (tblspace1 и tblspace2). Записи со значением поля num от 1 до 499 будут располагаться в первом разделе, а записи с номерами от 500 до 1000 — во втором (рис. 4).

Тогда при запросе:

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

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

Методы доступа

Современные СУБД предоставляют достаточно широкий набор различных методов доступа, которые чаще всего являются теми или иными видами индексирования — способа отображения ключа индексирования в адрес хранимой записи. Используются следующие типы индексных структур: на основе B-дерева (B-tree); на основе хэш-функции или хеширование (hashing); на базе битовых шкал или индексов (bitmap). Индекс может служить различным целям: для ускорения доступа к записям одной таблицы и для ускорения операций соединения, тогда он называется индексом соединения. Если в качестве ключа индексирования используется некоторая функция атрибутов таблицы, такой индекс называют «основанным на функции» (function-based). Скажем, можно создать такой индекс для ускорения поиска с учетом регистра символов для таблицы Famous (таблица 1):

Отличают также «кластеризованный» (clustered) индекс. При его использовании все записи таблицы упорядочиваются по его ключу; поэтому кластеризованный индекс более экономно расходует память и обычно быстрее опрашивается. Для таблицы, таким образом, можно создать лишь один такой индекс.

B-деревья универсальны и обеспечивают хорошую скорость доступа как при просмотрах по диапазонам, так и при выборке единичной записи по значению ключа, однако характеризуются относительно большим объемом памяти для хранения и затратами на поддержание в актуальном состоянии, включающими обычно балансировку дерева. Такой индекс имеет один существенный недостаток — он может быть использован только в запросах по ведущим столбцам. Например, если в таблице Famous создан составной индекс по столбцам fullname, birth и sex:

смогут использовать этот индекс, а в следующих запросах:

оптимизатор не сможет им воспользоваться, что связано с архитектурными особенностями данного типа индексирования. В данном примере индекс может быть использован при запросах по fullname, birth, sex либо fullname, birth либо только fullname. Несмотря на этот недостаток, индексы B-деревьев наиболее распространены и используются во всех рассматриваемых СУБД. Для B-дерева можно задать «степень использования страницы индекса» (fillfactor); так, в Oracle используются параметры PCTUSED и PCTFREE для блоков базы данных в том числе и индексных. При создании индекса его страницы заполняются только на указанный процент (рис. 5). При увеличении процента использования страницы увеличится скорость операций изменения индекса, однако возрастут также расходы на хранение и может увеличиться время выполнения запросов.

Каждая СУБД может иметь ряд дополнительных параметров, предоставляющих разработчику расширенные возможности конфигурирования В-деревьев.

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

Битовые индексы также очень компактны и полезны для столбцов с большим процентом повторения значений ключа. Обычно используют следующее правило: если количество повторяющихся значений столбца более 99% от общего количества строк таблицы, тогда целесообразно рассмотреть использование битового индекса. Так, таблица Famous могла бы выиграть от использования двух битовых индексов — по столбцам SEX и MARRIED.

Битовые индексы обладают очень важным свойством: если производится запрос, включающий сложное условие выборки, которое составлено из предикатов OR, AND, NOT и «=», то оптимизатор может использовать имеющиеся по конкретным столбцам битовые индексы, объединяя их. B-деревья этого делать не позволяют (для этого потребовалось бы построить составной индекс по этим столбцам, специально для ускорения данного запроса). В рассматриваемом примере запрос вида:

может использовать оба битовых индекса emp_ind_02 и emp_ind_03. Однако тот же запрос не сможет использовать два отдельных индекса по этим же столбцам. Битовые карты полезны в хранилищах, где преобладают длинные транзакции и данные читаются чаще чем записываются, однако они неэффективны в приложениях с короткими транзакциями, характерными для OLTP-систем.

В DB2 используется оптимизированный вариант B-дерева с двунаправленными указателями и «упреждающей регистрацией обновлений» (write-ahead logging), что позволяет ускорить вставку данных. При создании индекса можно также использовать некоторые опции, например, указать серверу о необходимости хранить в структуре индекса дополнительные часто запрашиваемые значения атрибутов.

В СУБД Oracle помимо многочисленных индексов используются «индексно-упорядоченные» (index-organized) таблицы и кластеры. В первом случае вся таблица индексирована по первичному ключу и организована в виде B-дерева.

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

Экономия времени при выполнении таких запросов может составлять от 15 до 400% в зависимости от длины строки [1].

Кластер Oracle — это структура для хранения одной или нескольких таблиц, главным образом служащая для ускорения операций их соединения, в которой строки таблиц, удовлетворяющие условию соединения, хранятся вместе. Столбцы, используемые для соединения, называются кластерным ключом. Значения кластерного ключа сохраняются один раз (дубликаты исключаются). Для доступа по кластерному ключу могут использоваться как B-деревья, так и хэш-структуры, в этом случае кластер является хэш-кластером. Стоит также упомянуть битовый индекс соединения (bitmap join), ускоряющий операции объединения таблиц. В Sybase используются B-деревья, а индекс может быть как кластеризованным так и обычным. В Informix можно применять кластеризованные, битовые и индексы, основанные на функции.

Проблемы управления внешней памятью

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

Фрагментация неизбежна и поэтому является нормальным явлением, и не всегда ухудшает характеристики базы данных. Индексы также подвержены проблемам фрагментации пространства, и могут стать несбалансированными, поэтому SQL-оператор ALTER INDEX обычно имеет опцию REBUILD, позволяющую перестроить индекс. Индекс также можно удалить и создать заново даже в работающей базе данных.

Заключение

Эффективность использования любых методов доступа зависит от распределения данных в запрашиваемых таблицах, от стратегии работы оптимизатора СУБД и от возможностей диалекта SQL. Поэтому приведенные рекомендации носят достаточно общий характер — все определяется конкретной ситуацией. Решения, принимаемые на этапах физического проектирования и настройки, чаще всего представляют собой компромисс между достижением требуемых характеристик, которые часто противоречат друг другу. За выигрыш в скорости обработки запросов, которую дает индекс, приходится платить дополнительными ресурсами памяти на его размещение и процессорным временем для его поддержки в актуальном состоянии. К сожалению, трудно привести конкретные оценки: многое зависит от конфигурации сервера, настройки ОС и СУБД и т.п.

Рассмотренный перечень методов доступа не является полным. Описаны лишь распространенные технологии, которые можно назвать традиционными. Например, за кадром остались возможности современных СУБД, связанные с реализацией расширяемой системы типов данных. Сюда относят технологии расширителей (Extender) IBM, DataBlade (Informix) и картриджей (Oracle). Тем не менее, перечисленный арсенал средств достаточно богат сам по себе. Адекватное представление об этих средствах позволяет сделать проектируемые базы данных и их приложения менее зависимыми от конкретной СУБД.

Жесткие диски (винчестеры). Из всех внешних устройств храненияданных они обеспечивают наиболее быстрый доступ к данным, высокие скорости чтения и записи данных, поэтому применяются не только для хранениябазы данных, но и для работы с информацией базы данных, так как обеспечивают быстрое выполнение запросов к базе.

CD-ROM(компакт-диск) – это один из видов оптических накопителейинформации, при работе которых используется лазерная технология. Онпредставляет собой компакт-диск, предназначенный только для чтения предварительно записанной на него информации с помощью соответствующегоустройства – привода. Доступ к данным на CD-ROM осуществляется быстрее,чем к данным на дискетах, но медленнее, чем на жестких дисках.

DVD-диски – универсальные цифровые диски (DigitalVersatileDisk).Имея те же габариты, что обычные компакт-диски и похожий принцип работы, они вмещают больше информации: от 4,7 до 17 Гб. В настоящее времяDVD-диски применяются в двух областях: для хранения сверхбольших базданных и видеофильмов.

Оптические библиотеки– это устройства для хранения большихобъемов данных. В них может быть объединено более десяти приводовдля чтения с CD-ROM и DVD-ROM, а также одновременно установленосвыше 500 компакт-дисков.

Приложения и компоненты базы данных. Словарь данных. Пользователи базы данных.

Приложения базы данных включают такие объекты для работы с базой данных как формы, отчеты, Web-страницы и прикладные программы. Формы, отчеты и Web-страницы можно создавать с помощью средств, поставляемых в комплекте с СУБД (например, в СУБД Access имеются средства конструирования таких объектов, называемые элементами управления). Прикладные программы должны быть написаны либо на входном языке СУБД (например, модули в Access), либо на одном из стандартных языков программирования и затем с помощью СУБД соединены с базой данных.

характеристика объектов приложений баз данных

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

Отчеты - это форматированное отображение информации из базы данных при выводе на печать.

Web-страницы используются для просмотра, редактирования, обновления, удаления, отбора, группировки и сортировки изменяющихся данных базы данных в Microsoft Internet Explorer.

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

Данные пользователя в большинстве современных баз данных представляются в виде набора таблиц, состоящих из строк (записей) и столбцов (полей).

Метаданные представляют собой описание структуры базы данных с помощью так называемых системных таблиц.

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

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

Читайте также: