Тенденции развития универсальных коммерческих субд м. Ривкин

Существуют также небольшие СУБД для нишевых (специализированных) решений и постоянно появляются прототипы новых специализированных СУБД (объектно-ориентированные СУБД, ХML СУБД, СУБД для обработки потоковых данных, СУБД для работы с текстами и т д).

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

I. Как предсказать тенденции развития СУБД
Раз в несколько лет собираются группы ведущих специалистов в области СУБД и устраивают обсуждение состояния отрасли, последних исследований в области СУБД. После мозгового штурма создается отчет, в котором перечислено множество интересных потенциальных направлений развития СУБД. Последним таким отчетом был так называемый Клермонтский отчет (май 2008) [1]. До этого были Лоуэльский отчет 2003, Ассиломарский отчет 1996, отчет собрания в Лагуна-Бич 1989. [2, 3, 4]. C прекрасным переводом этих отчетов на русский язык С Кузнецова можно ознакомиться на сайте citforum.ru.

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

Другой (прагматичный) подход к предсказанию тенденций основывается на анализе и текущего состояния и планов развития лидеров рынка СУБД (Oracle, DB2, SQL Server). Дело в том, что жесткая конкуренция на рынке СУБД заставляет производителей СУБД тщательно отслеживать новые версии конкурентов и, по возможности, быстро реализовывать их в следующих версиях своих продуктов, иначе на рынке не выжить. Поэтому анализ состояния и перспектив развития таких СУБД, как IBM DB2 9.5 и следующая версия Cobra, MS SQL Server 2008 и Oracle 11.1 и 11.2 позволяет делать более реалистичные предсказания тенденций развития универсальных коммерческих СУБД.

II. Революции не будет
Однако, прежде чем говорить о тенденциях развития этих СУБД, надо понять, будут ли они существовать в дальнейшем и не умрут ли в ближайшем будущем. Дело в том, что в последние несколько лет появилась целая серия статей Майкла Стоунбрейкера и К, в которых провозглашается грядущая революция в области СУБД и предсказывается скорая кончина универсальных коммерческих СУБД [5, 6, 7, 8]. Переводы и пересказы этих статей можно найти у С Кузнецова [9]. Стоунбрейкер обосновывает это тем, что современные универсальные коммерческие СУБД постоянно увеличивают свой функционал без переписывания ядра, в результате чего становятся очень сложными (никто сегодня не знает и не использует весь имеющийся функционал), громоздкими, медленными и дорогими. Он предсказывает, что грядет эпоха специализированных СУБД (потоковых, XML, научных, для обработки текстов и т д), которые вытеснят существующие универсальные СУБД в первую очередь за счет своей быстроты и компактности. Иллюстрируется это на примере нескольких стартапов (StreamBase, Vertica, ASAP, H-Store), которые показывают для специализированных решений (потоковая обработка, хранилища данных, научные исследования) производительность на 1-2 порядка выше, чем в современных промышленных дисковых СУБД.

Однако при ближайшем рассмотрении оказывается, что многие из этих поразительных результатов не совсем корректны. Так, при тестировании СУБД Vertica с поколоночным хранением данных используется огромная таблица (с более чем 200 колонками) из которой выбирают всего несколько колонок. Понятно, что при таком подходе традиционная СУБД работает намного медленнее, но любая операция выборки записей с разумным числом полей из этой таблицы на Vertica будет очень долгой. Автор этой статьи сам в свое время участвовал в разработке СУБД с векторным (по столбцам) хранением данных (проект АРИУС) и знает сколько вычислительных ресурсов необходимо чтобы разбить таблицу на векторы, а потом из них по ссылкам собрать записи и сколько длится обновление группы полей в такой записи.

Такие же некорректности есть и в других примерах, так Стоунбрейкер предлагает пожертвовать журналами транзакций, отказаться от одновременной работы пользователей, отказаться от случайных (Ad Hock) запросов, работать с базами, умещающимися целиком в оперативной памяти, всю логику приложения реализовывать внутри СУБД (в виде хранимых процедур) и т д. Все это ради достижения высокой производительности за счет надежности, масштабируемости, безопасности и т д

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

Дело в том, что хотя производительность СУБД и важна, но пользователи выбирают СУБД, ориентируясь на совокупность характеристик. Обычно учитываются такие характеристики, как обеспечение высокой надежности и непрерывности работы, масштабируемость, безопасность, простота управления, простота разработки, возможность работы с большими БД, поддержка специальных схем, алгоритмов и типов данных (DW, OLTP, XML, GIS, тексты и т д), поддержка стандартов, поддержка национального языка. Кроме того, очень важна распространенность данной СУБД в стране, наличие и возможность обучения специалистов (администраторов, разработчиков), наличие большого числа удачных внедрений СУБД для приложений, похожего типа (references) и т д. Здесь специализированные СУБД конкурировать с лидерами рынка не могут.

