СУБД Oracle Database 12.2: быстро и еще быстрее

Oracle любит инновации, лелеет инновации, взращивает их и удобряет, поэтому инновации в этой компании цветут пышным цветом.
Соответственно, в новой СУБД Oracle Database 12.2 - полно новинок. О них в ходе технологического форума Oracle Database and Cloud рассказал Сергей Томин, ведущий консультант департамента технологического консалтинга компании Oracle СНГ.

Прежде всего, была улучшена производительность Oracle Database In-Memory, которая предоставляет возможность размещения данных в оперативной памяти в двух форматах: стандартном - строчном, и колоночном. Данные в колоночном формате размещаются в сжатом виде в отдельном кэше, In-Memory Column Store. В результате такой ценный ресурс, как память, экономится, данные сжимаются в среднем в 5-6 раз. Буферный и колоночный кэши активны одновременно, колоночный кэш автоматически синхронизируются с буферным кэшем. В ходе работы происходит динамический выбор - использовать буферный кэш или колоночный. Казалось бы, эка невидаль, новый кэш! Тем не менее, второй кэш заметно повышает производительность аналитических запросов, так как колоночная структура хранения данных идеально подходит для них. Но, если использовать только колоночное хранение данных, то производительность будет "проседать" на OLTP-нагрузке. Например, если нужно вписать в таблицу базы данных строку то, казалось бы, это одна операция. Но когда данные разбиты по столбцам, то вместо одной операции необходимо провести несколько операций равное числу столбцов таблицы. Поэтому Oracle и предлагает двойной формат хранения данных, позволяющий ускорить не только аналитические запросы но и DML-операции за счет отказа от дополнительных индексов.
В использовании кэша In-Memory есть и маленькие хитрости. Так, в настоящее время процессоры не могут поддерживать все типы данных Oracle. Чтобы использовать векторные операции процессоров, данные кодируются. При этом возникает проблема: например, есть две таблицы, и у них один общий столбец, по которому делается соединение. Но этот столбец может кодироваться различным образом у разных таблиц. В Oracle Database 12.1 необходимо восстанавливать исходные значения столбца, что требует дополнительных затрат CPU. А в Oracle Database 12.2 можно указать, что столбцы связаны, создать Join Group, в результате столбцы будут закодированы одинаково.
Появилось и еще одно нововведение: материализация выражений в оперативной памяти. В случае, если нужно миллион раз вычислить какое-то выражение для аналитического запроса, можно объявить выражение виртуальным столбцом и разместить его в In-Memory кэше, где значения выражения будут заранее просчитаны.
На повышение производительности работает и функция автоматической оптимизации данных, которая теперь распространилась и на Oracle Database In-Memory. Когда в последний раз пользовались конкретными данными? Если больше 120 дней назад - данные выгружаются из колоночного кэша.
Есть нововведения и в деле первоначальной загрузки данных в колоночный кэш. Как быстро загрузить с диска в оперативную память несколько терабайт данных? Сложно, долго и дорого? Вовсе нет. С функцией In-Memory Fast Start, которая позволяет хранить копию колоночного кэша на диске, первоначальная загрузка ускоряется примерно в пять раз.
В СУБД Oracle Database 12.2 появился и новый механизм сжатия индексов Advanced Index Compression HIGH, схожий с существующими алгоритмами Advanced Row Compression и Hybrid Columnar Compression для таблиц. Этот новый алгоритм позволяет сжать индексы в 4,6 раза. Да, производительность немного теряется, но существенно экономится дисковое пространство.
Веское слово было сказано и в области безопасности. Теперь применяется шифрование табличных пространств "на лету". Ранее, чтобы поменять ключ шифрования, нужно было ограничивать доступ пользователей, это делалось офлайн. Теперь все на ходу. Кроме того, у опции Database Vault появился режим эмуляции. В этом режиме не ограничивается доступ к данным, но регистрируются нарушения правил доступа к данным, заданных в Database Vault. Это позволяет настроить правила доступа к данным во время разработки и тестирования приложения и избежать проблем при вводе Database Vault в промышленную эксплуатацию.
Появились и новые функции для разработчиков. Например, одно маленькое, но приятное улучшение: длинные идентификаторы. Максимальная длина имени большинства типов объектов базы данных теперь не 30 байт, а 128. Можно присваивать более понятные имена.
Существенно доработана опция Oracle Multitenant, хорошо подходящая для SaaS-приложений. Oracle Multitenant позволяет значительно сэкономить на административных расходах повысить эффективность использования аппаратных ресурсов благодаря консолидации большого количества мелких баз данных в одну конейнерную. В Oracle Database 12.2 максимальное количество подключаемых баз данных в контейнерной базе данных увеличено с 252 до 4096.
Опция Multitenant в сочетании с технологией тонкого клонирования позволяет быстро создавать клоны продакшн-системы, что отлично подходит для разработки и тестирования. Если раньше надо было перед клонированием переводить подключаемую БД в режим read only, то теперь можно сделать клон подключаемой БД на лету без остановки работы пользователей. Можно также в режиме online перенести подключаемую БД в облако.
Есть в СУБД Oracle 12.2 и кое-что принципиально новое. Это Oracle Sharding - разбиение таблиц по разным базам данных. Эта технология повышает отказоустойчивость БД и предоставляет возможности для масштабирования. Инициатором нововведения стали крупные пользователи, в частности, сеть LinkedIn. В результате "шардинга" вместо одной физической БД появляется несколько с одинаковой логической схемой, называемые "шардами". Максимальное количество "шардов" - до 1 тысячи, причем у каждой таблицы должен быть единый ключ шардирования. Пользователя автоматически направляют туда, где хранится его информация, в зависимости от значения ключа шардирования, указываемого в строке соединения. Соединение таблиц в таких базах работает только в рамках отдельного шарда, но можно сделать агрегацию данных по нескольким шардам.
Есть новые функции и среди аналитики. Так, к появившейся в Oracle Database 12.1 функции приблизительного вычисления количества различных значений столбца добавилась функция приблизительного вычисления перцентиля. Дополнительно эти функции могут возвращать стандартную ошибку и доверительную вероятность. Обладая точностью порядка 97%, эти функции работают в разы быстрее и потребляют меньше CPU и памяти.

