Реляционные СУБД появляются в 1970-х года. Данные хранят в виде таблиц и взаимосвязей между ними. Для того, чтобы наполнять такую систему данными, требуется предварительно создать структуру (схему) БД, а для манипуляций с данными используется язык структурных запросов Structured Query Language (SQL).
Преимуществом реляционных СУБД является:
- зрелость,
- надежность,
- транзакционная семантика и возможность поддержки сложных запросов.
Основными недостатками —
- масштабирование (они просто не задумывались для масштабирования, хотя реляционные системы с горизонтальным масштабированием постепенно развиваются)
- и гибкость (так как используется предварительно сформированная схема БД).
Следовательно, реляционные СУБД плохо предназначены для работы с большими объемами неструктурированных или слабоструктурированных данных, где разработчикам требуется гибкость в модификации структуры БД в соответствии с изменяющимися требованиями бизнеса.
Реляционные СУБД используют в стандартных приложениях, таких как ERP, CRM, системы e-commerce и другие.
Нереляционные СУБД. Изначально разрабатывались для поддержки больших наборов неструктурированных, слабоструктурированных и распределенных данных. Нереляционные СУБД не требуют предопределенной схемы БД из-за своей структуры метаданных, т.к. формат данных инкапсулируется в данные, а не предопределяется извне. Это позволяет пользователю помещать произвольные данные в базу данных и добавлять атрибуты на лету.
Поскольку в таких СУБД кроме SQL используются другие языки управления данными, их называют NoSQL или not-only-SQL, или non-SQL. Существует несколько типов нереляционных СУБД, определяемых тем, как организованы или представлены их данные:
- документоориентированные,
- графовые,
- ключ-значение,
- колоночные,
- временных рядов и др.
Наблюдается и движение в сторону мультимодельных баз данных, которые включают в себя несколько режимов представления данных.
Ключевыми преимуществами нереляционных СУБД являются
- простота использования,
- гибкость,
- горизонтальное масштабирование для размещения огромных объемов данных с ограниченным компромиссом производительности (в таких системах используется распределенная архитектура, не требующая совместного использования).
Нереляционные СУБД популярны среди разработчиков приложений, которые хотят быстро предоставлять нужные и быстро работающие функциональные возможности (часто в облаке) и не желают тратить время на проработку жестких схем БД.
Основными недостатками нереляционных СУБД являются
- отсутствие гарантий транзакций,
- ограниченные возможности (например, вызывает сложность объединение нескольких таблиц в одном запросе)
- относительная незрелость по сравнению с реляционными.
Большинство нереляционных СУБД не обеспечивают гарантированную согласованность и надежность транзакций, известную как ACID, присущие реляционной БД. Но, справедливости ради, стоит отметить, что некоторые разработчики стараются реализовать ACID.
Распространенные варианты использования нереляционных СУБД включают веб-приложения, IoT и мобильные приложения, DevOps, социальные сети, корзины покупок и механизмы рекомендаций.
На рисунке ниже представлены реляционные и нереляционные с логотипами известных продуктов.
На сайте DB-Engines.com можно посмотреть, в каком соотношении представлены на рынке различные системы управления базами данных:
Почему мы всё же взялись разрабатывать реляционную СУБД:
- У нас есть огромная экспертиза в области разработки реляционных СУБД.
- Реляционные СУБД занимают более 70% рынка обработки данных и будет занимать значительную долю очень продолжительное время.
- Наши исследования и разработки показывают, что реляционные СУБД ещё не скоро исчерпают свой потенциал.