Еще одним важным аспектом является то, что заранее очень трудно сказать, какой функционал СУБД понадобится заказчику в будущем. Сегодня он работает только с алфавитно-цифровой информацией, а завтра ему понадобится обработка в том же приложении документов, видео или гео информации. Часто мы видим, что системы, надежность работы которых вначале казалась не очень важной, вдруг становятся определяющими (конвеер остановился, т к система учета и контроля въезда/выезда транспорта дала сбой). Поэтому в большинстве случаев навряд ли при выборе СУБД можно себе позволить заранее отказаться от какого-то функционала.

Более того, уходит в прошлое время, когда приложение работало только с одним типом данных. Например, уже мало осталось чисто ГИС систем. Система должна хранить не только карты и координаты объектов (ГИС информацию), но и алфавитно-цифровые данные, описания состояния объектов, изображения объектов, документацию по объектам и т д. Т е нужны универсальные СУБД, использовать несколько специализированных СУБД в этих случаях очень сложно и дорого.

При выборе СУБД заказчик в первую очередь ориентируется на опыт и рекомендации коллег по бизнесу. Неспециалисту сегодня сложно провести детальный анализ и выбор СУБД. А коллеги используют универсальные коммерческие СУБД. Учет опыта и рекомендаций коллег по бизнесу в своей стране или в родственных областях бизнеса за рубежом часто определяет выбор. И здесь также малоизвестные специализированные СУБД проигрывают лидерам рынка.

Ну и конечно важна надежность и известность фирмы производителя СУБД. Сколько раз мы были свидетелями ухода с рынка производителей ПО, после чего приходилось переписывать все приложения, теряя время и деньги. Исходя из всех этих соображений заказчики и разработчики приложений, как правило, выбирают не просто СУБД, а платформу для разработки большого числа разнородных приложений.

Что касается сложности и избыточного функционала универсальных СУБД – это по-моему не проблема. В каждый момент времени разработчик и администратор изучают и используют только тот функционал, который им нужен. Незнание объектно-ориентрованного подхода, работы с XML и текстом или средств администрирования кластера не мешают развернуть и использовать систему. Когда этот функционал понадобится, его можно легко освоить и начать использовать. Знать все и сразу ненужно.

Да, по мере появления нового функционала требования к оборудованию (память, процессоры, место на диске) растут, но они не так важны. Оборудование сегодня развивается настолько быстро, что намного опережает скорость роста требований СУБД. Я бы заметил, что новые версии ОС (особенно Windows) гораздо быстрее ужесточают требования к оборудованию, чем СУБД.

По мере развития ПО СУБД мы можем видеть, что требуется довольно много времени, чтобы важные новые возможности начали работать эффективно, быстро, надежно, без ошибок. Технологии становятся все сложнее и сложнее. Например, компания Oracle уже около 10 лет совершенствует реализацию средств работы в кластере (архитектура shared anything), IBM много лет “вылизывает” свой прекрасный оптимизатор запросов и т д. Т е требуется время, ресурсы, которых у мелких стартапов нет, чтобы довести до ума сложные новые технологии. Только лидеры рынка могут позволить себе вкладывать в это огромные деньги, тем самым увеличивая разрыв. С нуля нельзя сделать хороший универсальный коммерческий продукт, а вот новые идеи и технологии, порожденные в стартапах, лидеры рынка умеют быстро воспринимать и реализовывать в своих продуктах, оставив стартап позади (или купив его вместе с технологией).

