В 2005 году спокойную до того атмосферу мира СУБД нарушил сенсационный доклад Майкла Стоунбрейкера, дезавуирующий негласное соглашение о разделении реляционных технологий на базы со строчной организацией, используемые для оперативной работы с данными, и на базы, в которых данные организованы по колонкам (Vertica, Calpont, Infobright, Kickfire, Paraccel и др.), предназначенные для аналитики. Еретики, возглавляемые Стоунбрейкером, заявили – СУБД из последней группы могут быть с успехом использованы в обоих типах приложений.

Некоторое время дискуссия носила академический характер, но летом 2009-го масло в огонь подлил Хассо Платтнер своим докладом «Общий подход к поколоночным базам данных, резидентным в оперативной памяти, с позиций OLTP и OLAP» (A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database) на конференции SIGMOD 2009. Платтнер представил результаты исследований резидентных в памяти СУБД, которые могут быть с равным успехом использованы как для оперативной обработки транзакций (Online Transaction Processing, OLTP), так и для оперативной аналитической обработки (Online Analytical Processing, OLAP).

Компания Oracle совместно с Sun Microsystems сделала серьезный практический шаг в том же направлении, выпустив специализированную машину Exadata 2, адаптированную для работы с гибридными СУБД. Аппаратное обеспечение поставила Sun, а Oracle – гибридную СУБД Oracle Database 11g Release 2, способную работать и со строками, и с колонками. Буквально через неделю в качестве своего ответа на Exadata 2 компания Teradata анонсировала альтернативные по форме, но близкие по смыслу решения. Одно из них – аналитическое облако Enterprise Analytics Cloud, второе – специализированная машина для работы с хранилищами данных Extreme Performance Appliance.

Появление Exadata 2 и Extreme Performance Appliance оказалось возможным не только благодаря новым тенденциям в технологии СУБД, но и во многом из-за новейших решений в области твердотельной памяти. Если представить иерархию всех видов памяти в виде пирамиды, то венчают ее самые быстрые и самые дорогие процессорные регистры, затем идет кэш-память процессора, которая сама делится на несколько уровней, далее – основная оперативная память и примыкающая к ней кэш-память на тракте между собственно памятью и дисками. До недавнего времени ниже по иерархии шли несколько уровней памяти на магнитных носителях, от быстрых дисков до медленных лент, но с развитием технологии SSD появился еще один уровень между дисковой кэш-памятью и собственно дисками. Этот уровень сочетает достоинства двух соседних – у него прямая адресация, как у кэш-памяти, а емкость сравнима с дисками, причем со скоростью доступа на порядки выше. Кроме очевидных последствий (массовость флэш-памяти, установка SSD в нетбуках) появление этого уровня имеет и менее очевидные – этот уровень изменил отношение не только к физической стороне хранения корпоративных данных, но и к принципам их использования.

Деление на оперативные данные (OLTP) и данные в хранилищах, используемые в аналитике (OLAP), исчезнет, тем более что потребность в оперативной аналитике постоянно растет. Сразу возникает ассоциация с одной из истин дзен – «когда ученик готов, приходит учитель»: прорыв происходит, когда одновременно созрело несколько родственных явлений.

Платтнер – один из пятерых выходцев из IBM, основавших SAP AG, который на протяжении 20 лет возглавлял совет директоров этой крупнейшей софтверной компании. Сейчас он отошел от активной административной деятельности и занят поддержкой нескольких исследовательских центров, в том числе Института Хассо Платтнера инженерии ИТ-систем c филиалами в Потсдаме и Пало-Альто. Доклад был сделан с позиции человека, посвятившего значительную часть своей производственной деятельности реляционным базам данных, но при этом, несмотря на возраст и общественное положение, не обремененного псевдоакадемизмом, присущим некоторым его коллегам по СУБД. Свобода от подобного рода комплексов позволяет Платтнеру достаточно критично переосмыслить все сделанное в области реляционных СУБД. Он отдает отчет в том, что те или иные решения не являются догмами и были приняты в условиях технологических ограничений своего времени, и если технологические условия меняются в более благоприятную сторону, то их следует смело пересматривать. Именно поэтому, сейчас, когда усилиями Oracle, Sun Microsystems, Teradata, Greenplum и некоторых других компаний условия меняются, рассуждения Платтнера особенно интересны.

