Сегодня в блоге мы публикуем третью, заключительную часть статьи о новых возможностях СУБД Oracle. Мы уже рассказали, как новая мультиарендная архитектура позволяет упростить администрирование и повысить эффективность использования оборудования, а также как ускоряется выполнение аналитических и других типов запросов и повышается надежность базы данных с помощью In-Memory Database и шардинг. В финальной части статьи мы уделим внимание механизмам повышения производительности и автономности, в том числе автоматической индексации, AutoML, блокчейн-таблицам и др.
В каждой новой версии Oracle Database происходит оптимизация алгоритмов, ускоряются многие операции, повышается производительность выполнения SQL и PL/SQL кода. Мы предлагаем обзор наиболее ценных и важных механизмов.
Статистика реального времени. Скорость выполнения SQL-запроса зависит от плана его выполнения. Оптимизатор запросов (cost-based optimizer) строит планы, в том числе, на основе собранной статистики (количество записей, наличие индексов, кардинальность и т.д.). При устаревшей, неверной статистике план будет плохим, поэтому администраторы баз данных должны постоянно обновлять статистику. Сейчас, например, это можно делать автоматически, в окне обслуживания (например, ночью). Но операция сбора статистики влияет на производительность базы даных, а в период между двумя ее сборами статистика быстро устаревает.
Для решения этой проблемы был реализовал механизм сбора статистики в реальном времени – Real Time Statistic. Теперь часть наиболее важной статистики («базовая статистика») хранится в оперативной памяти, автоматически обновляется при выполнении каждого оператора языка манипулирования данными (Data Manipulation Language, DML) и периодически сбрасывается на диск. Каждый новый запрос использует свежую статистику (она формируется на основе статистики из памяти и из словаря базы данных) и выполняется с оптимальным планом запроса.
Статистика собирается на лету, поэтому, чтобы не тормозить DML, собирается только базовая. Полную статистику можно собирать реже, так как она теперь меньше влияет на качество выполнения запросов.
Дополнительным бонусом от статистики реального времени является то, что многие агрегационные функции (min, max, count), если в запросе нет предложения where, не читают данные с диска, а берут их из базовой статистики в памяти. Это резко ускоряет выполнение запроса.
Автоматическое создание индексов. Это наиболее интересный новый механизм. Индекс в базе данных служит для ускорения выполнения SQL запросов. Считается, что основную массу индексов строят разработчики приложения на этапе создания приложения, а администраторы должны лишь поддерживать эти индексы. Однако, на практике мы видим, что администраторы и разработчики, ответственные за обеспечение высокой производительности приложения, постоянно создают все новые индексы на этапе эксплуатации. В результате некоторые индексы дублируют друг друга, занимая место в базе данных. Но, главное, они замедляют операции вставки, удаления и изменения данных, которые требуют изменения индексов.
Создание оптимального набора индексов – это искусство, которым владеет не каждый администратор баз данных. Поэтому в Oracle разработали механизм автоматического создания индексов из 6 шагов.
- Захват (Capture). Во время работы приложения СУБД периодически (каждые 15 мин) захватывает выполняемые SQL-запросы и помещает их в специальный репозиторий (Automatic SQL Tuning Set, ASTS). Захватываются не только тексты SQL, но и планы выполнения, переменные привязки, статистика выполнения и т д.
- Идентификация кандидатов (Identify). Новые захваченные запросы анализируются с помощью алгоритмов искусственного интеллекта (ИИ) для определения индексов-кандидатов, которые могут улучшить выполнение этих запросов. Кандидаты создаются в базе данных как неиспользуемые индексы (Unusable) – по сути это лишь описания индексов в словаре базы данных (метаданные). Кроме кандидатов на добавление выявляются кандидаты на удаление, так как новые индексы-кандидаты могут перекрывать существующие индексы.
- Верификация (Verify). Оптимизатор запросов проверяет, что новые индексы действительно влияют на планы выполнения запросов. Оказывающие влияние кандидаты реально создаются в базе данных, но помечаются как невидимые (сессиям они пока не видны). Захваченные запросы (Select) выполняются в отдельной сессии с учетом новых индексов, и по ним собирается статистика.
- Принятие решения (Decide). Если производительность всех запросов, использующих новый индекс, улучшилась, то индекс помечается как видимый для всех сессий и далее используется как обычно при построении планов запросов. Если производительность всех запросов, использующих новый индекс, ухудшилась, то индекс удаляется. Если же производительность одной части запросов улучшилась, а другой - ухудшилась, то индекс становится видимым только для тех запросов, которые он улучшает. Остальные запросы его не видят и не используют.
- Онлайн проверка (Online validation). При дальнейшем использовании приложений меняется статистика и нагрузка, появляются новые запросы, поэтому процедура выявления и построения новых автоматических индексов периодически повторяется, чтобы учесть изменения.
- Мониторинг. СУБД постоянно отслеживает использование автоматических индексов и удаляет давно не используемые (политику хранения задает администратор). Кроме того, в базе данных могут сосуществовать автоматические и ручные индексы, а политика удаления для них может различаться.
Администратор может включить/выключить автоматическое создание индексов; указать схемы базы данных, для которых этот режим не работает; задать, в каком табличном пространстве следует создавать эти индексы; построить отчет о полезных рекомендуемых индексах без их создания.
Реализация описанного механизма требует дополнительных вычислительных ресурсов. Поэтому, если удалить все индексы и включить режим их автоматического построения, то вначале нагрузка на процессоры резко возрастет. На этапе первичной оптимизации это допустимо, но все равно ее лучше производить на мощной машине (например, на Exadata). Когда основной массив индексов построен, накладные расходы на мониторинг, построение новых индексов и др. уже не так велики.
Применение механизма автоматического построения индексов на реальных приложениях показало, что число получаемых индексов меньше, чем при ручной настройке, при этом производительность приложения сохраняется или возрастает. Автоматическое построение индексов можно запускать на копии промышленной базы данных и затем уже по построенному отчету вручную создавать рекомендованные индексы на промышленной базе данных.
Карантин для ресурсоемких запросов. Сложные запросы сильно нагружают систему и мешают работать другим пользователям. При изменении плана выполнения или объема данных запрос, который раньше работал быстро, может стать помехой для других. Поэтому в менеджере ресурсов СУБД реализована возможность отправлять в карантин запросы, когда они потребляют больше ресурсов, чем позволено. Такой запрос прерывается и при последующих запусках не выполняется. При изменении ситуации, например, когда планка ограничения ресурсов будет поднята, карантин будет снят и запрос сможет выполняться. В качестве пороговых значений для помещения запроса в карантин могут использоваться процессорное время, общее время выполнения, объем ввода/вывода, число физических или логических операций ввода/вывода.
Работа с энергонезависимой памятью
В традиционных СУБД данные хранятся на дисках и для обработки считываются в оперативную память компьютера. После выключения компьютера данные в оперативной памяти теряются. Оперативная память очень быстрая, но дорогая, поэтому поместить в нее всю базу могут немногие заказчики. В качестве паллиатива в ячейках Exadata между дисками и оперативной памятью устанавливается флеш-память, где автоматически кэшируются часто используемые данные. К сожалению, она хоть и быстрее дисков, но намного медленнее оперативной памяти.
Появление энергонезависимой памяти (Persistent Memory, PMEM) революционно меняет правила игры и, очевидно, приведет к изменению архитектуры СУБД. PMEM по стоимости дешевле оперативной памяти, но по скорости близка к ней. И она не теряет данные после выключения питания. Таким образом, в будущем можно будет всю базу данных поместить в PMEM и отказаться от дорогостоящих операций ввода/вывода, кэшей в памяти, подкачки блоков и т д.
Oracle Database, начиная с версии 20с, умеет работать с PMEM. Она использует ее двояко. Во-первых PMEM Intel Optain помещается в ячейки хранения машины баз данных Oracle Exadata (рис. 1) .
Рисунок 1. Уровни хранения данных в Exadata
Таким образом, теперь в Exadata реализовано четыре уровня хранения данных:
- диски (холодные данные);
- флеш-память (кэширование теплых данных);
- PMEM (кэширование горячих данных);
- оперативная память.
При этом обращение экземпляра СУБД к данным PMEM происходит не по стандартному протоколу ROCE (замена Infiniband), а по специальному протоколу RDMA напрямую. Это позволяет обойти сетевой стек и стек ввода/вывода и снизить задержки в десятки раз. Кроме того, Exadata записывает журналы транзакций (redolog) на PMEM. Все это значительно ускоряет операции ввода/вывода.
Но пользователи Oracle Database 20с могут и на обычном (не Exadata) оборудовании использовать преимущества PMEM. В энергонезависимой памяти можно размещать журналы транзакций (redo logs) и файлы данных. SQL-запросы выполняются напрямую над данными файловой системы PMEM по специальным алгоритмам. Поскольку данные из PMEM не считываются в буферы оперативной памяти, соответствующие накладные расходы исключаются. Это позволяет значительно ускорить выполнение важных запросов и повысить производительность всей СУБД.
Новые возможности Oracle Database 20c
Несмотря на то, что версия Oracle Database 20с является промежуточной, она обладает множеством новых возможностей. Выделим лишь самые интересные из них (рис. 2). (DB Nest, In-Memory Vector Join и Persistent memory рассматривались во второй части.)
Рисунок 2. Инновации в Oracle Database 20c
Блокчейн-таблицы. Это обычные таблицы базы данных, открытые только на чтение и добавление строк – изменить данные в этих таблицах нельзя. Удалить строки и всю таблицу можно только через заданный срок (или никогда), который определяет администратор. Строки таблицы связаны в цепочки (как в обычном блокчейне) – в каждой строке хранится хэш-значение предыдущей строки цепочки. Тем самым гарантируется, что строки цепочки не изменились, так как для изменения одной строки придется перестроить всю цепочку. Пользователи могут сохранить копии хэш-значений для проверки, что интересующие их значения не были изменены. Это простой и удобный способ организовать централизованный блокчейн в базе данных для приложений/пользователей, не доверяющих друг другу.
Native JSON в базе данных. Таблицы могут содержать колонки с документами JSON. Элементы данных в документах JSON можно обновлять. Теперь документы хранятся не в текстовом, а в бинарном представлении, что сильно ускоряет работу с ними. Кроме того, и опция In-memory, и ячейки Exadata умеют работать с колонками, содержащими документы JSON.
SQL-макросы в запросе. SQL-макросы позволяют упростить написание SQL-запроса. SQL-макрос – это функция, которая на выходе возвращает текст, который подставляется в текст исходного SQL-запроса. Например, это может быть динамически сформированный текст подзапроса или предикат условия для WHERE. Макросы делятся на табличные (подставляются в выражение FROM и формируют имя таблицы/таблиц или подзапрос для генерации таблицы) и скалярные (подставляются в WHERE/HAVING, GROUP/ORDER BY и формируют имя колонки/группы колонок или целого предиката для WHERE). SQL-макросы позволяют проще писать то, что раньше реализовывалось с помощью динамического SQL.
Автоматизация машинного обучения (AutoML в OML4Py). Опция Advanced Analytics теперь является бесплатной компонентой СУБД Oracle. В ее состав входят средства создания, обучения и использования моделей для машинного обучения (Machine Learning, ML). В СУБД имеется большая библиотека таких моделей (преимущественно на языке Python) и средства построения и настройки моделей (рис. 3). Однако выбор, построение и обучение таких моделей – сложная задача и требует высокой квалификации в области машинного обучения.
AutoML позволяет упростить создание моделей машинного обучения. Она помогает сделать следующее:
- выбрать правильную и наиболее подходящую модель для конкретной задачи (выдает рекомендации и список подходящих моделей);
- выбрать необходимые атрибуты (колонки таблицы) в качестве входных данных для модели (рекомендует, какие атрибуты и как сильно влияют на результат – чем меньше значимых атрибутов, тем быстрее и проще модель)
- выбрать параметры настройки для моделей (features).
Сегодня алгоритмы машинного обучения очень широко используются в приложениях. Механизмы AutoML в OML4Py (Oracle Machine Learning for Python) помогут неспециалистам в области машинного обучения создавать и использовать модели.
Рисунок 3. Алгоритмы машинного обучения СУБД Oracle
Заключение
Это только часть новых возможностей СУБД Oracle 12.2, 18c, 19c и 20c. Полный список можно найти в документации по конкретной версии СУБД. Некоторые из рассмотренных новых возможностей требуют больших дополнительных вычислительных ресурсов (например, автоматические индексы, онлайн статистика, memoptimized таблицы и т. д.), поэтому они реализованы на платформе Exadata. Список возможностей для конкретной платформы также можно найти в документации на СУБД Oracle.
Новые версии СУБД работают в корпоративном ЦОД (on-premise), в публичном облаке Oracle Cloud и также доступны на Exadata Cloud@Customer и в частном регионе публичного облака Oracle Dedicated Region Cloud@Customer, которые размещаются в клиентском дата-центре, но полностью обслуживаются Oracle. На базе этих СУБД (начиная с 18с) также реализованы автономные базы данных Oracle Autonomous Database. Они доступны как в публичном облаке Oracle, так и на Exadata Cloud@Customer в дата-центрах клиентов по модели «Oблако Oracle у клиента». Каждая автономная база данных – это PDB.
Новая инициатива Oracle – облачные сервисы Always Free – позволяет каждому желающему бесплатно заказать на неограниченный срок две автономные БД. На них удобно изучать новые возможности, вести разработку, тестировать свои приложения.
Автор – Марк Ривкин, руководитель группы баз данных технологического консалтинга Oracle в России и СНГ