История развития СУБД показала, что часто выживают не те производители, которые первыми реализовали новые идеи, а те, кто имеет более мощный и агрессивный маркетинг. Побеждают не лучшие технологии, а деньги, маркетинг, правильная стратегия развития. И здесь лидеры рынка тоже сильнее. Они просто не допустят революции в области СУБД. Имея большие финансовые ресурсы и большое число разработчиков, лидеры быстро добавят новый функционал в свои СУБД, если надо, перепишут даже часть ядра. Поэтому конкурировать с ними сложно. Единственное, что может повлиять на судьбу универсальных СУБД – это революционные изменения в оборудовании, которые могут привести к кардинальному изменению внутренней архитектуры СУБД (например, отказ от дисков и появление быстрой дешевой оперативной флеш памяти или драматическое увеличение скорости передачи данных по сетям, превращающее множество разбросанных по всему миру компьютеров в один суперкомпьютер (сеть как компьютер). Но это нам в ближайшие 5-7 лет не грозит.

Так что кризиса пока нет и можно смело предсказывать тенденции развития универсальных коммерческих СУБД

В свою очередь компания Oracle, имея СУБД с достаточно развитым функционалом, может себе позволить исследования по новым направлениям и реализацию принципиально новых подходов, таких как Enterprise GRID [10], машина баз данных, измерение времени в БД, Real Application Testing и т д. Поэтому при определении тенденций развития мы будем ориентироваться на достижения лидеров рынка и в первую очередь Oracle 11g.

Понятно, что каждая новая версия СУБД реализует несколько сотен крупных и мелких новых возможностей. Поэтому выбор будет достаточно субъективен, возможно другие аналитики и специалисты расставили бы акценты по другому. Я постарался из всего множества направлений отобрать дюжину на мой взгляд наиболее важных тенденций. Конечно же список не полон и тенденции не равнозначны по важности и сложности, но я постарался выделить основные тенденции. Прогноз не может быть на неограниченный срок. Я думаю, что эти тенденции будут актуальны на ближайшие годы (на 2 – 3 версии СУБД) – это приблизительно 5 – 7 лет.

3. 
   Дюжина тенденций развития
   

Итак, мне кажется, что наиболее важными тенденциями развития современных универсальных коммерческих СУБД на ближайшее время будут следующие:

1. 
   Виртуализация ресурсов и GRID-технологии
   
2. 
   Встраивание Information Life cycle Management (ILM) в СУБД
   
3. 
   Самоуправление, самодиагностика, самолечение
   
4. 
   Real Application Testing – механизмы промышленного тестирования версий и изменений
   
5. 
   Совершенствование архитектур максимальной доступности (разные режимы standby, Active standby, Snapshot standby, минимизация времени плановых простоев (модификация приложений и версий СУБД, online redefinition)
   
6. 
   Включение измерения времени в СУБД
   
7. 
   Поддержка новых типов данных (XML, RFID, Semantic Web, геном, медицина, быстрые LOB и т д)
   
8. 
   Умные механизмы сжатия и дедублирования
   
9. 
   Совершенствование методов защиты данных (DataVault, Audit Vault, A&I management
   
10. 
    In-memory СУБД реального времени как кэш для коммерческих СУБД
    
11. 
    Облачные вычисления (Cloud computing)
    
12. 
    Машины баз данных
    

Рассмотрим эти тенденции подробнее.

Выходом является виртуализация ресурсов. При этом все диски ЦОД объединяются в один большой виртуальный диск, на котором располагаются все данные всех приложений и мы можем гибко на ходу увеличивать этот виртуальный диск, добавляя к нему новые физические диски, или легко отдавать место для хранения тем приложениям, которым оно сейчас необходимо. Та же картина и с процессорным ресурсом. Объединение множества компьютеров в один виртуальный компьютер, на котором одновременно работает множество приложений, мощность которого можно легко увеличивать на лету добавляя новые компьютеры, и возможность перераспределения вычислительных ресурсов этого суперкомпьютера между приложениями по мере необходимости, позволяет резко повысить гибкость вычислительной системы, снизить ее стоимость и увеличить эффективность использования оборудования. Примером такой виртуализации является Oracle GRID [10], где диски объединены в Storage Grid, а компьютеры в Database Grid – виртуальный сервер БД и Application Grid – виртуальный сервер приложений. Для управления таким множеством элементов используется ПО Grid Control, которое позволяет работать с множеством объектов как с единым целым (рис 1).

Если в качестве элементов GRID используются дешевые элементы (дешевые диски, обычные Intel компьютеры), то стоимость такой вычислительной среды намного меньше, чем при использовании традиционных архитектур. Поскольку элементы виртуального диска или виртуального компьютера взаимозаменяемы, то система также обладает повышенной надежностью и живучестью, т к выход из строя одного или нескольких элементов не приводит к остановке работы. Система просто сама автоматически переконфигурируется и продолжает работу.

Такой подход очень привлекателен для организаций, он позволяет создавать вычислительный ресурс неограниченной мощности и не заботиться о том, на каких компьютерах реально работает Ваше приложение. Главное – запросить и получить тот вычислительный ресурс, который Вам сейчас нужен. Система сама выполнит балансировку нагрузки для Вашего приложения, создаст, если надо, БД с учетом обеспечения зеркалирования данных и снижения нагрузки по вводу/выводу, задействует столько элементов GRID, сколько необходимо для обеспечения требуемой Вам надежности и производительности. И по мере изменения внешних условий и Ваших требований она будет подстраиваться под эти требования.

Сегодня уже реализованы такие Еntеrprise GRID первого поколения на Oracle (Amazon, e-Bay Латинской Америки, EDS ABNAMRO и т д), компания IBM активно проводит исследования в области GRID технологий для научных вычислений, существует специальный инструментарий Globus Toolkit для использования Grid технологий при разработке приложений (однако подход Oracle, который не требует использования специальных инструментов и подходов для разработки корпоративных приложений, которые будут работать в среде GRID, кажется более перспективным)

Основой Database GRID у Oracle является архитектура Real Application Clusters, реализующая подход shared disk (все узлы кластера одновременно работают с единой БД). Еще одним подтверждением перспективности подхода послужила информация о разработке компанией Sybase продукта Sybase ASE Cluster Edition, который очень похож на Oracle RAC, похожую архитектуру реализует и IBM DB2 для Mainframe.

У Enterprise Grid первого поколения был ряд ограничений, так выделялось два виртуальных компьютера – Database Grid и Application Grid (вместо одного единого большого виртуального компьютера для СУБД, серверов приложений, Веб серверов, HTTP серверов и т д), ресурсы не перераспределялись автоматически в соответствии с заранее заданной политикой, система не адаптировалась автоматически к постоянно изменяющейся нагрузке, приложения не могли без остановки работы переезжать с более слабых узлов GRID на более мощные и т д. Большинство из этих ограничений будет снято в архитектуре Enterprise GRID 2, примером которой будет Oracle 11.2.

Рис 1. Oracle GRID 2

Рис. 2. Цикл жизни данных и информации

Поддержание жизненного цикла информации и данных разного типа как правило сегодня реализуется на уровне логики приложений. Это сложно, негибко, усложняет приложения и снижает качество управления информацией. В результате важные данные могут быть утеряны (пример - компания Энрон) или занимать большой объем на дорогих дисках.

Часто управление жизненным циклом данных реализуют производители систем хранения. Но поскольку они работают именно с данными (а не с информацией) и не знают бизнес логики и бизнес характеристик информации, то реализуют поддержку именно жизненного цикла данных (DLM), а не информации (ILM)

Поэтому сегодня наметилась тенденция реализации механизма ILM на уровне самой СУБД. Администраторы или разработчики описывают различные области хранения данных с разными характеристиками (быстрые диски, медленные диски, ленты, флеш память, CD и т д) и правила разделения данных одного типа на группы (например, по мере устаревания, по частоте использования и т д). Группы привязываются к областям хранения и при изменении характеристик данных они автоматически перемещаются в другую группу, а следовательно и в другую область хранения. При этом меняются характеристики этих данных, данные могут сжиматься, переводиться в режим “только для чтения” и т д. Система будет следить, чтобы данные группы хранились требуемое количество времени и затем уничтожались.

Разделение данных на группы должно учитывать бизнес смысл данных (работаем с информацией) и должно быть независимым от оборудования, на котором данных хранятся и обрабатываются, оно должно быть прозрачным для приложений (те приложения не знают о том, что эти данные разделены на группы и работают как обычно). Очень удобным средством такого логического разделения данных на группы является механизм секционирования (partitioning). Например, можно группировать данные по диапазону значений, по времени, по частоте использования, по географии размещения, по значению одного или нескольких полей записи. Возможно и смешанное секционирование (по нескольким измерениям). Графический инструментарий позволяет не только описать эти группы, области хранения, политики хранения/уничтожения и т д и отслеживать состояние данных. Он также подскажет сколько денег и места на дисках Вы сможете сэкономить используя тот или иной вид сжатия данных, тот или иной тип устройств хранения. С помощью механизма ILM Вы сможете переложить всю ответственность за поддержку жизненного цикла информации на СУБД.

3 Самоуправление, самодиагностика, самолечение
СУБД становятся все сложнее и сложнее и для их быстрой и надежной работы требуется все более опытные администраторы. Но даже они не могут оперативно реагировать на постоянно меняющуюся нагрузку СУБД, изменение режима работы приложений и т д. Кроме того, растет число СУБД в организации, которые надо администрировать.

Единственный выход решить эти проблемы – сделать СУБД самоуправляемыми, самодиагностирующимися, самолечащимися. Большинство производителей СУБД уже идут по этому пути, но возможностей развития остается еще много. Основная идея здесь проста. Во время работы СУБД постоянно собирает информацию о своей работе, анализирует ее (оперативно и в фоновом режиме), принимает решения и либо автоматически их реализует (например, меняет размеры областей в памяти, выполняет процедуры, запрашивает у ОС дополнительные ресурсы, меняет планы выполнения запросов), либо информирует администратора о проблеме, рекомендует ему последовательность действий для решения проблемы и после одобрения выполняет эти действия. При анализе работы применяются лучшие практики и знания, накопленные лучшими администраторами этой СУБД. Их список постоянно совершенствуется. Системы учатся реагировать проактивно (т е заранее, до возникновения проблем), выявляют причины, а не следствия возникновения проблем, учитывают множество факторов, которые администратору в условиях стресса учесть трудно.

Системы контроля и самонастройки могут настраивать размеры областей памяти, ввод/вывод, давать рекомендации по оптимизации запросов, выявлять проблемы безопасности (например, незакрытые порты, неизмененные пароли и т д) и производительности, нехватки места и ресурсов, отклонения от заданных или типичных стандартов поведения и т д

В фоновом режиме СУБД постоянно проверяет свое состояние, целостность данных, ищет и исправляет сбойные блоки и файлы, сверяет контрольные суммы и т д. Ведется работа по встраиванию алгоритмов data mining для выявления и контроля зависимостей между данными. Многие СУБД научились сегодня автоматически (без участия DBA) выполнять Backup и восстановление, собирать информацию о сбоях и отправлять ее в службу технической поддержки, отслеживать появление новых важных патчей. Продолжается совершенствование оптимизаторов SQL запросов, они учитывают все больше важных факторов (например, взаимовлияние кардинальности столбцов, параметры оборудования и среды эксплуатации и т д). Детальная оптимизация, которая требует много вычислительных ресурсов, проводится в фоновом режиме, выявляя и тестируя новые, более перспективные планы выполнения запросов, автоматически выявляя и настраивая наиболее ресурсоемкие SQL.

Еще одной важной тенденцией является уменьшение количества “ручек”, которые может подкрутить не очень опытный администратор БД, и переход к заданию бизнес критериев работы, таких как допустимое время простоя системы при сбоях, максимально допустимое время отклика, минимальная пропускная способность системы и т д. На основе этих критериев СУБД сама регулирует свои параметры, чтобы обеспечить требуемый результат. Благодаря всему этому, время обучения администратора мощных коммерческих СУБД снизилось до нескольких дней. Однако, у опытного DBA все еще остается возможность детально контролировать и настраивать работу СУБД, поскольку ни один оптимизатор пока не может сравниться с гуру – администратором.

4 Real Application Testing – механизмы промышленного тестирования версий и изменений
Жизнь не стоит на месте и вокруг на все постоянно меняется. Чтобы не отстать от конкурентов, мы вынуждены менять компьютеры в ЦОД, добавлять процессоры и память, патчировать ОС и менять ее версию, патчировать СУБД и переходить к новым более мощным и современным версиям СУБД. В процессе работы приходится постоянно менять параметры работы СУБД и структуры данных, создавать новые объекты в БД (индексы, материализованные представления и т д), менять архитектуру вычислительной системы (например, переходить от одного компьютера к кластеру или GRID), выполнять рекомендации службы технической поддержки, опытных коллег, руководства и т д

К сожалению, любые из этих необходимых действий могут привести не к улучшению работы системы, а к ухудшению или остановке работы. Автор знает примеры совершенно безобидных изменений, которые резко ухудшали скорость работы системы. А уж апгрейд на новую версию СУБД – это хуже пожара. Зная все это администраторы БД оттягивают внесение изменений до последнего момента, не желая рисковать. Единственная возможность решить эту проблему – позволить заранее протестировать любые из перечисленных изменений (ОС, оборудования, структур данных, архитектуры) на тестовой системе (до их выполнения на промышленной системе) и оценить последствия. Для этого используется тестовая копия БД, у некоторых производителей в качестве тестовой можно временно использовать резервную БД (Oracle Snapshot Standby).

Существует много пакетов, позволяющих имитировать нагрузку на тестовой системе для выполнения функционального и нагрузочного тестирования. Однако все эти пакеты создают не реальную, а синтетическую нагрузку, дороги, требуют длительного времени для анализа работы системы и создания тестовых скриптов. И в результате многие проблемы так и остаются не выявленными.

Появившийся у Oracle продукт RAT (Real Application Testing) очевидно вскоре будет реализован у большинства СУБД, т к он позволяет на реально работающей под нагрузкой производственной системе захватить (с минимальными накладными расходами) реальную нагрузку (с учетом времени выполнения, одновременности, зависимости операций) и воспроизвести эту нагрузку на тестовой БД, не устанавливая там приложение. Захват и проигрывание нагрузки легко выполнить и они позволяют выявить появившиеся/ пропавшие/изменившиеся после выполнения изменений ошибки, изменения в планах и результатах выполнения реальных SQL, проблемы снижения производительности как всей системы, так и отдельных запросов. После анализа результатов система дает рекомендации по улучшению работы SQL, позволяет попробовать различные варианты оптимизации работы. Откатывая тестовую БД назад можно тестировать различные изменения и их совокупность. И только после того, как все проблемы выявлены и решены, изменения можно выполнять в производственной среде.

Поскольку захват, проигрывание, анализ, оптимизация проводятся в автоматическом или автоматизированном режиме, они не требуют много времени от администратора БД. Впервые появилась возможность значительно снизить риски перехода от старой версии СУБД к новой, более совершенной. Регулярный апгрейд СУБД становится обычным рутинным делом (рис 3).

Рис. 3. Oracle Real Application Testing

Особо хочется отметить тенденцию к более полному использованию возможностей резервной БД. Сегодня у большинства производителей она постоянно догоняет основную БД и используется только тогда, когда основная БД выйдет из строя. Это замораживает инвестиции в оборудование и не дает гарантии того, что когда сбой наконец произойдет, переключение будет успешным. Поэтому производители начинают реализовывать механизм быстрого переключения основная – резервная и резервная – основная БД, чтобы этот механизм можно было легко и часто использовать при выполнении регламентных работ и для поэтапного апгрейда СУБД без остановки ее работы. Кроме того, появляются механизмы открытия резервной БД на чтение в то время, как она догоняет основную. Это позволяет разгрузить производственную системы, вынеся на резервную БД операции построения отчетности, анализа, backup. Также резервную БД можно переводить в режим тестирования и использовать для тестирования изменений. После окончания тестирования она возвращается в режим резервной БД и продолжает догонять основную БД. Это тем более удобно, что можно одновременно иметь несколько standby баз, иногда даже в разных городах.

Сегодня большинство сложных, ресурсоемких операций по изменению структуры БД или параметров работы СУБД может производиться online, в фоновом режиме. Т е изменение структуры таблиц и индексов, перемещение объектов не приводит к замедлению работы с этими объектами. Online патчи позволят модифицировать ПО без остановки работы системы.

В ближайшее врем будет реализован и механизм версионности приложений БД, когда в БД существует несколько различных версий одной и той же процедуры, функции, таблицы, пакета, view и т д. Это позволит на какое то время обеспечить одновременную работу с базой двух разных версий приложения с плавным переключением со старой версии на новую. Таким образом апгрейд приложений БД и версий БД станет еще более быстрым и безболезненным.

Для выполнения этих операций в СУБД встраивается измерение времени и механизм для быстрого воссоздания старого состояния базы, объекта или запроса. В частности у Oracle это реализуется с помощью команды Flashback (Database, Table, Transaction, Query, Version Query). Развитием механизма Flashback стал механизм Flashback Data Archive, который позволяет компактно хранить след изменения данных и легко восстанавливать старое состояние данных таблиц. При этом можно откатиться на любой отрезок времени в прошлое, вплоть до момента создания этой таблицы, и восстановить старое состояние ее данных, даже если за это время изменилась структура таблицы

За последнее время началась реализация поддержки в универсальных СУБД таких специфических типов данных как RFID, данные семантических сетей (Semantic Web), данные генома, специальные типы данных и алгоритмов для медицины, биологии, иммунологии, генетики. Практически все универсальные СУБД сегодня совершенствуют работу с XML. В ближайшее время, когда мы наконец перейдем к более умным веб страницам, описывающим не только представление данных, но и их семантику, резко возрастет спрос на работу с семантическими сетями, поддержку стандартов OWL и RDF в СУБД, т к объем данных этих сетей будет огромен и скорость извлечения и обработки таких данных будет очень важна..

Также наметилась тенденция перемещения неструктурированных данных, ранее хранимых рядом с СУБД (в файловой системе), внутрь СУБД. Польза от использования единого механизма доступа, безопасности, надежности и т д для структурированных и неструктурированных данных была очевидна давно. Однако СУБД работали с неструктурированными данными медленнее, чем файловая система. Сегодня новые механизмы СУБД (такие как SecureFiles Oracle) позволят работать с такими неструктурированными данными не медленнее, а иногда и быстрее (за счет сжатия, дедублирования, работы по частям и т д), чем при их хранении в файловой системе. Хранение документов, изображений, видео, аудио и т д в БД позволит упростить разработку приложений и повысить их качество.

8 Умные механизмы сжатия и дедублирования
Объемы данных сегодня растут лавинообразно. Многие приложения хранят данные за большой период времени, в БД хранятся LOB объекты, документы, видео и т д. А стоимость дискового пространства до сих пор достаточно высока (до 1000$ за терабайт). Поэтому большинство производителей СУБД реализовало механизмы сжатия данных в БД. Речь идет о том, насколько умные эти механизмы сжатия. Дело в том, что за сжатие, разжатие и изменение сжатых данных приходится платить производительностью работы системы. Поэтому прослеживается тенденция к совершенствованию механизмов сжатия.

Во-первых, для разных данных должны автоматически применяться различные алгоритмы сжатия, а там, где сжатие не дает большого выигрыша, оно производиться не должно. Во-вторых, администратор должен иметь возможность выбирать различные уровни степени сжатия, понимая, что за экономию места придется платить процессорным временем. В-третьих, сжатие должно быть прозрачно для приложения, т е приложение не знает о том, сжаты ли его данные. В-четвертых, иногда для LOB полезен механизм дедублирования, когда система сама выявляет дубли LOB полей и хранит их только в одном экземпляре. В-пятых, сжимать надо уметь все. Не только реляционные, но и неструктурированные данные, backup, данные сетевого трафика, данные экспорта, индексы. А иногда надо наоборот, сжимать не все данные таблицы, а только редко используемую часть таблицы. И СУБД должна работать со сжатыми данными также эффективно, как и с несжатыми, не тратя время на перестройку таблиц, на разжатие ненужных блоков и т д

Традиционные алгоритмы сжатия позволяют сжать данные в 2-3 раза. Некоторые специфические виды сжатия позволяют увеличить эту степень сжатия на порядок, но при этом сильно замедляется выполнение операций DML с этими данными. Например, известно, что сжатие поколоночно хранимых и заранее отсортированных данных обеспечит очень высокий уровень сжатия (иногда в десятки раз). Однако попытки изменения таких таблиц в Oracle 11.2 показали, что время обновления данных значительно увеличивается. Однако для хранилищ данных и исторических данных такой подход вполне приемлем.

Администратор должен иметь возможность для различных данных, различных таблиц и даже частей таблиц выбирать те варианты сжатия и хранения (по строкам, по столбцам), которые наиболее подходят с точки зрения бизнес использования этих данных. Причем, поскольку для приложений способ хранения и сжатия прозрачен, DBA может периодически менять способы хранения и сжатия. Я думаю, этот подход будет очень полезен пользователям больших БД (например, SAP-пользователям), которые сегодня вынуждены постоянно увеличивать свои многотеррабайтные системы хранения. Ну и умный механизм сжатия позволяет оставлять самые свежие и наиболее активно используемые данные некоторое время несжатыми. Позднее они сжимаются автоматически в фоновом режиме.

Кроме того, интенсивно совершенствуются средства защиты данных внутри БД. Например, быстро развивается механизм задания политик переопределения запросов на лету, т е запрос автоматически модифицируется в зависимости от самых разных параметров (имя приложения, время запуска на выполнение, имя пользователя, место поступления запроса – Интернет/локальная сеть, номер терминала и т д)

Еще одно перспективное направление развития – изоляция DBA от данных. Сегодня администратор может видеть и изменять все данные в БД. Новые средства защиты (такие как Oracle Data Vault option) позволят DBA выполнять все операции по администрированию БД, не позволяя ему видеть и менять данные. Также администратору можно будет ограничить набор разрешенных к выполнению операций. Ограничение может быть привязано к имени DBA, времени, точке входа в систему.

10 In-memory СУБД реального времени как кэш для коммерческих СУБД
Практически все универсальные коммерческие СУБД сегодня – это СУБД, ориентированные на работу с дисками. Такая архитектура, даже при очень хорошей настройке приложения может дать время отклика порядка нескольких миллисекунд. Однако для многих приложений (например, для систем работающих в реальном времени) нужно быстродействие на порядок выше (время отклика – микросекунды). Для получения такого быстродействия используются специальные СУБД, работающие в оперативной памяти (In memory DB), и имеющие специальную архитектуру, специальные способы хранения, адресации и индексации данных, специальные механизмы оптимизации и буферизации и т д. Данные на диск они не сбрасывают или делают это в фоновом асинхронном режиме. Надежность работы и обработка сбоев реализуется специальными методами (например, за счет репликации память – память). Многие не очень важные функции таких СУБД можно отключать (например, журналирование) в угоду быстродействию.

Сейчас наметилась тенденция использования таких быстрых in memory СУБД в качестве высокоскоростных кэшей к коммерческим дисковым СУБД. Oracle сегодня использует в таком качестве СУБД Times Ten, IBM приобрел СУБД SolidDB и начал ее интеграцию с DB2. Специальное ПО позволяет поднять или подкачивать данные в такой скоростной кэш и синхронизировать изменения в дисковой СУБД и в кэше. Приложения, требующие высокого быстродействия и малого гарантированного времени отклика практически работают с таким кэшем в памяти, который уже сам синхронизируется с дисковой СУБД. Таких кэшей над дисковой СУБД можно подвесить несколько, давая возможность многим приложениям получать время отклика (особенно при чтении и коротких обновлениях) в несколько микросекунд. При этом размеры основной БД могут быть очень большими (десятки и сотни терабайт), но кэшируется по определенной политике только часть данных. Важно, что для работы с использованием такого кэша не нужно специальное программирование, можно использовать стандартные протоколы (ODBC, JDBC), привычный язык дисковой СУБД.

Примерами Cloud Computing являются сервисы хранения (Amazon S3), вычислительные сервисы (Google App Engine, Amazon EC2) и сервисы данных (Amazon SimpleDB, Microsoft SQL Server Data Services, Google’s Datastore).

СУБД должны уметь работать в такой среде и использовать эту среду (например, ее систему хранения) для создания и хранения файлов и backup. Работа в среде cloud computing предъявляет повышенные требования к СУБД с точки зрения защиты данных и разграничения доступа (ведь данные размещаются на чужих компьютерах), с точки зрения масштабируемости (декларируется, что пользователь сервиса может заказать машину большой мощности и с большим количеством процессоров). Поскольку управление системой идет через Интернет, да и вообще сам подход подразумевает минимальные усилия по управлению как инфраструктурой, так и самой СУБД, то очевидно понадобится еще больше совершенствовать средства администрирования и повысить самоуправляемость СУБД.
12 Машины баз данных
В последнее время широко развивается направление хранилищ данных. Поскольку объемы данных огромны (сотни терабайт) и продолжают расти, а специальные алгоритмы традиционных СУБД уже не могут обеспечить хорошее время отклика для задач анализа и построения корпоративной отчетности, появляются специальные вычислительные системы с массивно-параллельной архитектурой. Наиболее известным примером такой архитектуры является NCR/Teradata. Это сплав оборудования и специального ПО. Такие архитектуры позволяют распараллелить обработку данных и вынести часть обработки с уровня СУБД на уровень ячеек хранения, которые сами имеют свои небольшие компьютеры.

Обычно при росте объема БД узким местом становятся каналы передачи данных между сервером БД и устройствами хранения. Возможность увеличить количество и пропускную способность таких каналов, а также снизить объем передаваемых данных за счет выполнения части операций по просмотру и выборке данных на уровне ячеек хранения, позволяет снять проблему каналов передачи. Такая связка оборудования и специального ПО, называемая машина баз данных, давно описана в литературе [11, 12]. Примеры – Netezza, Datallegro, Teradata.

Но обычно такие машины баз данных использовали специальное ПО и требовали специальной квалификации для разработки приложений. Они не использовали широко распространенные универсальные СУБД, а универсальные СУБД не поддерживали такую архитектуру. Сейчас началось движение универсальных коммерческих СУБД в сторону машин баз данных. Первый коммерческий пример – совместная Oracle и HP машина баз данных с ячейками хранения Exadata. Она обеспечивает для обычных приложений хранилищ данных Oracle ускорение обработки данных в десятки раз (до 70 раз) без переписывания приложений.

Oracle – HP Database Machine представляет из себя единый преднастроенный компьютер (с ячейками Exadata и кластером БД). Очень важна для таких архитектур сбалансированность компонент, те размер памяти, дисков, число процессоров, скорость каналов ввода/вывода и т д

1. 
   The Claremont Report on Database Research, 2008, http://db.cs.berkeley.edu/claremont/
   
2. 
   “The Lowell Database Research Self-Assessment”. CoRR cs.DB/0310006, 2003. Also in CACM 48(5): 111-118, 2005. Имеется пересказ на русском языке в обзоре C Кузнецова: «Крупные проблемы и текущие задачи исследований в области баз данных».
   
3. 
   “The Asilomar Report on Database Research”. SIGMOD Record 27(4): 74-80, 1998. Имеется перевод на русский язык.
   
4. 
   “Future Directions in DBMS Research – The Laguna Beach Participants”. SIGMOD Record 18(1): 17-26, 1989. Имеется пересказ на русском языке С Кузнецова: «Будущие направления исследований в области баз данных: десять лет спустя»
   
5. 
   A Conversation with Michael Stonebraker and Margo Seltzer, ACM Queue, Volume 5, Number 4, May/June 2007
   
6. 
   M. Stonebraker and U. Cetintemel. “One Size Fits All: An Idea Whose Time has Come and Gone”. In Proceedings of the International Conference on Data Engineering (ICDE), 2005.
   
7. 
   Michael Stonebraker, Chuck Bear, Uğur Çetintemel, Mitch Cherniack, Tingjian Ge, Nabil Hachem, Stavros Harizopoulos, John Lifter, Jennie Rogers, and Stan Zdonik. One Size Fits All? – Part 2: Benchmarking Results, 3rd Biennial Conference on Innovative Data Systems Research (CIDR) January 7-10, 2007, Asilomar, California, USA.
   
8. 
   Michael Stonebraker, Samuel Madden, Daniel J. Abadi, Stavros Harizopoulos, Nabil Hachem, Pat Helland. The End of an Architectural Era (It's Time for a Complete Rewrite). Proceedings of VLDB, 2007, Vienna, Austria
   
9. 
   С Кузнецов ” Универсальность и специализация: время разбивать камни?”, 2007, http://www.citforum.ru
   
10. 
    М Ривкин “Платформа для коммерческих сред Grid” //Открытые системы, 2003, N 12
    
11. 
    А. Александров. “Машины хранения данных” //Открытые системы, 2006, N 2
    
12. 
    Э. Озкарахан “Машины баз данных”, М., Мир, 1989