На протяжении долгого времени доминировали реляционные СУБД. Сам по себе реляционный подход оказался простым и удобным, что обеспечило его распространение среди разработчиков, а производители смогли выпустить зрелые продукты, пригодные для широкого использования: Oracle Database Server, IBM DB2, Microsoft SQL Server, Teradata, PostgreSQL, MySQL и MariaDB. Возможности реляционных СУБД полностью соответствовали требованиям приложений того времени, однако появление информационных хранилищ и многомерного анализа данных разделило прикладные информационные системы на OLTP и OLAP, а для нужд последних появились специализированные СУБД, хотя и соответствующие идеологии реляционного подхода, но на уровне реализации имеющие существенные отличия: секционирование, поколоночное хранение, сжатие данных и т. д. Дальнейшее развитие технологий баз данных было стимулировано появлением принципиально новых прикладных задач, связанных с высоконагруженными системами, Большими Данными, потоковой аналитикой, социальными сетями и проч. Каждый новый класс задач требовал принципиально новых СУБД, и реляционные системы оказались неприменимы — излишняя функциональность и универсальность привели к слишком академичной архитектуре, плохо адаптируемой под требования конкретных приложений [1]. В новых СУБД уже на уровне архитектуры не было универсальности реляционного подхода SQL, богатого функционала, обязательной поддержки ACID и др. К сегодняшнему дню появилось большое количество различных систем класса NoSQL [2], способных решать самые разнообразные задачи, но и реляционные системы впитали в себя идеи NoSQL, породив системы NewSQL [3], сочетающие в себе достоинства реляционного и нереляционного подходов.

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

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

Выбор СУБД как процесс

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

Пример сравнения связанных, но не сопоставимых критериев — оценка скорости работы двух СУБД. На первый взгляд, все просто: на различных нагрузках выполняется тестовый прогон, а затем на основе полученных результатов принимается окончательное решение [4]. Но как быть, если при одной нагрузке выигрывает одна система, а при другой — другая. Выбор осложняется, когда одна из систем работает медленнее, но зато лучше масштабируется, требуя меньше ресурсов.

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

СУБД следует рассматривать не только как составную часть прикладной системы, но и как инструмент разработчика, и тут появляются такие критерии сравнения, как простота, удобство, понятность, предсказуемость и т. д., которые, однако, нельзя однозначно оценить формально. Единственное, что можно добавить, — это связь удобства использования системы и ее распространенности. Как правило, в Интернете присутствует масса материалов по широко распространенным СУБД, что облегчает работу программистов при решении каких-либо проблем. Однако продукты Open Source — это не универсальная панацея, поскольку наличие исходного кода само по себе не гарантирует ни удобства использования, ни предсказуемости поведения системы. Еще один довод в пользу Open Source — наличие сообщества, но ни одно сообщество не дает стопроцентной гарантии оперативной технической поддержки, особенно в случаях критически важных приложений (управление производством, банковский сектор и т. п.).

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

СУБД как часть проекта

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

Таблица 1. Примеры СУБД, созданных как результат прикладных проектов
Таблица 1. Примеры СУБД, созданных как результат прикладных проектов

 

Трудно предложить однозначные критерии в пользу принятия решения о необходимости создания новой специализированной СУБД под нужды конкретного проекта, тем не менее можно привести аргументы «за» и «против» (см. табл. 2).

Таблица 2. Создавать или нет новую СУБД?
Таблица 2. Создавать или нет новую СУБД?

 

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

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

Некоторые современные СУБД (например, Vertica и VoltDB) стали результатом исследовательских проектов, в рамках которых был создан прототип будущей системы (C-Store — прототип Vertica, H-Store — прототип VoltDB), проверенный затем на реальных практических задачах. Однако для массового создания новых СУБД такой путь невозможен: далеко не каждая компания готова финансировать подобные исследовательские проекты.

Иррациональный мир современных СУБД

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

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

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

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

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

 

Там, где бессильны универсальные СУБД

Примеры приложений, для которых требуется разработка специализированных СУБД:

  • средства контроля видеопотока и автоматического мониторинга рекламных роликов;
  • системы легковесной аналитики, выполняющие аналитические задачи без задействования дорогостоящих аппаратных решений;
  • распределенные банки знаний из сложных предметных областей;
  • системы индексации и поиска геопространственных данных.

 

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

***

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

Литература

  1. M. Stonebraker. «One Size Fits All»: An Idea Whose Time Has Come and Gone. URL: http://dl.acm.org/citation.cfm?id=1054024 (дата обращения: 18.09.2017).
  2. Венкат Гудивада, Дана Рао, Виджай Рагхаван. Ренессанс СУБД: проблема выбора // Открытые системы.СУБД. — 2016. — №3. — С. 12–17. URL: https://www.osp.ru/os/2016/03/13050249 (дата обращения: 18.09.2017).
  3. M. Stonebraker. New SQL: An Alternative to NoSQL and Old SQL for New OLTP Apps. URL: https://cacm.acm.org/blogs/blog-cacm/109710-new-sql-an-alternative-to-nosql-and-old-sql-for-new-oltp-apps/fulltext (дата обращения: 18.09.2017).
  4. Андрей Николаенко. Эталонные тесты СУБД: что было, что стало, что будет // Открытые системы.СУБД. — 2017. — №2. — С. 35–39. URL: https://www.osp.ru/os/2017/02/13052225 (дата обращения: 10.09.2017).

Константин Селезнев (konstantin_seleznyov@relex.ru) — ведущий инженер-программист, группа компаний «РЕЛЭКС» (Воронеж).

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF