В последние несколько месяцев на сайтах CITForum.ru и CitCity.ru в моих переводах или пересказах было опубликовано четыре материала, связанных с именем Майкла Стоунбрейкера: «Беседа Марго Зельцер с Майклом Стоунбрейкером», «"Один размер пригоден для всех": идея, время которой пришло и ушло», «Пригоден ли один размер для всех? Часть 2: результаты тестовых испытаний», «Конец архитектурной эпохи, или Наступило время полностью переписывать системы управления данными». К этим материалам примыкает и статья Марго Зельцер «За пределами реляционных баз данных: доступ к базам данных не ограничивается возможностями SQL». Вопреки обыкновению, я не сопроводил ряд этих публикаций своими предисловиями. Это было сделано сознательно, поскольку мне хотелось написать некоторый общий текст после публикации хронологически последней статьи Стоунбрейкера и др.

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

1. Кризис назрел?

В области управления данными явно прослеживаются элементы кризиса. Некоторые признаки этого кризиса проявляются в следующем:

• Львиная доля мирового рынка управления данными занята продуктами трех ведущих компаний-поставщиков технологии СУБД: Oracle, IBM и Microsoft. Системы управления базами данных (СУБД), поставляемые этими компаниями, с каждым новым выпуском становятся все объемнее. В них появляются все новые и новые возможности, и, похоже, что полный набор возможностей этих СУБД уже неизвестен не только их пользователям, но и рядовым системным разработчикам.

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

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

• Все менее понятно, что такое язык SQL. В существующем стандарте SQL:2003 можно выделить модельный слой, действительно определяющий общие черты СУБД основных поставщиков (см., например, мою статью «Объектно-реляционные базы данных: прошедший этап или недооцененные возможности?»). Но в этом стандарте содержится множество спецификаций, выходящих за пределы этого модельного слоя (например, средства OLAP, XML и т.д.). Я не знаю ни одного человека, который мог бы с уверенностью сказать, что он знает современный SQL полностью. Нет и, видимо, никогда не будет ни одной системы, в который был бы полностью реализован стандарт языка SQL.

  Часто приходится слышать (особенно от представителей компаний, производящих SQL-ориентированные СУБД «второго эшелона»), что для них стандарт SQL – это некоторый ориентир. Они стремятся двигаться в нужном направлении, считая, что это направление указывается именно этим стандартом. Но стандарт SQL сегодня настолько велик и многообразен, что в каком бы направлении не развивалась некоторая СУБД, почти всегда можно найти некоторую черту SQL, которую можно было бы считать путеводной звездой.

  В 1990-м г. в «Манифесте систем баз данных третьего поколения» говорилось, что SQL стал «межгалактическим» языком общения. Похоже, что с того времени возможности использования SQL для общения резко уменьшились.

2. Что делать и с чего начать?

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

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

Совсем по-другому отвечает на этот вопрос Майкл Стоунбрейкер. Мое понимание его позиции состоит в следующем (сразу замечу, что сам Стоубрейкер в таком виде свою позицию никогда не излагал):

• Архитектура современных SQL-ориентированных СУБД появилась более 30 лет тому назад, когда рынок систем управления данными был единым, не фрагментированным на специализированные секторы. Поэтому СУБД вынужденно делались «безразмерными», пригодными для использования в любой области приложений баз данных. Эта «безразмерность» присутствует сегодня в продуктах основных поставщиков (и в универсальных СУБД «второго эшелона»). Плюсами основных SQL-ориентированных СУБД является надежность и общая высокая производительность. Минусы – сложность, объемность и высокие накладные расходы, свойственные универсальности.
• За прошедшие 30 с лишним лет рынок систем управления данными сильно фрагментировался. Стали известными большие секторы рынка, для которых очень существенна высокая производительность приложений, которая не достигается или достигается с недопустимо большими затратами при использовании «безразмерных» СУБД. Другими словами, экономически целесообразной стала разработка специализированных систем, которые ориентируются на эффективную поддержку заранее известных сценариев использования.
• За эти же тридцать лет в области управления данными была выполнена громадная исследовательская работа, результаты которой можно успешно применять для разработки специализированных систем.
• В связи с быстро меняющимися требованиями рынка успешными могут быть только такие новые продукты, которые можно вывести на рынок достаточно быстро – через год или два после начала разработки. Это еще один довод в пользу специализированных систем, нацеленных на решение узкого класса задач. В таких систем требуются более простые языковые средства, упрощается оптимизация запросов и другие аспекты, являющиеся традиционным камнем преткновения «безразмерных» систем.

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

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

Наконец, теперь Стоунбрейкер полностью выходит на тропу войны с «безразмерными» СУБД, покушаясь на их основной, традиционный сектор рынка – OLTP. В исключительно интересном, пока еще университетском проекте H-Store приводятся результаты испытаний этой системы на эталонном тестовом наборе TPC-C, демонстрирующие превосходство над «безразмерной» коммерческой СУБД почти на два порядка.