Еще один интересный доклад на мероприятии был посвящен вопросами аппаратного ускорения. Как пояснил Игорь Мельников, ведущий консультант департамента технологического консалтинга компании Oracle СНГ, когда выходит новый процессор, то выигрыш производительности составляет 10-15%, резко роста не наблюдается. Он отметил, что нельзя сказать, что индустрия топчется на месте, но развитие очевидно замедлилось. Что же делать? Выполнять часть задач на аппаратном уровне. Такая технология носит название "Software in Silicon".
Так, существуют специальные криптоакселераторы, встроенные в процессор SPARC M7. Полтора десятка алгоритмов шифрования доступны в качестве низкоуровневых команд процессора, необходимость тратить дорогостоящие вычислительные ресурсы пропадает. Те же криптоакселераторы применяются и для шифрования бэкапов. К слову, эту функциональность могут использовать любые другие Java-приложения, а не только СУБД Oracle.
Кроме защиты данных, есть и функции защиты памяти Silicon Secured Memory. На низком уровне реализуется защита от некорректных указателей, отсеиваются программные ошибки, определяется выход обращений за пределы массивов, а также операции чтения памяти, которая еще не была выделена, или уже была освобождена. Кроме криптозащиты и анализа использования памяти, в процессор SPARC M7 встроены функции SQL in Silicon.
Также для ускорения работы применяется технология DAX (Data Analytics Accelerator). Она добавляет средства обработки, позволяющие выполнять такие функции, как Scan, Extract, Select и Translate, на выделенном физическом сопроцессоре. DAX выполняет наиболее тяжелую и "грязную" работу, например, декомпрессию. Так, заказчики Oracle часто с некоторым напряжением относятся к компрессии, ибо она нагружает процессор. Но DAX делает автоматическую запаковку и распаковку, эта операция выполняется на аппаратном уровне. Предлагается и открытый API для разработчиков Oracle Open DAX API.