DeepEdit!

Марк Ривкин

 

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

Среди множества современных универсальных промышленных СУБД сегодня можно выделить трех лидеров, занимающих более 90% мирового рынка СУБД. Это СУБД первого эшелона – IBM DB2, Microsoft SQL Server и Oracle. В список СУБД второго эшелона входят Adabas, Cache, Firebird, Informix, Ingress, Interbase, Progress, Postgres, Sybase, Teradata, ЛИНТЕР и ряд других. Существуют СУБД для нишевых решений, и постоянно появляются прототипы новых специализированных СУБД: объектно-ориентированные СУБД, ХML СУБД, СУБД для обработки потоковых данных, СУБД для работы с текстами и т.д. 

Для формирования прогнозов развития отрасли, раз в несколько лет собираются группы ведущих специалистов в области СУБД и выпускают отчеты: Клермонтский отчет (май 2008) [1], Лоуэльский отчет 2003 [2], Ассиломарский отчет 1996 [3], отчет собрания в Лагуна-Бич 1989 [4]. Правда, большая часть этих предсказаний так и не сбывается – производители СУБД обычно руководствуются своими собственными соображениями. Более прагматичен подход к предсказанию тенденций на основе анализа текущего состояния и планов развития тройки продуктов, лидирующих на рынке СУБД, – анализ состояния и перспектив развития IBM DB2 9.5 и Cobra, MS SQL Server 2008 и Oracle 11.1 и 11.2 позволяет делать вполне реалистичные предсказания тенденций развития универсальных коммерческих СУБД. 

За последние несколько лет появилась серия статей Майкла Стоунбрейкера, в которых провозглашается грядущая революция в области СУБД и предсказывается скорая кончина универсальных коммерческих СУБД [5-8]. Стоунбрейкер обосновывает свою позицию тем, что современные универсальные коммерческие СУБД постоянно увеличивают свой функционал без переписывания ядра, в результате чего становятся сложными (никто сегодня не знает и не использует весь имеющийся функционал), громоздкими, медленными и дорогими. Грядет, по мнению Стоунбрейкера, эпоха специализированных СУБД, которые вытеснят универсальные. Данное утверждение иллюстрируется на примере продукции нескольких стартапов (StreamBase, Vertica, ASAP, H-Store), демонстрирующих на специализированных применениях производительность на один-два порядка выше, чем современные промышленные дисковые СУБД. 

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

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

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

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

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

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

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

Традиционно в большинстве организаций для каждого приложения выделяется отдельный компьютер (или группа) и свой набор дисков для базы, но поскольку в реальной жизни нагрузка на приложения постоянно изменяется, то ресурсы компьютеров оказываются загружены неравномерно. Выход – виртуализация. 

Все диски объединяются в один виртуальный, на котором располагаются все данные всех приложений. Например, в Oracle GRID [9] диски объединены в Storage Grid, а компьютеры – в Database Grid (виртуальный сервер базы данных) и Application Grid (виртуальный сервер приложений). Для управления таким множеством элементов используется программа Grid Control, которая позволяет работать с множеством объектов как с единым целым. 

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

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

Сегодня уже реализованы такие корпоративные grid первого поколения на решениях Oracle (Amazon, EDS ABNAMRO), а IBM активно проводит исследования в области grid для научных применений, продвигая инструментарий Globus Toolkit. 

Основой Database GRID у Oracle является архитектура Real Application Clusters, реализующая подход shared disk (все узлы кластера одновременно работают с единой базой данных), похожую архитектуру реализует и СУБД IBM DB2 для z/OS. 

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

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

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

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

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

ИТ-инфраструктура предприятий постоянно развивается, и в процессе работы приходится все время менять параметры СУБД и структуры данных, создавать новые объекты и т.д. Любое такое действие может привести к ухудшению или остановке работы, а уж переход на новую версию СУБД – хуже пожара. Единственная возможность решить эту проблему – позволить заранее проверить любые изменения на тестовой системе до их выполнения на промышленной системе. 

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

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

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

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

Для борьбы с ошибками, вызванными человеческим фактором, для аудита, а также для восстановления старых версий данных и отчетов надо иметь в СУБД штатную возможность «откатываться» в прошлое по оси времени. Для этого в СУБД встраиваются механизмы измерения времени и быстрого воссоздания старого состояния базы, объекта или запроса. В частности, у Oracle это реализуется с помощью команды Flashback, развитием которой стал механизм Flashback Data Archive, позволяющий компактно хранить след изменений данных и восстанавливать старое состояние данных таблиц. При этом можно откатиться на любой отрезок времени в прошлое, вплоть до момента создания таблицы, и восстановить старое состояние ее данных, даже если за это время изменилась структура таблицы. 

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

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

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

