Обычно на каждой ежегодной всемирной конференции Oracle OpenWorld можно выделить некое главное событие или анонс. В году нынешнем таких событий, без сомнения, было два: анонс новой опции СУБД Oracle Database In-memory Option и не входящие формально в программу форума финальные гонки Кубка Америки, в которых сошлись экипажи яхт Oracle и Team New Zealand. Последние оказались для бессменного CEO Oracle Ларри Эллисона настолько важными, что он буквально в последнюю минуту отменил один из двух своих пленарных докладов и умчался на заключительную гонку, оставив в полном недоумении 60 тыс. собравшихся в Сан Франциско пользователей продуктов корпорации. Давайте оставим спортивным изданиям возможность пообсуждать, как удалось команде (или патронирующему ее Эллисону) победить в конечном итоге со счетом 9:8, проигрывая на начальной стадии 3:8, и вернемся к технологиям БД, целиком обрабатываемых в оперативной памяти.
Рассказывая о них в своем первом выступлении, Ларри Эллисон был необычайно оживлен и эмоционален. Речь шла о близких и хорошо понятных ему технологических вопросах, и излагал он их с явным удовольствием. И хотя совершенно очевидно, что новая опция — это недвусмысленный ответ на выпущенную пару лет назад in-memory-СУБД SAP HANA, имя главного конкурента Oracle из уст Эллисона ни разу не прозвучало. Тем не менее в самых общих чертах In-memory Option выглядит аналогично HANA: в обоих продуктах используется поколоночное хранение таблиц, оба поддерживают транзакционную и аналитическую обработку. Однако при детальном рассмотрении различия обнаруживаются, и весьма существенные.
О том, что СУБД с поколоночным хранением имеют целый ряд преимуществ в решении аналитических задач, но плохо приспособлены для OLTP-обработки, которую обычно возлагают на традиционные движки с хранением построчным, известно давно. Чтобы совместить преимущества обоих подходов, в Oracle решили поддерживать в БД оба формата хранения — построчный и поколоночный, обеспечивая синхронную согласованность обоих массивов данных. Это позволяет для генерации отчетов и аналитических операций использовать поколоночную версию БД, а для проведения транзакций, связанных с внесением изменений в таблицы, — построчную. Казалось бы, накладные расходы, связанные с синхронизацией двух форматов, должны снизить производительность транзакционной обработки, но, как заверил Ларри Эллисон, она, напротив, даже увеличилась в два-три раза по сравнению с “обычной in-memory-СУБД”. Произошло это благодаря тому, что в данном случае после транзакции не приходится перестраивать несколько десятков индексов, применяемых для аналитической обработки. Роль индексов в СУБД с поколоночным хранением исполняют сами колонки.
Не до конца понятно, правда, что понимается под “обычной in-memory-СУБД”, выбранной докладчиком в качестве базы для сравнения. По отношению к ней скорость аналитической обработки повышается, по его словам, в сто раз. Вряд ли такое превосходство наблюдается по отношению к SAP HANA: иначе докладчик не забыл бы об этом упомянуть. Более вероятно, что речь идет о представленной в прошлом году версии Oracle Database 12c, поддерживающей работу с данными, распределяемыми в зависимости от частоты использования по трем уровням хранения: динамического ОЗУ, PCI-флэша и жесткого диска. Кстати, как пояснил впоследствии вице-президент Oracle по технологиям серверов БД Энди Мендельсон, новая опция способна функционировать не только в оперативной памяти, но и в упомянутой трехуровневой иерархической архитектуре размещения данных. Она полностью совместима со всеми остальными опциями, включая multitenancy (мультиарендность), обеспечивающую эффективную работу в публичных и частных облаках. Очевидно, что, как и любые другие опции, эту придется покупать дополнительно к базовой версии СУБД. Относительно цены (как, впрочем, и сроков выпуска) пока ничего не известно, но, к примеру, стоимость упомянутой опции multitenancy составляет около 40% от цены лицензии на саму СУБД.
Вряд ли сегодня возможно сколько-нибудь объективное сопоставление нового решения Oracle с продуктом SAP HANA, но на некоторые моменты хотелось бы обратить внимание. Если в СУБД SAP не используется “двухформатный” подход, применяемый Oracle, то она окажется более экономичной по требуемым ресурсам хранения данных. Теоретически трехуровневая иерархия памяти Oracle должна быть менее производительной, чем обработка всей БД в быстрой ОЗУ HANA, но она экономичнее по стоимости. Оба вендора говорят о линейной масштабируемости своих решений, как горизонтальной (при наращивании числа серверов в кластере), так и вертикальной (при увеличении числа процессоров в одном SMP-сервере). Тут тоже важны детали. В SAP HANA при наращивании числа серверов требуется дополнительна работа по рациональному распределению таблиц (partitioning) с тем, чтобы снизить накладные расходы при обращении процессора к ОЗУ другого узла кластера. В опции Oracle, судя по всему, такого ограничения нет. Во всяком случае при развертывании на ее собственных программно-аппаратных комплексах Exadata, обладающих высокопроизводительной системой межсоединений на базе InfifBand.
Ларри Эллисон представил еще один мощный сервер для решения подобных задач — M6-32 Big Memory Machine, реализованный на новейших 12-ядерных процессорах SPARC M6 (в сумме 384 ядра) и содержащий 32 Тб оперативной памяти. Будучи интегрирован с дисковой подсистемой Exadata Storage Servers, способной самостоятельно выполнять предварительную обработку SQL-запросов, он превращается в Oracle Supercluster M6-32 — машину баз данных, аналогичную Exadata, но уже на платформе SPARC.
Пожалуй, главное преимущество Oracle Database In-memory Option перед SAP HANA состоит в том, что, как утверждает г-н Эллисон, клиентам, уже использующим решения на базе СУБД Oracle, не придется ничего менять: не нужно осуществлять перенос данных или вносить изменения в код приложений. “Вы нажимаете кнопку “включить опцию”, и все сразу работает”, — с неподдельным энтузиазмом провозгласил глава корпорации. Довольно двусмысленно в этом контексте прозвучал анонс собственных усовершенствованных бизнес-приложений In-Memory Applications (JD Edwards EnterpriseOne, PeopleSoft, E-Business Suite, Value Chain Planning, Transportation Management), обладающих более высокой производительностью при выполнении аналитических задач, организации хранилищ данных, подготовке отчетов и обработке транзакций. Вроде бы они и без всякой подготовки должны работать на In-memory Option? Остается предполагать, что в редакциях бизнес-приложений In-memory появятся некие новые функции, в полной мере использующие возможности скоростной обработки в памяти.
Еще одна важная тема, затронутая Ларри Эллисоном, связана с местом уникальных программно-аппаратных комплексов Oracle в современных дата-центрах, базирующихся преимущественно на Intel-серверах стандартной архитектуры. Глава Oracle полагает, что работа в дата-центрах найдется и для тех, и для других, причем для решения специализированных задач предпочтительнее использовать специализированные платформы, такие как машина БД Exadata или аналитический сервер Exalytics. В частности, на роль подобной платформы для резервного копирования БД претендует анонсированный на конференции комплекс Oracle Database Backup Logging Recovery Appliance. “Как вы думаете, кто придумал такое красивое название, — с долей самоиронии спросил у аудитории Ларри Эллисон? — Вы угадали, это я, Big Boss”. Предназначен этот программно-аппаратный комплекс для резервирования тысяч БД (не только Oracle), причем копироваться будет каждое событие в журнале транзакций по мере его возникновения. В результате резервная копия всегда будет актуальна с точностью до одной транзакции, а на процедуры бэкапа не придется выделять специальные временные окна. Обещана поддержка петабайтных объемов данных и гарантированное восстановление БД на любой момент времени в прошлом.