Как признает Платтнер, несмотря на то что за минувшие два десятилетия реляционные базы стали фундаментальной основой большинства бизнес-приложений, итог этих лет не столь триумфален, как задумывалось, и не все из обещанного оправдалось. По мере ужесточения требований со стороны бизнеса приходилось вынужденно уходить в направление, которое потом назвали OLTP, а для поддержки аналитики выделилось отдельное направление OLAP. Хотя в основе и OLTP, и OLAP лежит одна и та же реляционная теория, но в OLTP кортежи данных организованы по строкам, хранимым в блоках на дисках или в кэше. В таком случае сложное индексирование работает быстро, не выходя на пределы блоков, а в OLAP, напротив, система хранения по колонкам оказалась удобнее для аналитики. Существование OLTP обеспечивает создание данных, но только средствами OLAP компания может серьезно проанализировать свой бизнес и подготовиться к принятию ответственных решений.

На параллельное существование двух подходов никто не обращал особого внимания, пока не наметились новые тенденции в процессорных технологиях – рост тактовой частоты, казавшийся бесконечным, остановился на уровне 3 ГГц, но зато стали резко расти размеры памяти, а многоядерность и многопотоковость вылились в основные направления развития процессоров. Рост размеров памяти идет на благо обоих подходов, а вот с массовым параллелизмом OLTP-системам справляться сложнее – увеличению производительности мешает обязательное наличие механизма временных блокировок на обновление содержимого памяти. Исследования, показавшие бесперспективность параллелизма строчных баз данных для OLTP, проводились в SAP и Институте Хассо Платтнера, там же были проведены исследования на предмет использования баз с колоночным представлением для OLTP. Результаты этих исследований, продолжавшихся около трех лет, дают Платтнеру основание утверждать, что переход на базы с поколоночной организацией в сочетании с современными серверами приблизит скорость работы с большими массивами данных к производительности работы в режиме реального времени, что позволит полностью изменить отношение к данным. Он сравнивает по своей революционности переход на новые технологии с появлением поисковых машин в Сети.

Exadata 2

Машина Exadata (а это именно машина, не компьютер и не система хранения) представляет собой сложный комплекс, состоящий как минимум из двух серверов и системы коммуникаций. Принципиальной новизной отличается введение еще одного уровня серверов, получившего название Storage Server и располагаемого между собственно системой хранения и, условно говоря, дисками, с одной стороны, и обычными серверами, на которых работают базы данных, – с другой. Выше в иерархии могут находиться серверы приложений, Web-серверы и др.; таким образом, можно говорить о многосерверной системе.

Сервер системы хранения избавляет от нескольких проблем, которыми страдают обычные двухуровневые конфигурации, состоящие из серверов баз данных и систем хранения. Во-первых, удается покончить с ограничениями пропускной способности интерфейса между сервером баз данных и системой хранения данных. Существует множество узких мест в системе ввода/вывода, снижающих общую производительность: серверам требуется множество адаптеров Host Bus Adapter, чтобы обеспечить достаточную пропускную способность на тракте от системы хранения до базы данных. Если сервер не может поддерживать необходимое число HBA, то приходится приобретать дополнительные коммутаторы сетей хранения, что повышает стоимость. Кроме того, крупные массивы часто не могут предоставить достаточную пропускную способность для обслуживания сотен расположенных в них дисков. Эффективность работы дисков ограничивается петлями Fibre Channel Loop и процессорными возможностями массива хранения данных.

Вторая проблема – «тупость» традиционных устройств хранения, которые ничего не знают о размещенных в них базах данных. Поэтому они не способны обрабатывать информацию и SQL-операции прозрачно для базы данных, и, когда она запрашивает столбцы или строки, ей в ответ приходят блоки данных, а не результат самого запроса. Традиционные средства хранения не имеют сведений о базе данных, которые помогли бы определить конкретные столбцы и строки, содержавшиеся в запросе. Проблемы решаются за счет введения трех типов ячеек: серверов хранения, мощной системы коммуникации между ними и серверов базы данных.