Кроме того, в статье «Пригоден ли один размер для всех? Часть 2: результаты тестовых испытаний» приводится краткая характеристика и показатели производительности экспериментальной системы ASAP, ориентированной на поддержку математических баз данных. Результаты тоже впечатляют, хотя опубликованных данных относительно общей организации и интерфейсов системы явно недостаточно, чтобы можно было хорошо понять принципы ее организации.

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

3. Сомнения и размышления

Начну этот раздел с обсуждения одного общего вопроса: хотят ли новой революции пользователи и разработчики приложений? В уже упоминавшемся Манифесте, одним из основных авторов которого был Стоунбрейкер, звучала мысль о том, что 20-му веку не нужна еще одна революция. Тогда это говорилось в связи с попытками передела мира баз данных сообществом объектно-ориентированных баз данных. Как видно, этот передел не состоялся, и объектно-ориентированные базы данных заняли периферийную позицию на рынке управления данными.

Конечно, теперь мы живем уже в 21-ом веке, в котором, к счастью, революций пока еще не было. Но почему Стоунбрейкер считает, что народ с нетерпением их ждет? Мне кажется, что к настоящему времени накоплено так много технологических возможностей, как аппаратных, так и программных, что большинство пользователей и разработчиков предпочтет потратить больше средств и/или пожертвовать некоторой долей производительности, чем перейти к использованию радикально других программных средств. Наверное, это будет и дальше тормозить прогресс, но зато сохранит общественное спокойствие.

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

Теперь немного поговорим о технической стороне проблемы. Начну с СУБД Vertica. В описываемых в статье «Пригоден ли один размер для всех? Часть 2: результаты тестовых испытаний» результатах испытаний Vertica побеждает традиционную СУБД на агрегатных запросах, в которых используется малая доля столбцов очень «широкой» таблицы. Заметим, что речь идет о приложениях категории OLAP, в которых принципиально участвуют непредвиденные («ad hoc») запросы аналитиков. В частности, в этих приложениях могут запрашиваться не только агрегатные, но и «атомарные» данные. Но при этом хорошо известно, что в СУБД с хранением данных по столбцам операция извлечения строк таблицы является очень дорогостоящей. Так что нужно еще разобраться, до каких пределов Vertica будет побеждать СУБД с хранением данных по строкам. Здесь все не так очевидно.

Что касается преимуществ H-Store в приложениях OLTP, то, конечно, очень впечатляют примеры классов транзакций, для которых свойства ACID обеспечиваются автоматически, без накладных расходов на управление транзакциями. Очень радуют возможности достижения высокого уровня доступности за счет репликации данных. Однако рассмотрим более внимательно, за счет чего на основе H-Store удалось добиться таких высоких показателей на тестовом наборе TPC-C.

1. Приведение классов транзакций TPC-C к форме, в которой для сериализации не требуются средства управления транзакциями. Не знаю, сколько времени это заняло у авторов статьи, но задача эта явно не тривиальна, поскольку для ее решения потребовалось специальным образом разделять и реплицировать базу данных. Конечно, авторы говорят, что в будущем у них должны появиться специальные инструменты, автоматизирующие этот процесс, но, насколько я понимаю, подходы к созданию таких инструментов очень туманны. Для транзакций, не обладающих специальными свойствами, преимущества H-Store не оценивались.
2. Отсутствие сетевых взаимодействий между приложением и СУБД за счет использования для разработки приложения механизма хранимых процедур. Более того, хранимая процедура в среде H-Store выполняется в том же адресном пространстве, что и СУБД. Другими словами, фактически мы имеем дело с СУБД, встроенной в приложение. И здесь возникают сразу два сомнения.

   Во-первых, какой механизм разработки приложений, в конце концов, будет предложен пользователям? Пока, насколько я понимаю, в среде H-Store нет никакого механизма разработки приложений (используется программирование на языке C++ на том же уровне, что и программирование самой СУБД). Как отмечают авторы в конце статьи, они планируют использовать средства Ruby-on-Rails. Но будут ли счастливы разработчики приложений, если их всех, вне зависимости от пристрастий, заставят использовать Ruby-on-Rails?

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

На этом я закончу свою заметку, поскольку иначе она может стать объемнее основных статей, предлагаемых вашему вниманию, хотя я затронул только часть своих сомнений. В заключение хочу пожелать вам полезного и приятного чтения.

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

Итак, предлагаемая подборка переводов и пересказов включает следующее:

«Беседа Марго Зельцер с Майклом Стоунбрейкером»

«За пределами реляционных баз данных: доступ к базам данных не ограничивается возможностями SQL»

«"Один размер пригоден для всех": идея, время которой пришло и ушло»

«Пригоден ли один размер для всех? Часть 2: результаты тестовых испытаний»

«Конец архитектурной эпохи или Наступило время полностью переписывать системы управления данными»