II. Революции не будет
Однако, прежде чем говорить о тенденциях развития этих СУБД, надо понять, будут ли они существовать в дальнейшем и не умрут ли в ближайшем будущем. Дело в том, что в последние несколько лет появилась целая серия статей Майкла Стоунбрейкера и Ко, в которых провозглашается грядущая революция в области СУБД и предсказывается скорая кончина универсальных коммерческих СУБД [, , , ]. Переводы и пересказы этих статей можно найти у С Кузнецова []. Стоунбрейкер обосновывает это тем, что современные универсальные коммерческие СУБД постоянно увеличивают свой функционал без переписывания ядра, в результате чего становятся очень сложными (никто сегодня не знает и не использует весь имеющийся функционал), громоздкими, медленными и дорогими. Он предсказывает, что грядет эпоха специализированных СУБД (потоковых, 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 лет не грозит.
Так что кризиса пока нет, и можно смело предсказывать тенденции развития универсальных коммерческих СУБД
Как уже упоминалось выше, появление важных новых возможностей у одного из конкурентов заставляет остальных немедленно их реализовать. Однако ситуация с разработкой новых возможностей у разных производителей выглядит по-разному. При анализе новых возможностей последних версий СУБД DB2 и особенно MS SQL Server видно, что большинство из них были реализованы у Oracle недавно или несколько лет назад. (Раньше эту пальму первенства держала IBM.) Автору довелось поговорить с разработчиками из лабораторий IBM в Торонто, и на вопрос, почему они планируют реализовать в новой версии СУБД (тогда это был Viper) эти функции, а не иные, они ответили, что действуют по запросам пользователей. Понятно, что пользователи СУБД в своих запросах опираются на личный опыт (эксплуатация ограниченного круга своих приложений) или на то, что увидели у конкурентов. Поэтому такой подход к разработке (а он очевидно актуален и для Microsoft) заставляет их все время догонять лидера. Microsoft приходится еще сложнее, т.к. приходится параллельно реализовывать отсутствующий функционал в области безопасности и работы с большими БД.
В свою очередь, компания Oracle, имея СУБД с достаточно развитым функционалом, может себе позволить исследования по новым направлениям и реализацию принципиально новых подходов, таких как Enterprise GRID [], машина баз данных, измерение времени в БД, Real Application Testing и т.д. Поэтому при определении тенденций развития мы будем ориентироваться на достижения лидеров рынка и, в первую очередь, Oracle 11g.
Понятно, что каждая новая версия СУБД реализует несколько сотен крупных и мелких новых возможностей. Поэтому выбор будет достаточно субъективен, возможно, другие аналитики и специалисты расставили бы акценты по-другому. Я постарался из всего множества направлений отобрать дюжину, на мой взгляд, наиболее важных тенденций. Конечно же, список не полон, и тенденции не равнозначны по важности и сложности, но я постарался выделить основные тенденции.Прогноз не может быть на неограниченный срок. Я думаю, что эти тенденции будут актуальны на ближайшие годы (на 2–3 версии СУБД) – это приблизительно 5–7 лет.