С физической точки зрения Exadata 2 – это решение, поддержанное инфраструктурой, состоящей из отдельных ячеек, которые взаимодействуют между собой через один или несколько коммутаторов Infiniband. Серверы хранения предоставляют данные, но сами «ничего не знают» о сетке серверов баз данных, на которые они работают. Как следствие, архитектура Oracle Exadata масштабируема, что позволяет достигать любого уровня производительности путем простого добавления ячейки, при этом все показатели возрастают линейно.

В качестве сервера хранения (первой ячейки) сейчас используется Exadata Storage Server (Sun Fire X4275), на котором работает программное обеспечение Exadata Storage Server Software, разработанное в Oracle и в максимальной степени соответствующее поддержке СУБД Oracle. Сервер включает два четырехъядерных процессора Intel Xeon E5540, 384 Гбайт флэш-памяти Exadata Smart Flash Cache, 12 дисков (SAS 7 Тбайт или SATA 24 Тбайт) и 24 Гбайт оперативной памяти. Конкретная конфигурация может меняться, но самое главное, как подчеркнул Ларри Эллисон, представляя Exadata: «Flash Exadata – это не флэш-диски... Флэш образует еще один уровень иерархии памяти по сравнению с DRAM, мы можем работать с ней так же эффективно, как с памятью, а не как с ускорителями-кэшами».

Данная технология обеспечивает для операций чтения 10-кратное улучшение по времени отклика по сравнению с обычными дисками; 100-кратное улучшение для операций ввода/вывода по сравнению с обычными дисками; менее дорогую и высокоемкую альтернативу обычной памяти. В целом достигается 10-кратное ускорение производительности по сравнению с обычными массивами для операций чтения и записи. Кроме того, Exadata Smart Flash Cache управляет активными данными на внутренних дисках в ячейке, но управление представляет собой не просто список наименее «свежих» объектов: программное обеспечение Exadata совместно с Oracle Database анализирует запрашиваемые данные и знает, когда и какие данные следует кэшировать, чтобы избежать «замусоривания» памяти. Данная функциональность работает автоматически, но если существует таблица или индекс, быстрый доступ к которым являются ключевым для обеспечения производительности приложения, то они могут быть помещены в кэш вручную.

Sun Oracle Exadata Storage Server работает под управлением операционной системы Oracle Enterprise Linux 5.3, назначение которой сводится к поддержке специфических функций управления ячейкой Exadata cell CELLSRV (Cell Services). CELLSRV является многопотоковым ПО, общающимся с СУБД по протоколу iDB. Еще две функции – Management Server и Restart Server – поддерживают интерфейс с администратором. Целью этой конструкции является перенос большей части SQL-запросов из основного сервера в специализированный и обеспечение интеллектуального сканирования и предикативной фильтрации.

Вторая ячейка, выполняющая роль сервера базы данных, – обычный сервер Sun Oracle Database Server формата 1U (Sun Fire X4170) на двух процессорах Xeon Nehalem).

Третья ячейка – коммутатор InfiniBand с производительностью 40 Гбит/с, что во много раз превышает пропускную способность традиционных устройств хранения или серверных сетей. Каждая ячейка Exadata имеет двойной порт Quad Data Rate (QDR) InfiniBand для обеспечения высокой доступности. Более того, Oracle InterConnect использует технологию непосредственного ввода данных в память DMA (Direct Memory Access) для снижения нагрузки на центральный процессор путем перемещения данных с кабеля в буфер базы данных без промежуточного копирования данных. Сеть InfiniBand обладает гибкостью, свойственной обычной локальной сети, и так же эффективна, как и сеть хранения. Интерфейс InfiniBand не позволяет сети стать узким местом и снизить производительность. Кроме того, InfiniBand предоставляет высокоскоростное межсоединение для узлов кластера для Oracle Real Application Cluster.

Базовым конструктивным элементом Exadata 2 является мощная стойка, состоящая из 176 ядер x86-архитектуры, способная поддерживать 352 потока, 912 Гбайт памяти DDR3, область хранения на флэш-памяти с одноуровневыми ячейками емкостью 5,4 Тбайт, 336 Тбайт дисковой памяти, и все это соединено через InfiniBand. Можно собирать многостоечные варианты либо делить стойку пополам, на четыре части – и далее вплоть до минимального варианта, состоящего из двух серверов и одного коммутатора.

