Что определяет структура хранения данных определенного типа
Как устроены хранилища данных: обзор для новичков
Международный рынок гипермасштабируемых дата-центров растет с ежегодными темпами в 11%. Основные «драйверы» — предприятия, подключенные устройства и пользователи — они обеспечивают постоянное появление новых данных. Вместе с объемом рынка растут и требования к надежности хранения и уровню доступности данных.
Ключевой фактор, влияющий на оба критерия — системы хранения. Их классификация не ограничивается типами оборудования или брендами. В этой статье мы рассмотрим разновидности хранилищ — блочное, файловое и объектное — и определим, для каких целей подходит каждое из них.
Типы хранилищ и их различия
Хранение на уровне блоков лежит в основе работы традиционного жесткого диска или магнитной ленты. Файлы разбиваются на «кусочки» одинакового размера, каждый с собственным адресом, но без метаданных. Пример — ситуация, когда драйвер HDD пишет и считывает блоки по адресам на отформатированном диске. Такие СХД используются многими приложениями, например, большинством реляционных СУБД, в списке которых Oracle, DB2 и др. В сетях доступ к блочным хостам организуется за счет SAN с помощью протоколов Fibre Channel, iSCSI или AoE.
Файловая система — это промежуточное звено между блочной системой хранения и вводом-выводом приложений. Наиболее распространенным примером хранилища файлового типа является NAS. Здесь, данные хранятся как файлы и папки, собранные в иерархическую структуру, и доступны через клиентские интерфейсы по имени, названию каталога и др.
При этом следует отметить, что разделение «SAN — это только сетевые диски, а NAS — сетевая файловая система» искусственно. Когда появился протокол iSCSI, граница между ними начала размываться. Например, в начале нулевых компания NetApp стала предоставлять iSCSI на своих NAS, а EMC — «ставить» NAS-шлюзы на SAN-массивы. Это делалось для повышения удобства использования систем.
Что касается объектных хранилищ, то они отличаются от файловых и блочных отсутствием файловой системы. Древовидную структуру файлового хранилища здесь заменяет плоское адресное пространство. Никакой иерархии — просто объекты с уникальными идентификаторами, позволяющими пользователю или клиенту извлекать данные.
Марк Горос (Mark Goros), генеральный директор и соучредитель Carnigo, сравнивает такой способ организации со службой парковки, предполагающей выдачу автомобиля. Вы просто оставляете свою машину парковщику, который увозит её на стояночное место. Когда вы приходите забирать транспорт, то просто показываете талон — вам возвращают автомобиль. Вы не знаете, на каком парковочном месте он стоял.
Большинство объектных хранилищ позволяют прикреплять метаданные к объектам и агрегировать их в контейнеры. Таким образом, каждый объект в системе состоит из трех элементов: данных, метаданных и уникального идентификатора — присвоенного адреса. При этом объектное хранилище, в отличие от блочного, не ограничивает метаданные атрибутами файлов — здесь их можно настраивать.
/ 1cloud
Применимость систем хранения разных типов
Блочные хранилища
Блочные хранилища обладают набором инструментов, которые обеспечивают повышенную производительность: хост-адаптер шины разгружает процессор и освобождает его ресурсы для выполнения других задач. Поэтому блочные системы хранения часто используются для виртуализации. Также хорошо подходят для работы с базами данных.
Недостатками блочного хранилища являются высокая стоимость и сложность в управлении. Еще один минус блочных хранилищ (который относится и к файловым, о которых далее) — ограниченный объем метаданных. Любую дополнительную информацию приходится обрабатывать на уровне приложений и баз данных.
Файловые хранилища
Среди плюсов файловых хранилищ выделяют простоту. Файлу присваивается имя, он получает метаданные, а затем «находит» себе место в каталогах и подкаталогах. Файловые хранилища обычно дешевле по сравнению с блочными системами, а иерархическая топология удобна при обработке небольших объемов данных. Поэтому с их помощью организуются системы совместного использования файлов и системы локального архивирования.
Пожалуй, основной недостаток файлового хранилища — его «ограниченность». Трудности возникают по мере накопления большого количества данных — находить нужную информацию в куче папок и вложений становится трудно. По этой причине файловые системы не используются в дата-центрах, где важна скорость.
Объектные хранилища
Что касается объектных хранилищ, то они хорошо масштабируются, поэтому способны работать с петабайтами информации. По статистике, объем неструктурированных данных во всем мире достигнет 44 зеттабайт к 2020 году — это в 10 раз больше, чем было в 2013. Объектные хранилища, благодаря своей возможности работать с растущими объемами данных, стали стандартом для большинства из самых популярных сервисов в облаке: от Facebook до DropBox.
Такие хранилища, как Haystack Facebook, ежедневно пополняются 350 млн фотографий и хранят 240 млрд медиафайлов. Общий объем этих данных оценивается в 357 петабайт.
Хранение копий данных — это другая функция, с которой хорошо справляются объектные хранилища. По данным исследований, 70% информации лежит в архиве и редко изменяется. Например, такой информацией могут выступать резервные копии системы, необходимые для аварийного восстановления.
Но недостаточно просто хранить неструктурированные данные, иногда их нужно интерпретировать и организовывать. Файловые системы имеют ограничения в этом плане: управление метаданными, иерархией, резервным копированием — все это становится препятствием. Объектные хранилища оснащены внутренними механизмами для проверки корректности файлов и другими функциями, обеспечивающими доступность данных.
Плоское адресное пространство также выступает преимуществом объектных хранилищ — данные, расположенные на локальном или облачном сервере, извлекаются одинаково просто. Поэтому такие хранилища часто применяются для работы с Big Data и медиа. Например, их используют Netflix и Spotify. Кстати, возможности объектного хранилища сейчас доступны и в сервисе 1cloud.
Благодаря встроенным инструментам защиты данных с помощью объектного хранилища можно создать надежный географически распределенный резервный центр. Его API основан на HTTP, поэтому к нему можно получить доступ, например, через браузер или cURL. Чтобы отправить файл в хранилище объектов из браузера, можно прописать следующее:
После отправки к файлу добавляются необходимые метаданные. Для этого есть такой запрос:
Богатая метаинформация объектов позволит оптимизировать процесс хранения и минимизировать затраты на него. Эти достоинства — масштабируемость, расширяемость метаданных, высокая скорость доступа к информации — делают объектные системы хранения оптимальным выбором для облачных приложений.
Однако важно помнить, что для некоторых операций, например, работы с транзакционными рабочими нагрузками, эффективность решения уступает блочным хранилищам. А его интеграция может потребовать изменения логики приложения и рабочих процессов.
Архитектура хранилищ данных: традиционная и облачная
Привет, Хабр! На тему архитектуры хранилищ данных написано немало, но так лаконично и емко как в статье, на которую я случайно натолкнулся, еще не встречал.
Предлагаю и вам познакомиться с данной статьей в моем переводе. Комментарии и дополнения только приветствуются!
Введение
Итак, архитектура хранилищ данных меняется. В этой статье рассмотрим сравнение традиционных корпоративных хранилищ данных и облачных решений с более низкой первоначальной стоимостью, улучшенной масштабируемостью и производительностью.
Хранилище данных – это система, в которой собраны данные из различных источников внутри компании и эти данные используются для поддержки принятия управленческих решений.
Компании все чаще переходят на облачные хранилища данных вместо традиционных локальных систем. Облачные хранилища данных имеют ряд отличий от традиционных хранилищ:
Традиционная архитектура хранилища данных
Следующие концепции освещают некоторые из устоявшихся идей и принципов проектирования, используемых для создания традиционных хранилищ данных.
Трехуровневая архитектура
Довольно часто традиционная архитектура хранилища данных имеет трехуровневую структуру, состоящую из следующих уровней:
Kimball vs. Inmon
Два пионера хранилищ данных: Билл Инмон и Ральф Кимбалл предлагают разные подходы к проектированию.
Подход Ральфа Кимбалла основывается на важности витрин данных, которые являются хранилищами данных, принадлежащих конкретным направлениям бизнеса. Хранилище данных — это просто сочетание различных витрин данных, которые облегчают отчетность и анализ. Проект хранилища данных по принципу Кимбалла использует подход «снизу вверх».
Подход Билла Инмона основывается на том, что хранилище данных является централизованным хранилищем всех корпоративных данных. При таком подходе организация сначала создает нормализованную модель хранилища данных. Затем создаются витрины размерных данных на основе модели хранилища. Это известно как нисходящий подход к хранилищу данных.
Модели хранилищ данных
В традиционной архитектуре существует три общих модели хранилищ данных: виртуальное хранилище, витрина данных и корпоративное хранилище данных:
Звезда vs. Снежинка
Схемы «звезда» и «снежинка» — это два способа структурировать хранилище данных.
Схема типа «звезда» имеет централизованное хранилище данных, которое хранится в таблице фактов. Схема разбивает таблицу фактов на ряд денормализованных таблиц измерений. Таблица фактов содержит агрегированные данные, которые будут использоваться для составления отчетов, а таблица измерений описывает хранимые данные.
Денормализованные проекты менее сложны, потому что данные сгруппированы. Таблица фактов использует только одну ссылку для присоединения к каждой таблице измерений. Более простая конструкция звездообразной схемы значительно упрощает написание сложных запросов.
Схема типа «снежинка» отличается тем, что использует нормализованные данные. Нормализация означает эффективную организацию данных так, чтобы все зависимости данных были определены, и каждая таблица содержала минимум избыточности. Таким образом, отдельные таблицы измерений разветвляются на отдельные таблицы измерений.
Схема «снежинки» использует меньше дискового пространства и лучше сохраняет целостность данных. Основным недостатком является сложность запросов, необходимых для доступа к данным — каждый запрос должен пройти несколько соединений таблиц, чтобы получить соответствующие данные.
ETL vs. ELT
ETL и ELT — два разных способа загрузки данных в хранилище.
ETL (Extract, Transform, Load) сначала извлекают данные из пула источников данных. Данные хранятся во временной промежуточной базе данных. Затем выполняются операции преобразования, чтобы структурировать и преобразовать данные в подходящую форму для целевой системы хранилища данных. Затем структурированные данные загружаются в хранилище и готовы к анализу.
В случае ELT (Extract, Load, Transform) данные сразу же загружаются после извлечения из исходных пулов данных. Промежуточная база данных отсутствует, что означает, что данные немедленно загружаются в единый централизованный репозиторий.
Данные преобразуются в системе хранилища данных для использования с инструментами бизнес-аналитики и аналитики.
Организационная зрелость
Структура хранилища данных организации также зависит от его текущей ситуации и потребностей.
Базовая структура позволяет конечным пользователям хранилища напрямую получать доступ к сводным данным, полученным из исходных систем, создавать отчеты и анализировать эти данные. Эта структура полезна для случаев, когда источники данных происходят из одних и тех же типов систем баз данных.
Хранилище с промежуточной областью является следующим логическим шагом в организации с разнородными источниками данных с множеством различных типов и форматов данных. Промежуточная область преобразует данные в обобщенный структурированный формат, который проще запрашивать с помощью инструментов анализа и отчетности.
Одной из разновидностей промежуточной структуры является добавление витрин данных в хранилище данных. В витринах данных хранятся сводные данные по конкретной сфере деятельности, что делает эти данные легко доступными для конкретных форм анализа.
Например, добавление витрин данных может позволить финансовому аналитику легче выполнять подробные запросы к данным о продажах, прогнозировать поведение клиентов. Витрины данных облегчают анализ, адаптируя данные специально для удовлетворения потребностей конечного пользователя.
Новые архитектуры хранилищ данных
В последние годы хранилища данных переходят в облако. Новые облачные хранилища данных не придерживаются традиционной архитектуры и каждое из них предлагает свою уникальную архитектуру.
В этом разделе кратко описываются архитектуры, используемые двумя наиболее популярными облачными хранилищами: Amazon Redshift и Google BigQuery.
Amazon Redshift
Amazon Redshift — это облачное представление традиционного хранилища данных.
Redshift требует, чтобы вычислительные ресурсы были подготовлены и настроены в виде кластеров, которые содержат набор из одного или нескольких узлов. Каждый узел имеет свой собственный процессор, память и оперативную память. Leader Node компилирует запросы и передает их вычислительным узлам, которые выполняют запросы.
На каждом узле данные хранятся в блоках, называемых срезами. Redshift использует колоночное хранение, то есть каждый блок данных содержит значения из одного столбца в нескольких строках, а не из одной строки со значениями из нескольких столбцов.
Redshift использует архитектуру MPP (Massively Parallel Processing), разбивая большие наборы данных на куски, которые назначаются слайсам в каждом узле. Запросы выполняются быстрее, потому что вычислительные узлы обрабатывают запросы в каждом слайсе одновременно. Узел Leader Node объединяет результаты и возвращает их клиентскому приложению.
Клиентские приложения, такие как BI и аналитические инструменты, могут напрямую подключаться к Redshift с использованием драйверов PostgreSQL JDBC и ODBC с открытым исходным кодом. Таким образом, аналитики могут выполнять свои задачи непосредственно на данных Redshift.
Redshift может загружать только структурированные данные. Можно загружать данные в Redshift с использованием предварительно интегрированных систем, включая Amazon S3 и DynamoDB, путем передачи данных с любого локального хоста с подключением SSH или путем интеграции других источников данных с помощью API Redshift.
Google BigQuery
Архитектура BigQuery не требует сервера, а это означает, что Google динамически управляет распределением ресурсов компьютера. Поэтому все решения по управлению ресурсами скрыты от пользователя.
BigQuery позволяет клиентам загружать данные из Google Cloud Storage и других читаемых источников данных. Альтернативным вариантом является потоковая передача данных, что позволяет разработчикам добавлять данные в хранилище данных в режиме реального времени, строка за строкой, когда они становятся доступными.
BigQuery использует механизм выполнения запросов под названием Dremel, который может сканировать миллиарды строк данных всего за несколько секунд. Dremel использует массивно параллельные запросы для сканирования данных в базовой системе управления файлами Colossus. Colossus распределяет файлы на куски по 64 мегабайта среди множества вычислительных ресурсов, называемых узлами, которые сгруппированы в кластеры.
Dremel использует колоночную структуру данных, аналогичную Redshift. Древовидная архитектура отправляет запросы тысячам машин за считанные секунды.
Для выполнения запросов к данным используются простые команды SQL.
Panoply
Panoply обеспечивает комплексное управление данными как услуга. Его уникальная самооптимизирующаяся архитектура использует машинное обучение и обработку естественного языка (NLP) для моделирования и рационализации передачи данных от источника к анализу, сокращая время от данных до значения как можно ближе к нулю.
Интеллектуальная инфраструктура данных Panoply включает в себя следующие функции:
По ту сторону облачных хранилищ данных
Облачные хранилища данных — это большой шаг вперед по сравнению с традиционными подходами к архитектуре. Однако пользователи по-прежнему сталкиваются с рядом проблем при их настройке:
Организация БД и структуры хранения данных
БД Oracle предоставляет полностью независимое определение логических и физических структур данных. Логическим элементом данных является сегмент. Существуют различные виды сегментов; типичным примером является таблица. Сегменты физически хранятся в файлах данных. Разделение физического и логического представления данных осуществляется путём ввода понятия tablespace. Связь физических и логических представлений хранится в словаре данных.
Физические структуры БД
Существуют три основных типа файлов из которых состоит БД Oracle, плюс дополнительные файлы которые хранятся отдельно от БД и грубо говоря не необходимы. Необходимые файлы это файл управления (controlfile), файл логов (online redo log files) и файлы данных. Дополнительные файлы которые обычно присутствуют (существуют ещё другие для дополнительной настройки) это файл параметров инициализации, файл паролей, архив логов и т.п.
Файл контроля / Controlfile
Разберёмся с терминологией: кто-то говорит что у БД может быть несколько controlfile-ов, а другие утверждают что файл один, который может иметь несколько копий. Мы придержимся последнего определения, так как согласно Oracle “multiplexing control files” означает именно возможность иметь копии.
Controlfile – файл небольшого объёма, но он жизненно важный. Внутри содержатся указатели для всей БД: место online redo log-а, файлов данных, критически важную системную информацию для обеспечения целостности ( значение sequence и timestamp). Размер файла обычно не превышает несколько мегабайт но БД не существует без этого файла.
У каждой БД есь один controlfile, но хороший DBA всегда будет создавать копии файла, чтобы в случае проблем с какой либо копией всегда можно было быстро восстановить систему. Если все копии утеряны, то теоретичеески можно попробовать восстановить базу, но лучше никогда не попадать в такую ситуацию. Oracle сервер сам синхронизирует controlfile-ы – задача DBA решить сколько копий необходимо и где их хранить.
Если вы в момент создания базы данных не указали количество или путь – это можно изменить после, но потребует включения выключения БД, так что лучше планировать заранее. Нету определенного значения сколько копий делать, минимум – один файл, максимум – восемь. Проблемы с любой копией controlfile приводят к немедленной остановке экземпляра БД.
Файлы логов / Online redo log files
Redo log – это набор хрогологически упорядоченных записей, об изменениях в БД. Это минимально необходимое количество информации, которая необходима чтобы восстановить все действия, которые совершались над БД. Если файлы данных пропали или удалены, эти записи изменений могут быть использованы чтобы повторить все действия с определенной точки времени до момента возникновения ошибки над резервной копией файлов данных. Этот лог может состоять из двух типов файлов: online redo log файлы (необходимые файлы для работы БД) и archive log файл-ы (которые не обязательны для работы, но необхоидмы для восстановления данных к точке времени).
У любой БД есть минимум два online redo log файла, но как и в случае с controlfile-ом, хороший DBA создаёт копии каждого файла. Online redo log состоит из групп файлов, каждый файл в которой называется member. У БД Oracle должно быть минимум две группы, состоящие минимум из одного member для работы. Вы можете создать больше чем две группы для улучшения производительности, и больше чем один member для сохранности данных. Две группы минимум нужны для того, чтобы в одну писать текущие изменения, а другую можно было в это время использовать для создания архивной копии.
Одна из групп в момент времени является текущей (current group) – в неё LGWR будет записывать изменения из буфера логов. В момент времени когда файлы группы заполнятся – LGWR совершит так называемую операцию log switch. Вторая группа становится текущей и LGWR начинает писать данные в файлы второй группы, и, если у вас настроен archive log mod, ARCn сделает резервные копии файлов первой группы. Когда вторая группа заполнится, LGWR опять сделает текущей первую группу а ARCn сделает резеврную копию второй группы. Таким образом группы redo log работают по кругу и каждая операция log switch создаёт файл архивного лога.
Так же как и для controlfile, если у вас настроено несколько файлов в группе (желательно иметь несколько копий!) не нужно никаких дополнительных настроек для их синхронизации и т.п. LGWR сам запишет во все копии в параллели одинаковую информацию. Если к примеру какая-либо копия на каком либо диске оказалась недоступна – до тех пор пока есть хотя бы одна копия – БД может нормально функционировать.
Размер и количество груп – задача оптимизации БД. В общем, необходимо выбирать значения в зависимтости от активности работы с БД. Минимальный размер – пятьдесят мегабайт, но активно используемые БД с большим количество пользователей могут использовать файлы размером до нескольких гигабайт. Количество копий файлов в группе – вопрос какой уровень отказоустойчивости вы хотите достигнуть. В любом случае – задание этих параметров не критично на этапе создание БД, так как они могут изменять в режиме «онлайн» — без перезагрузки экземпляра БД.
Файлы данных / Datafiles
Третий тип необходимых файлов для работы это файлы данных. Как минимум требуется два файла, которые создаются в момент созданий БД. До версии 10g – можно было создать базу с одним файло – после создаются два файла, по одному для табличного пространства SYSTEM и SYSAUX. Как бы то ни было, в рабочей базе будет больше файлов.
Файлы данных – это хранилище для данных. Их размер и количество неограниченны. Маленькие БД размером в несколько гигабайт могут состоять из пол-дюжины файлов, каждый размером в несколько сот магабайт. Большие БД могут состоять из тысяч файлов, размер которых ограничен только возможностями ОС и аппаратным обеспечением.
Файлы данных с физической точки зрения – это системные файлы, которые видят системные администраторы. Логическая же структура файлов данных, это хранилище сегментов (segments) в которых хранятся пользовательские данных и логическая структура доступна программистам, а также сегментов словаря данных. Сегмент – это структура хранения для данных; типичные сегменты это таблицы и индексы. Файлы данных могут быть переиенованы, перемещены, удалены, добавлены в любое время жизни БД. Но важно помнить что некоторые операции требуют перезапуска экземпляра БД.
С точки зрения ОС, файлы данных состоят из набора блоков операционной системы. Внутри файлов, они отформатированы на Oracle блоки (blocks). Эти блоки последовательно пронумерованы внутри каждого файла. Размер блока фиксирован и в большинстве случаев будет одинаковым для всей БД. Выбор размера блока задача для оптимизации. Допустимы значения от 2КБ до 64КБ. Нет взаимосвязи между размерами системных блоков и блоков Oracle.
Многие DBA используют одинаковый размер системного блока и Oracle блока. С точки зрения производительности системный блок не должен быть больше чем блок Oracle. Однако ничто не мешает системному блоку быть меньше чем блоку Oracle. К примеру системный блок в 1Кб и блок Oracle размеров в 8КБ вполне допустимая конфигурация.
Внутри блока находтся заголовок, область данных и возможно неиспользуемое место. Заголовок содержит информацию такую как: каталог строк, в котором перечислено расположение строк в области данных (если блок используется как часть таблицы), информация о блокировках строк, если данные используются в транзакциях. В области данных хранятся сами данные, такие как строки если блок является частью таблицы, или ключи индекса, если блок – часть индекса.
Когда пользовательскйо сессии необходимо работать с данными из блока, серверный процесс находит блок с нужными данными на диске и копирует этот блок в свободный буфер в database buffer cache. Если затем данные изменяются – в какой-то момент времени DBWn запишет этот блок обратно на диск.
Желательно регулярно делать копии файлов данных. В отличие от controlfile и redo log файлов, Oracle не поррерживает копии файлов данных (хотя вы можете построить RAID массив или использовать другие аппаратные возможности и возможности операционной системы). Если файлы данных повреждаются, они могут быть восстановлены из архивной копии и затем recovered (recovered — означает что к копии файлов данных будут применены изменения из redo log).
Логические структуры БД
Физические структуры БД есть ни что иное как системные файлы. Пользователи видят логические структуры, такие как таблица. Oracle использует термин segment для описания любой структуры, которая содержит данные. Типичный сегмент – это таблица, состоящая из строк данных, однако существует ещё более 12 возможных типов используемых в Oracle. Нас интересуют таблицы, индексы и UNDO сегменты. Таблица содержат собственно данные, индексы используются для быстрого доступа к конкретным данным, UNDO сегменты используются для хранения временной информации, изменений которые могут быть отменены.
Oracle позволяет абстрагировать физичесую структуру от логической путём ввода понятия табличное пространство (tablespace). Tablespace – логически это коллекция одного или несколько сегментов, а физически коллекция одного или нескольких файлов данных. В терминах реляционной алгебры – мы видим отношение многие-ко-многим между сегментами и файлами данных: одна таблица может находиться в разных файлах даных, и, с другой стороы, в одном файле данных может находиться много таблиц. Путём добавления понятия «табличное пространство» — Oracle управляет этими отношениями.
Несколько сегментов создаются во время создания БД: это сегменты которые составляют словарь данных. Эти сегменты хранятся в двух табличных пространствах SYSTEM и SYSAUX. SYSAUX появилось только после версии 10g: в прошлых весь словарь данных хранился в табличном пространстве SYSTEM. Процесс создания обязательно создаст минимум два табличных пространства с минимум одним файлом данных в каждом, для хранения словаря данных.
Сегмент состоит из блоков. Файлы данных также отформатированных с использованием блоков и блоки из файла данных назначаются к сегментам по мере роста последних. Управление дисковым пространством по одному блоку – было бы сильно затратным занятием, поэтому блоки группируются в extent-ы. Extent – это группа последовательных блоков в файле данных, и размер сегментов будет увеличиваться на размер extent-а. Extent-ы для одного сегмента не обязательно должны быть рядом в файле и вообще даже могут находиться в разных файлах, но файлы должны прнадлежать табличному пространству этого сегмента.
Рисунок 1-8 отображает отношения структур Oracle с отделением логических структур от физической. Табличное пространство может содержать множество сегментов, каждый из которых состоит из extent-ов. Extent – это набор блоков Oracle. Файл данных состоит из блоков операционной системы. Как итог табличное пространство состоит из множества файлов данных и блок Oracle состоит из одного или нескольких блоков операционной системы.
Словарь данных
Словарь данных хранит метаданные описывающие логическую и физическую структуру БД и её содержимое. Информация о пользователях, пароли, ограничения целостности и (начиная с 10g) информация о производительности – всё это хранится в словаре данных. Эти данные хранятся в виде набора сегментов в табличных пространствах SYSTEM и SYSAUX.
В целом, сегменты составляющие словарь данных такие же как и остальные сегменты – обычные таблицы и индексы. Главное отличие – эти сегменты создаются в момент создания БД и нет прямого доступа к информации в них. Конечно ничто не может остановить DBA от прямого доступа в словарь данных – однако их любое изменение может привести к разрушению БД.
Управление словарём данных осуществляется командами DML. Когда вы выполняете команду CREATE TABLE – на самом деле осуществляется вставка строк в таблицы словаря данных. Точно такое же механизм работы у команд CREATE USER и GRANT и т.д.
Для просмотра словаря данных Oracle предоставляет определённый набор представлений (view). Большинство из них начинаются с префикса DBA_, ALL_ или USER_. Все представления начинающиеся с USER_ будут отображать объекты БД принадлежащие текущему пользователю. Если пользователь JOHN будет простматривать представление USER_TABLES он увидит только те таблица, которые принадлежат ему. Таким образом никогда два пользователя не увидят одинаковой информации. Представления начинающиеся с ALL_ отображают информацию об объектах к которым у текущего пользователя есть доступ – то есть все объекты которые во создали плюс объекты к которым есть соответсвующее разрешение. Представления с префиксом DBA_ отображают информацию о всех объектах БД. Если вы просмотрите DBA_TABLES – то увидите строку для каждой таблицы, не важно кто создал её. Эти представления создаются в момент создания БД, а также генерируется большое количество PL/SQL пакетов. Эти пакеты предоставляются Oracle в помощь администраторам и разработчикам. PL/SQL код также хранится в словаре данных.
Свзяь табличных пространств и файл данных управляется controlfile-ом. Внутри перечислены все файлы данных и информация частю какого табличного пространства они являются. Без файла контроля БД не сможет найти файлы данных и определить какие из них хранят данные табличного пространства SYSTEM. Только после того как табличное пространство SYSTEM найдено и доступно для чтения информации – становится возможным чтение информации из словаря данных, что позволяет открыть БД.
SQL команды всегда ссылаются на объекты определённые в словаре данных. Чтобы выполнить простой запрос в таблицу, сервер Oracle вначале должен проверить в словаре данных существует ли такая таблица и какие столбцы в ней. Затем найти файлы где физически хранятся данные, т.е. прочитать список какие extent-ы хранят данные этого сегмента. В этом списке хранится информация в какой файле данных хранится каждый extent, с какого блока файла данных extent начинается и как много блоков входит.