Автономность и искусственный интеллект, мультимодельность и конвергентность, база данных как сервис, работа с энергонезависимой памятью, эти и другие возможности, уже реализованные в СУБД Oracle, задают направления совершенствования современных СУБД. Сегодня в блоге мы публикуем первую часть статьи о тенденциях развития и возможностях баз данных, где объясняются основные особенности новой мультиарендной архитектуры и преимущества для системных администраторов баз данных, разработчиков и тестировщиков.
Коммерческие реляционные СУБД быстро развиваются и широко востребованы на рынке. Oracle непрерывно совершенствует свой флагманский продукт СУБД Oracle Database. Новые возможности версий Oracle Database 19с и 20c иллюстрируют перспективные направления развития современных средств работы с базами данных.:
- Создание мощных коммерческих СУБД, одинаково эффективно работающих в разных средах (ЦОД заказчика, частное, публичное или гибридное облако, машина баз данных Exadata, Cloud at Customer – фрагмент публичного облака, развернутый в ЦОД заказчика). Иначе говоря, современная база данных может работать и как СУБД, и как сервис.
- Самоуправляемость, автономность и одновременное управление множеством БД с использованием алгоритмов искусственного интеллекта
- Мультимодельность и конвергентность – поддержка в одной СУБД множества типов данных (реляционные, геоинформация, текст, JSON, NO SQL, XML, Hadoop, Spark, мультимедиа и пр.) и множества разных нагрузок (OLTP, системы поддержки принятия решений, интернет вещей, хранилища, блокчейн, «ключ-значение» и т. д.).
- In-memory вычисления и использование векторных команд процессоров.
- Работа с энергонезависимой памятью.
- Разделение базы данных между несколькими серверами (шардинг).
- Встраивание новых технологий в СУБД (блокчейн, машинное обучение, интернет вещей, JSON и т д).
Кроме того, естественно, продолжается работа над повышением надежности, производительности, безопасности, масштабируемости и управляемости СУБД.
С 2013 года, когда вышла версия 12.1, в СУБД Oracle было добавлено множество новых возможностей, появились автономные БД и механизмы самоуправления. Новые версии выходят постоянно, однако, недавно порядок их выхода изменился. Раньше новая версия появлялась каждые 3-4 года и в течение этого времени выходили два релиза версии. Теперь, начиная с версии 18с, новая версия СУБД будет выпускаться каждый год и ее номер будет совпадать с номером года. Таким образом, теперь есть версии 18с, 19с, в 2020 году выходит версия 20с.
Все новые версии теперь делятся на промежуточные и долговременные. Промежуточные позволяют попробовать новые возможности и хороши для разработчиков и тех, для кого новые функции важны. Долговременные версии более стабильны, имеют долгий срок технической поддержки (4 года + 2 года расширенной поддержки) и предпочтительны для промышленной эксплуатации. Первый долговременный релиз – Oracle Database 19c, на него и рекомендуется переводить промышленные системы. Поэтому нет смысла отдельно говорить об отличиях СУБД Oracle 12.2, 18c, 19c. Мы рассмотрим новые возможности в Oracle Database 19c по сравнению с Oracle Database 12.1 и коротко расскажем об основных новшествах Oracle Database 20c. Наиболее важными являются следующие:
- мультиарендная архитектура (опция Multitenant);
- механизмы векторной обработки данных в оперативной памяти (опция In-Memory)
- шардинг (параллельное хранение и обработка частей таблиц/групп таблиц на различных компьютерах);
- автономные базы данных;
- работа с энергонезависимой памятью.
Рассмотрим эти новые возможности подробнее и начнем с изменений в архитектуре СУБД и работе с большими базами данных.
Мультиарендная архитектура СУБД
Новая архитектура СУБД Oracle позволяет упростить сопровождение множества баз данных Oracle и повысить эффективность использования оборудования. В традиционной архитектуре для каждой новой БД создается свой набор файлов этой БД на дисках, а для работы с ней запускается отдельный экземпляр Oracle (Instance), который занимает часть оперативной памяти компьютера и запускает набор фоновых процессов. Если на одном компьютере необходимо развернуть 10 баз данных, то создается 10 наборов файлов на дисках, запускается 10 наборов фоновых процессов и в оперативной памяти выделяется 10 областей.
В случае мультиарендной (multitenant) архитектуры создается одна контейнерная база данных (Container Database, CDB), которую обслуживает один экземпляр Oracle. А все вновь создаваемые БД (они называются подключаемыми – Pluggable Database, PDB) помещаются в эту контейнерную БД. При этом для обслуживания множества независимых БД используются один набор процессов и одна область оперативной памяти.
Мультиарендная архитектура
Cтарый словарь БД разделяется на 2 части. Общая для всех PDB часть словаря хранится в CDB, а в каждой PDB хранится информация словаря, специфичная для данной PDB. Мультиарендная БД имеет один набор журнальных файлов (redo logs) и один набор управляющих файлов, общих для всех PDB в контейнерной БД.
Такой подход позволяет на одном компьютере разместить гораздо больше БД и избежать проблем дублирования и несовместимости объектов, которую мы имеем при консолидации схем БД. Как показывает тестирование, на одном и том же компьютере помещается в 50 раз больше БД новой архитектуры за счет более эффективного использования памяти, процессоров и дисков. Подключаемые БД (PDB) не зря так называют и изображают в виде флешки. Их можно легко отключить от одной CDB и подключить к другой. Например, при переносе PDB из CDB версии 12с в CDB версии 20с, PDB автоматически обновляется до версии 20с.
Новая архитектура значительно упрощает администрирование множества баз данных. Если раньше DBA приходилось администрировать, скажем, 10 баз данных и экземпляров, то, превратив эти БД в PDB, потребуется администрировать только один экземпляр СУБД Oracle. Больше не надо делать бэкап для каждой БД – достаточно сделать один для CDB, откуда можно будет восстановить нужную PDB. Теперь можно создать одну резервную базу данных для CDB и все текущие и вновь создаваемые PDB будут иметь резервную БД. Кроме того, для CDB можно сконфигурировать кластер (RAC), это автоматически повысит надежность всех подключенных PDB. Чтобы обеспечить изолированность и масштабируемость, отдельные PDB можно закрепить за конкретными узлами RAC. В CDB очень просто делать клоны PDB, существующих в этой или другой CDBкоторые будут обновляться по мере обновления исходных PDB.
И, конечно, упрощается апгрейд и патчирование баз данных. Вместо 10 обновлений для 10 БД достаточно обновить CDB и все PDB автоматически обновятся до новой версии. Если же апгрейд или патчирование нужны не для всех PDB, а лишь для части, то их просто надо перенести в CDB новой версии. Перенос PDB из одной CDB в другую осуществляется одной командой (или кликом мышки в Enterprise Manager), по которой метаинформация о PDB выгружается в xml-файл, а затем загружается в другую CDB. Если CDB размещаются на одном компьютере, то даже копировать файлы БД PDB не придется.
В новой CDB можно сделать клон PDB из другой CDB. При клонировании в режиме горячего обновления (hot refreshable) исходная PDB остается открытой для изменений во время клонирования. После окончания клонирования изменения применяются к клону. Далее синхронизация клона и исходной PDB периодически повторяется в автоматическом или ручном режиме. Таким образом, всегда имеется открытая на чтение свежая копия мастер-клона в новой CDB, где можно создавать новые клоны PDB, доступные для изменений. Это очень удобно для разработчиков приложений.
Исходная PDB и синхронизируемый с ней клон в другой CDB – это своего рода вариант резервной БД. Как и в случае резервной БД, PDB-клон можем переключить в режим основной, открытой для изменений PDB. Тогда исходная PDB превратится в доступный для чтения обновляемый мастер-клон, т.е. происходит переключение (PDB switchover) – смена ролей.
Разработчикам и тестировщикам приложений часто требуется восстановить базу данных на определенный момент времени в прошлом. Для отдельной PDB это можно сделать с помощью механизма flashback, но можно применить новый механизм – карусель снэпшотов (snapshot carousel). При активированном режиме карусели ежедневно будет автоматически сохраняться копия PDB в архивном файле (такая копия называется снимком, или снэпшотом). По умолчанию хранятся последние 8 снимков. Если, например, в среду необходимо восстановить PDB по состоянию на 5 ч вечера понедельника, то мы просто восстанавливаем PDB из снэпшота за понедельник и далее накатываем архивные журналы, чтобы применить изменения, сделанные до 5 ч вечера.
Еще один интересный механизм мультиарендной базы данных – Application Container (AC). Если несколько PDB имеют одинаковые объекты (таблицы, процедуры, функции и т д), то их можно поместить в отдельную PDB, называемую application container. Все PDB, наследующие объекты этого контейнера, будут видеть эти объекты. Это устраняет дублирование и облегчает сопровождение объектов (они изменяются в одном месте – application container). Причем, если таким разделяемым объектом является таблица, то есть 3 варианта:
- Хранить таблицу со всеми данными в AC (тогда PDB будут видеть ее как таблицу, открытую на чтение)
- Хранить таблицу и часть ее данных в АС (тогда каждая PDB будет видеть эти данные в режиме чтения, но может иметь свою открытую на изменение часть этой таблицы)
- Хранить только описание структуры таблицы в АС (тогда каждая PDB будет иметь свой, скрытый от других, открытый для изменений вариант этой таблицы)
PDB базы изолированы друг от друга. Управлять разделением ресурсов компьютера (память, процессоры, ввод/вывод, параллелизм) между PDB можно с помощью менеджера ресурсов. Механизм блокирования профиля (lockdown profiles) позволяет ограничить выполнение отдельных команд SQL и их частей для конкретной PDB, запретить выполнение некоторых потенциально опасных команд (например: alter system) и команд операционной системы и даже блокировать прямой доступ к PDB.
Серверные процессы ОС имеют доступ к файлам БД и могут читать или модифицировать файлы других PDB. Чтобы избежать этого, в версии 20с вводится механизм DB Nest. Все процессы ОС экземпляра Oracle можно разделить на две группы: фоновые и серверные (они обслуживают сессии и SQL отдельных пользователей). DB Nest позволяет запретить серверным процессам конкретной PDB доступ к файлам БД, файлам трассировки, файлам настройки других PDB. Им также можно запретить доступ к областям памяти (pga) других PDB и выполнение команд ОС. Механизм схож с контейнеризацией в ОС: каждая PDB работает как бы в отдельном контейнере и изолирована от других.
С PDB можно работать как с обычной базой данных, соответственно, у нее есть и традиционные средства настройки. Она имеет свой автоматический репозиторий для хранения статистики о работе базы данных (Automatic Workload Repository, AWR), периодически запускается анализ статистики для выявления проблем (Automatic Database Diagnostic Monitor, ADDM). Отчеты AWR можно строить на уровне PDB и получать рекомендации по настройке базы данных. Тестирование под нагрузкой (Real Application Testing, RAT) можно запускать на отдельной PDB, чтобы захватить, а потом и воспроизвести нагрузку и оценить влияние изменений на эту PDB.
Мультиарендная архитектура доказала свои преимущества, на ней построены все автономные базы данных Oracle и с версии 20с Oracle будет поддерживать только эту новую архитектуру. Те, кто хочет по-прежнему иметь один экземпляр Oracle для каждой БД, могут создавать CDB с одной PDB. Бесплатно можно создавать до 3 PDB в одной CDB, если требуется больше – следует лицензировать опцию Multitenant.
Хранилища данных и большие БД
В Oracle Database 19c можно создавать гибридные секционированные таблицы. Часть секций такой таблицы – это обычные секции в БД, а часть – внешние (external), размещенные в файлах ОС или на системе облачного хранения. SQL-операторы видят этот набор секций как единую внутреннюю таблицу БД. Поддерживаются все виды внешних секций, которые можно загружать с помощью SQL Loader и Data Pump, можно использовать в качестве секций файлы Hadoop (формат HDFS и Hive). Внешние секции доступны только для чтения. Гибридное секционирование позволяет, например, легко и быстро перемещать архивные данные из базы данных в Hadoop и сохранять доступ к ним, не переписывая приложения. Это позволяет заметно снизить стоимость хранения.
Многие приложения используют временные таблицы, но до версии 18с можно было создавать только глобальные временные таблицы. Они были видны для всех сессий и существовали в БД постоянно, но каждая сессия помещала туда свои данные для работы с ними. Затем данные автоматически удалялись по завершении транзакции (commit), либо при завершении сессии. Теперь для сессии можно создавать частные временные таблицы (private temporary table). Они размещаются в оперативной памяти, другие сессии их не видят и не имеют к ним доступа. Такая таблица автоматически удаляется либо по окончании транзакции, либо по окончании сессии. Частные временные таблицы можно создавать и на резервной БД.
Oracle стремится минимизировать время простоя и задержки при любых операциях с объектами БД. Теперь практически все операции с секциями таблиц и их индексами (создание, перемещение, удаление, изменение, расщепление, преобразование типа секционирования и т.д.) можно выполнять онлайн, без остановки работы с таблицами.
В следующей части мы подробнее расскажем о том, как опция In-Memory Database позволяет ускорить выполнение аналитических запросов, что такое шардинг и как он помогает повысить надежность СУБД.
Автор – Марк Ривкин, руководитель группы баз данных технологического консалтинга Oracle в России и СНГ