Что касается версии Oracle Database 11g Release 2, то по ней пока информации существенно меньше, но очевидно, что она воплотила в себе функционал, приобретенный вместе с компанией TimesTen, продукт которой DataServer обрабатывал данные в памяти, что повышало производительность в десятки раз. Аналогичная опция In-Memory Database Cache (IMDB Cache) в Oracle Database 11g Release 2 позволяет приложениям самим работать с данными, расположенными в кэше, что исключает любые задержки и повышает производительность на порядок и выше. Кроме того, Oracle Database 11g Release 2 способна к определению оптимального уровня параллелизма при обработке запросов – она автоматически распределяет большие упакованные или небольшие исходные таблицы по памяти, доступной в сетке, а процедура Stripe And Mirror Everything позволяет распределить блоки по дискам и обеспечить зеркалирование. Средствами Oracle Database 11g Release 2 любые аппаратные компоненты Oracle Grid могут быть динамически добавлены или сняты с эксплуатации.

Утверждается, что при сочетании Exadata 2 и Oracle Database 11g Release 2 удается в пять раз сократить стоимость оборудования в целом, а систем хранения – в десять раз, на порядок увеличить производительность и при этом заметно повысить безопасность и доступность.

Ответ Teradata

Первое предложение – оперативное аналитическое облако Teradata Agile Analytics Cloud – ориентировано на аналитиков и состоит из двух продуктов: Teradata Express on Amazon EC2 и Teradata Express for VMware Player. Оба распространяются свободно. При использовании EC2 максимальный объем данных составляет 1 Тбайт, а на рабочем месте должно быть установлено программное обеспечение Teradata, работающее под Novell Suse Linux Enterprise Server 10. Продукт Teradata Express for VMware Player использует VMware Player – инструмент, позволяющий пользователям запускать виртуальную машину на компьютерах, работающих под управлением ОС Windows. Teradata Agile Analytics Cloud рассматривается как средство для быстрого создания аналитических витрин данных с перспективой для использования в больших производственных хранилищах данных. Используя портлет Elastic Marts Builder, можно за 10 минут создать нужную базу данных и начать работать, получая данные из внешних или внутренних источников.

Совершенно очевидно, что облачные технологии и ЦОД, собранные из дешевых серверов, в перспективе могут составить альтернативу специализированным машинам, предназначенным для аналитики. Сегодня мы привыкли к схеме, в которой имеется корпоративное хранилище Enterprise Data Warehouses со специализированными машинами Data Warehouse Appliances, но вполне вероятно и синтетическое решение, когда в облаке собраны оба компонента. Первой этот подход предложила компания Greenplum, назвав его Enterprise Data Cloud vision и сделав на него серьезную ставку.

Что касается Teradata, то складывается впечатление, что компания лишь бросила пробный камень, сохраняя верность избранной технической политике. В подтверждение этого можно использовать еще одно сообщение, сделанное Teradata, которое свидетельствует, что компания не оставляет традиционные для себя подходы. Параллельно с Teradata Agile Analytics Cloud была выпущена скоростная аналитическая машина Teradata Extreme Performance Appliance 4555, построенная на флэш-технологии с использованием твердотельных дисков, обещающая ускорение примерно в 150 раз. Эта машина должна появиться в первом квартале 2010 года и может быть особенно полезна при обработке сложных событий (Complex Event Processing, CEP).


Универсальные коммерческие СУБД: есть ли перспективы?

Сегодня к универсальным коммерческим СУБД с легкой руки видных представителей западных научных кругов прилепилось словечко legacy, и ожидается, что их место скоро займут быстрые и недорогие специализированные СУБД. Так ли это?

Exa против Tera

Приставку Exa в названии нового специализированного семейства продуктов Exadata, анонсированного компаниями Oracle и HP в сентябре 2008 года, следует рассматривать как вызов производителям, работающим в сегменте аппаратного и программного обеспечения для хранилищ данных и систем бизнес-аналитики.