Традиционные алгоритмы сжатия позволяют упаковывать данные в два-три раза «плотнее», а некоторые специфические приемы позволяют увеличить этот показатель на порядок, но при этом сильно замедляется выполнение операций DML (Data Manipulation Language) с этими данными. 

Сегодня все чаще механизм управления учетными записями пользователей выносится из отдельных СУБД и приложений в единую централизованную систему организации (Identity&Access Management). Это упрощает управление в масштабах организации и позволяет управлять учетными записями исходя из требований бизнеса. Совершенствуются методы аудита, будет появляться интегрированная среда сбора и анализа информации всей организации. Кроме того, интенсивно совершенствуются средства защиты данных, например быстро развивается механизм задания политик переопределения запросов на лету – запрос автоматически модифицируется в зависимости от разных параметров (имя приложения, время запуска на выполнение, имя пользователя, место поступления запроса и т.д.). 

Еще одно перспективное направление – изоляция администратора от данных. Такие средства защиты, как Oracle Data Vault option, позволят выполнять все операции по администрированию, но не дают возможности видеть и менять данные. 

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

Сегодня наметилась тенденция использования In memory СУБД в качестве высокоскоростных кэшей к дисковым СУБД, например, Oracle использует в таком качестве СУБД Times Ten, а IBM – СУБД SolidDB. Приложения, требующие высокого быстродействия и гарантированного времени отклика, практически работают с таким кэшем в памяти, который сам синхронизируется с дисковой СУБД. При этом размеры основной базы могут быть очень большими, но кэшируется по определенной политике только часть данных. 

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

Поскольку объемы данных растут, а алгоритмы традиционных СУБД уже не могут обеспечить хорошее время отклика для задач анализа и построения корпоративной отчетности, то все большую популярность получают вычислительные системы с массивно-параллельной архитектурой, например NCR/Teradata. Такие архитектуры позволяют распараллелить обработку данных и вынести часть работы с уровня СУБД на уровень ячеек хранения, которые сами имеют свои небольшие компьютеры. 

Обычно при росте объемов узким местом становятся каналы передачи данных между сервером базы и устройствами хранения, поэтому для увеличения пропускной способности часть операций по просмотру и выборке данных переносится на уровень ячеек хранения. Такая связка оборудования и специального ПО называется машиной баз данных [10], реализации которых сегодня предлагают такие компании, как Netezza, Datallegro и Teradata. Однако такие машины работают со специальным ПО и требуют специальной квалификации для разработки приложений, не используют универсальные СУБД, а универсальные СУБД не поддерживали архитектуру машин. Сейчас началось движение универсальных коммерческих СУБД в сторону машин баз данных, и примером такого сближения стала совместная разработка Oracle и HP – машина баз данных с ячейками хранения Exadata.

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

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

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

Сжатие поколоночно хранимых и заранее отсортированных данных обеспечит их «уплотнение» в десятки раз, однако все попытки изменения таких таблиц в Oracle 11.2 показали, что время обновления данных значительно увеличивается, хотя для хранилищ данных и исторических данных такой подход вполне приемлем. 

HP Oracle Database Machine обеспечивает для обычных приложений хранилищ данных Oracle ускорение обработки данных до 70 раз без переписывания приложений. В том же направлении движется Microsoft, купившая DATAllegro и интегрирующая ее продукты с SQL Server. 

The Claremont Report on Database Research, 2008, http://db.cs.berkeley.edu/claremont. 

The Lowell Database Research Self-Assessment. CoRR cs.DB/0310006, 2003. Also in CACM 48(5): 111-118, 2005. 

The Asilomar Report on Database Research. SIGMOD Record 27(4): 74-80, 1998. 

Future Directions in DBMS Research – The Laguna Beach Participants. SIGMOD Record 18(1): 17-26, 1989. 

A Conversation with Michael Stonebraker and Margo Seltzer, ACM Queue, Volume 5, Number 4, May/June 2007. 

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. 

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. 

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. 

Ривкин М. Платформа для коммерческих сред Grid // Открытые системы. – 2003. – № 12. – С. 58-64. 

Александров А. Машины хранилищ данных // Открытые системы. – 2006. – № 2. – С. 32-38. 

Марк Ривкин (Mark.Rivkin@oracle.com) –

 руководитель направления отдела технического консалтинга

 Oracle СНГ (Москва). 

Постоянный URL статьи: http://www.osp.ru/os/2009/02/7322713/