Автор: Дмитрий Безруков, директор лаборатории решений компании
"ФОРС - Центр разработки"
Сегодня к универсальным коммерческим СУБД с легкой руки некоторых видных представителей западных научных кругов прилепилось словечко legacy. При этом молчаливо подразумевается, что "наследство" это - тяжелое. Учитывая, что переделка универсальных СУБД дело сложное, ожидается, что их место займут быстрые и недорогие специализированные СУБД, которые уже появляются на рынке. Так ли это?
Главным образом универсальные СУБД критикуют за неудовлетворительную производительность выполнения OLTP-операций и аналитики. Действительно, основы этих СУБД закладывались почти четыре десятилетия назад, а в последние годы появились новые концепции реализации базовых механизмов обработки и хранения данных, которые гораздо эффективнее созданных ранее, однако не могут быть использованы в универсальных СУБД без полного переписывания кода ядра. Критики предполагают, что производители СУБД на это не пойдут в основном из-за объема работ, требующего вложения огромных средств. Также утверждается, что универсальные СУБД перегружены функционалом из различных областей ИТ, хотя реально потребитель использует лишь его небольшую часть. Прогнозируется, что скоро универсальные СУБД будут вытеснены быстрыми и недорогими специализированными СУБД. В этом утверждении, конечно, есть доля истины - но лишь доля.
Предложение использовать на предприятии продукты нескольких стартапов для решения конкретных задач вместо одной универсальной СУБД звучит достаточно странно. Вряд ли серьезный менеджер примет такое решение, даже если эти новые продукты будут работать на порядок быстрее. В самом деле, одна универсальная СУБД снимает массу проблем, которые могут возникнуть при применении специализированных баз данных. Универсальная СУБД - это прежде всего развитая, содержащая массу опций на все случаи жизни инфраструктура, включающая в себя универсальный механизм резервного копирования и восстановления данных, унифицированный сетевой доступ, единое универсальное администрирование, развитые универсальные средства защиты от потерь и повреждений данных, единые интерфейсы для взаимодействия с различными схемами данных внутри СУБД, развитые механизмы взаимодействия с системами других производителей и др. Все это нарабатывалось годами, и требуются очень веские причины, чтобы отказаться от привычных удобств в пользу новых специализированных СУБД, возможно и обладающих лучшей производительностью.
Каждая специализированная СУБД имеет свою собственную инфраструктуру, свои собственные уникальные средства резервного копирования и восстановления, проверки данных, дублирования баз данных, кластерной обработки и т.д. С помощью универсальной базы данных, поддерживающей как OLTP, так и аналитику, можно воспользоваться единым набором средств, решающих все перечисленные задачи. К тому же, например, легче организовать процесс пополнения данных хранилища из базы OLPT в рамках одной универсальной СУБД, чем в двух специализированных.
Что касается перегруженности универсальных СУБД различными опциями, то для пользователя это скорее плюс - платить за опции не нужно, а в случае необходимости можно их протестировать и затем приобрести.
В ближайшем будущем, на мой взгляд, в области СУБД прорывов не предвидится - мегавендоры практически монополизировали эту область ИТ. Развитие СУБД будет происходить преимущественно эволюционно в направлении расширения функциональности. К тому же производители будут по возможности включать новые широко обсуждаемые технологии в свои СУБД. Для этого проводится колоссальная работа по информированию потребителей, образуются сообщества пользователей и другие общественные организации, и в итоге оказывается, что это именно то, что нужно пользователям. Но в первую очередь, пользователям нужно, чтобы система, обладающая новыми средствами, работала без сбоев, была эффективной и имела удобные интерфейсы, а техническая поддержка была качественной и надежной.
Главным стимулом для потребителей делать выбор в пользу специализированных СУБД, кроме их производительности, на мой взгляд, является нестабильность работы новых версий универсальных СУБД. Конкуренция, заставляющая производителей постоянно расширять функциональность и применимость СУБД к различным областям, делает код их продуктов все сложнее, что чревато появлением значительного количества багов даже там, где их ранее не было. По логике вещей надо бы зафиксировать текущую версию, направить главные усилия на ее стабилизацию и удаление допущенных ошибок, но гонка за лидерство на рынке вынуждает выпускать новые, сыроватые версии с расширенными возможностями. Неисправленные ошибки из текущей версии переходят в новую, их количество растет, отнимая массу сил на их учет, а тем временем выпускаются новые редакции "устаревших" версий.
Коды современных универсальных СУБД создавались в течение десятков лет разными людьми в разное время. Ядро иногда модифицировалось по сиюминутным конъюнктурным соображениям без детального продумывания общей концепции, в виде заплаток. В результате существующие сейчас коды настолько сложны и витиеваты, что усовершенствование продукта приводит к появлению новых ошибок, а средства, затрачиваемые на их обнаружение, не дают непосредственной коммерческой отдачи, поэтому производители не проявляют особой заинтересованности в этой деятельности. Старые, стабильные версии снимаются с поддержки, а на смену им приходят новые, над которыми еще предстоит много работы по устранению ошибок.
В то же время слишком большое количество ошибок ведет к подрыву репутации поставщика. Известно немало примеров, когда недовольство измученных разработчиков просачивается в прессу и поднимается на щит конкурентами, поэтому поставщик все же вынужден решать эту задачу, обычно заявляя, что ошибка будет исправлена в следующей версии, а сейчас для реализации нужной функциональности рекомендуется применить обходной путь (workaround), предоставленный технической поддержкой или найденный самостоятельно. В итоге разработчик получает, возможно, не самый эффективный, но более или менее решающий его проблему workaround. Однако все это превращает разрабатываемое приложение в странную конструкцию, содержащую нелогичный и непонятный код, полученный в результате обхода багов.
Наращивание функционала без проведения тщательной работы по устранению ошибок приводит к миграции ошибок в новые версии, что, в свою очередь, может привести к неконтролируемой и необратимой ситуации. Поэтому в известных словах Майкла Стоунбрейкера о неизбежной кончине универсальных СУБД есть доля истины. Весьма вероятно, что в отдаленном будущем выживут те универсальные СУБД, производители которых будут вкладывать серьезные средства в модернизацию и приведение в порядок кодов своих систем. К сожалению, пока ничего не слышно об усилиях производителей ведущих СУБД в этом направлении, хотя такие заявления серьезно подняли бы их рейтинг.
Обсуждение проблем, связанных с недостатками функционирования СУБД и тенденциями их развития, сегодня отошло на задворки ИТ-индустрии. Почему-то по умолчанию считается, что с СУБД все в порядке, и текущее состояние этой отрасли не изменится никогда. Это, на мой взгляд, объясняется двумя причинами. Во-первых, основное внимание направлено на разработку и внедрение новых технологий в других отраслях ИТ. Во-вторых, производители универсальных СУБД всеми силами сами поддерживают эту точку зрения. Однако, неверно считать, что все производители махнули рукой на проблему модернизации ядра. Например, Марк Таунсенд, вице-президент Oracle по разработке продуктов, отвечающий за направление СУБД, заявил: "Технология хранения данных по колонкам показывает очень хорошие результаты в применении к хранилищам данных. Мы намерены реализовать эту технологию в очередной версии своей СУБД, но это будет сделано в рамках существующего сервера и совершенно прозрачно для конечных пользователей и приложений… Главное достоинство "поколоночных" СУБД - это высокая степень сжатия данных".
Oracle реализует поколоночное хранение, за отсутствие которого Стоунбрейкер критикует универсальные СУБД. Поколоночное хранение будет реализовано Oracle "в одном флаконе"; к множеству других опций добавляется еще одна. Критики такое сочетание называют "перегруженностью средствами", однако звучит все это очень заманчиво - теперь пользователи смогут применять поколоночное хранение без модификации схемы данных путем их перемещения в другое место на диске, не прилагая к этому особых интеллектуальных усилий.
Среди обсуждаемых сегодня тенденций развития современных универсальных коммерческих СУБД особо хотелось бы отметить одну, которая с течением времени становится все более заметной, - использование технологий Google Reduce и MapReduce с целью распараллеливания обработки в базах данных и создания программ для распределенных вычислений на кластере. Хотя Майкл Стоунбрейкер и Дэвид Девитт осудили в блог-сообществе The Database Column использование MapReduce для хранения и обработки данных, эта технология может оказаться перспективной. Сейчас уже существуют несколько коммерчески доступных систем для аналитики (Hadoop, Greenplum и Aster Data), разработанных на ее основе, и, возможно, через несколько лет эта система будет настолько популярна, что ведущие поставщики СУБД включат ее в состав своих продуктов.