Сказки о СУБД

    Введение


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

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


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

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

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

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

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


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

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

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

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

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

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

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

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


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

    Если мы представим себе небольшой 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.

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

    Комментарии 18

      0
      Хорошее эссе. Точнее, зарисовки :) А за цитаты — отдельное спасибо, нечасто их в постах встретишь.

      Маленькая поправка:
      > если в час пик приходит неоправданно большое количество потребителей

      Я бы заменил «неоправданно» на «неожиданно». Перед кем вы собираетесь оправдываться за слишком большое количество посетителей сайта? :)) Пользователей именно ожидают — и иногда их приходит неожидано много :)
        0
        Да такие зарисовочки +)
        Просто копятся, а на статью по отдельности не тянут +)
        Решил чтобы не пропадали, оформить…

        За цитаты на самом деле спасибо тем,
        кто участвовал в дискуссии по вопросам СУБД и их места в ИС

        0
        Интересный вывод:

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

        К примеру, одна из крупнейших систем хранения, обработки и анализа данных построена на объектной базе компании Versant. Название системы — Echelon.

        Да и нашу базу тоже используют довольно широко — правда, имена клиентов публиковать не имеем права.

        Доля объектных баз на общем рынке пока мала, но это сравнимо с ситуацией с электромобилями. Гибридный Prius вполне популярен, а Tesla — чистый электромобиль — пока довольно дорогА, но показывает, что электрический автомобиль — не такой уж «велосипед».
          +1
          Мое мнение, что это не промышленный стандарт!
          Отдельные удачные реализации были есть и будут.
          Их будут использовать и продвигать.

          Я верю,
          что рано или поздно объектно-ориентированные СУБД станут основой для многих ИС,
          а может и для большинства.
          0
          Отдельное спасибо за цитаты (шутку понял и оценил:))

          А если по существу, то рекомендую всем интересующимся темой хранения данных почитать статью: Изменяемое состояние: опасности и борьба с ними — fprog.ru/2009/issue1/eugene-kirpichev-fighting-mutable-state/
            0
            >> собственные решения для промежуточного слоя
            Имееся в виду middleware?

            По поводу разделения логики на две части — для небольших и не склонных к расширению проектов имеет смысл воспользоваться возможностью написания и развертывания в СУБД бизнес-логики не на SQL-скриптах, а на прикладном языке, который позволяет эта СУБД (для MsSQL это языки CLR, для PostgreSQL — perl, для Oracle — Java). Тогда не понадобятся простыни SQL, задачу можно решать наиболее эффективно, а БД выполняет роль и сервера приложений.

            Я за продолжение «сказок»-заметок :)
              0
              Конечно middleware

              Такой вариант часто рассматривается и реализуется и имеет право на жизнь,
              но мне он видится как вариант, выбранный от бедности: или разработчики экономят или заказчики.

              Их у меня еще есть +)
                0
                >> как вариант, выбранный от бедности
                Да не. Например, сертификация по классу безопасности предусматривает Kerberos + изоляцию за слоем хранимок/вью. С точки зрения поддержки в таком случае лучше не связываться с SQL вообще )
                Или бизнес-логики не так много, чтобы выносить ее на отдельный сервер приложений. Или существующая система — двухзвенка, а доступ к данным решено переделать на более интеллектуальный.

                Будем ждать =)
                  0
                  P.S. Вы на java пишете, так?
                    0
                    Предпочитаю +)
                      0
                      Так и подумал, особенно после того, как упомянули про Connection Pool (ну и middleware слегка). «Клятый» майкрософт для .net реализовал все коннекшены с автопулингом (настраивается через ConnectionString), так что у .net программистов такая мысль просто не возникает :)
                        0
                        Дело в том, что чистыми пулами уже давно не пользуются.
                        Все обычно спрятано в датасорсы и JDBC драйвера,
                        которые используют паттерн прокси,
                        для слежения за закрытием и обеспечением не закрытия злосчастных подключений.

                        Ну и конечно клятые ORM-фреймворки +)
                0
                Давненько упоминаний про Intersystems Cache не видел. На хабре — похоже первое. Замечательная СУБД. Замечательная статья.
                  0
                  ну почему же первое — я упоминал multik.habrahabr.ru/blog/59380/ и то не уверен что моё было первым
                  0
                  Раз уж вспомнили про каше — необходимо было вспомнить и про прямой доступ к данным — то есть к глобалам (деревьям) потому как каше поддерживает три механизма доступа к данным объектный реляционный и прямой. Прямой доступ может показаться на первом этапе более сложным — но зато он более мощный, можете посмотреть пример am.ua проекта с использованием прямого доступа к каше.

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

                  Касательно проблемы размещения бизнес-логики — автор попал в самую суть — здесь действительно чувствуешь себя как на минном поле, и за каждый свой шаг — потом, по мере развития проекта, придётся отвечать (как минимум перед самим собой).

                  В целом очень грамотная статья — видимо автор сталкивался с полным перечнем проблем описанных в статье «лицом к лицу».
                    0
                    спасибо +) за позитивный отклик

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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое