Классика баз данных - статьи

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


Начну этот раздел с обсуждения одного общего вопроса: хотят ли новой революции пользователи и разработчики приложений? В уже упоминавшемся Манифесте, одним из основных авторов которого был Стоунбрейкер, звучала мысль о том, что 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: результаты тестовых испытаний»

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



Содержание раздела