Сказки о СУБД

Введение

Часто, когда произносится термин «СУБД», под ним понимается только реляционная СУБД (здесь и далее по тексту будем считать термины синонимами) — это вызвано прежде всего тем, что большинство СУБД на рынке сейчас являются именно реляционными. Реляционная модель ориентирована на организацию данных в виде двумерных таблиц, а ее реализация опирается на работы Эдгара Кодда¹. Реляционная модель — это хорошо и плохо: хорошо в следствии простоты реализации, плохо с точки зрения работы с объектно-ориентированными языками программирования.

Сказка первая. «Объекты в БД»

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

Объект обладает состоянием, поведением и идентичностью; структура и поведение схожих объектов определяет общий для них класс; термины «экземпляр класса» и «объект» взаимозаменяемы [Буч]. Важнейшими свойствами в контексте взаимодействия с СУБД является состояние (совокупное значение атрибутов объекта) и идентичность. «Идентичность — это такое свойство объекта, которое отличает его от всех других объектов» [Khoshafian].

Хошафян и Коуплэнд отмечают следующее: «в большинстве языков программирования и управления базами данных для различения временных объектов их именуют, тем самым путая адресуемость и идентичность. Большинство баз данных различают постоянные объекты по ключевому атрибуту, тем самым смешивая идентичность и значение данных».

Ряд проблем, связанных с обработкой объектов в БД, были решены в объектно-ориентированных СУБД, например, в Cache². Использование таких СУБД пока не является повсеместным. Поэтому решение с использованием объектно-ориентированных СУБД в качестве основы для хранения данных следует считать скорее очередным «велосипедом», нежели промышленным стандартом.

Сказка вторая. «Бизнес-логика»

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

Чтобы не быть голословным, приведу основные доводы в пользу подхода «Все в базу»:

1. Безопасность. Считается, что значительно надежнее дать права на хранимую процедуру и защитить логику обработки данных, чем дать права на таблицы и затем пытаться реализовать сохранность данных с помощью триггеров.
2. Скорость. Выполнение хранимых процедур происходит в адресном пространстве СУБД, что означает близость к хранимым данным, что в свою очередь, уменьшает время реакции системы.
3. Специализация языков для разработки хранимых процедур. Такие языки «заточены» на работу с данными в БД, что опять же положительно сказывается на скорости работы ХП.
4. Локализация изменений. Изменение логики работы системы производится в единственном месте, и в большинстве случаев не требует перекомпиляции клиентского ПО и последующей его переинсталяции.
5. Минимизация трафика. Уменьшение объемов трафика связано с тем, что пользователю возвращается результат выполнения ХП, а не сырые данные.

Спорить с данными утверждения бессмысленно, так как они в основе своей истинны. Однако, если конкретизировать вопрос, а именно, нужно ли хранить бизнес-логику в БД при использовании трехзвенной архитектуры с выделением полноценного «сервера приложения»? Если для стартапа создание такой инфраструктуры не всегда оправданно, то для корпоративного применения практически нет альтернативных решений, — монстры индустрии, естественно, предлагают собственные решения для промежуточного слоя.

Исходя из вышесказанного, хочу напомнить одно из правил разработки приложений:

«Самое главное — это концентрация бизнес логики на одном уровне. А выбор уровня зависит от конкретной задачи.»
— Киселев Сергей, соучредитель и консультант по технологиям и разработке, ООО «Научно-производственная компания Ай-поинт рус».

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

«Если переносить логику приложения в БД, то привязываешь себя к конкретной БД, а что еще точнее и хуже, к конкретной версии СУБД. Теряется гибкость. В то же время, если мы понимаем, что такое кросс-платформенная реализация, то перенесение логики в рамках реализации куда бы то ни было не составляет никаких проблем. И как этим управлять вполне известно.»
— Виктор Гамов, ведущий программист, учебно-научный центр МИИТ-Эксперт.

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

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

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

«Всю бизнес-логику условно можно разделить на «две части». Одна часть — «обслуживание данных», вторая «реализация прикладной задачи». Первую логичнее держать в СУБД, рядом с данными, вторую — на сервере приложений. Под «обслуживание данных» я понимаю поддержку непротиворечивости данных с точки зрения прикладной задачи и функции типа собрать из первичных данных прикладные-расчетные.»
— Владимир Бормотов, системный админситратор, ЗАО «БиоХимМак».

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

Сказка третья. «Водопад подключений»

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

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

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

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

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

Описанный механизм позволяет осуществлять более эффективное управление мощностью системы. При использовании подхода общая производительность системы, выраженная в количестве обслуживаемых запросов за единицу времени, становится гораздо более предсказуемой, поскольку не уменьшается из-за нехватки памяти [Ch].

Заключение

Скорость разработки программного обеспечения, а не его качество, во многих компаниях является главным приоритетом и, хоть это и неправильно, от этого никуда не деться. Так как большинство работ связанны с хранением и обработкой данных в СУБД, то компании от собственных «велосипедов» приходят к проверенным ORM-фреймворкам.

ЛИТЕРАТУРА

[Буч] Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Издательства: Бином, Невский Диалект, 1998 г., 560 стр.
[Khoshafian] Khoshafian, S. and Copeland, G. November 1986. Object Identity. SIGPLAN Notices vol.21(ll).p.406.
[Fa] Фаулер М. Рефакторинг. Улучшение существующего кода / М. Фаулер — СПб.: Символ-Плюс, 2004. — 432 с.: ил.
[Ki] Кериевски Д. Рефакторинг с использованием шаблонов / М.: ООО «И.Д. Вильямс», 2006. — 400 с.: ил.
[Тейт] Тейт Б. Горький вкус Java: Библиотека программиста / СП.: Питер, 2003. — 333 с.
[Ch] Черноусов А.В. ИТ-инфраструктура системных исследований в энергетике и технологии ее реализации / Л.В Массель, А.В. Черноусов // Моделювання та iнформацiйнi технологiï — КИÏВ, 2006.

_________
¹ Эдгар Кодд (Edgar Codd) — британский ученый, основоположник теории реляционных баз данных. В 1970 издал работу «A Relational Model of Data for Large Shared Data Banks», которая считается первой работой по реляционной модели данных.
² Официальный сайт InterSystems Caché www.intersystems.com/cache
³ Рефакторинг или Реорганизация — процесс полного или частичного переписывания компьютерной программы или другого материала, с целью добиться улучшения читаемости кода и общей внутренней структуры компонентов, при полном и точном сохранении изначального смысла и поведения (кроме случаев, когда при рефакторинге устраняется ошибка — неправильное поведение) [Fa, Ki].
⁴ CMS — (Content Management System) — компьютерная программа или система, используемая для обеспечения и организации совместного процесса создания, редактирования и управления текстовых и мультимедиа документов (содержимое или контента). Обычно это содержимое рассматривается как неструктурированные данные предметной задачи в противоположность структурированным данным, обычно находящимися под управлением СУБД. В данном случае рассматриваются Web-ориентированные CMS начального уровня.