SQL и NoSQL: инь и ян в мире баз данных
2026-02-21 17:33 Diff
https://skillbox.ru/media/code/sql_i_nosql_in_i_yan_v_mire_baz_dannykh/

#статьи

  • 23 апр 2021
  • 0

SQL или NoSQL — вот в чём вопрос. Чем они различаются? Это конкуренты или сотрудники? Что о них спрашивают на собеседовании?

Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.

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

В одной статье мы не сможем глубоко погрузиться в эту тему — материал слишком объёмный. Поэтому просто дадим начальные знания или освежим прежние.

Поговорим про основные типы баз данных, их достоинства и недостатки. А отталкиваться будем от реляционных баз, поэтому их рассмотрим чуть подробнее.

Это такие базы, в основе которых лежит реляционная модель.

Реляционную модель данных придумал Эдгар Кодд ещё в семидесятых годах прошлого века.

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

Кодд доказал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, который в математике называется отношением (relation) — отсюда и слово «реляционная» в переводе названия.

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

А ещё Эдгар Кодд дал жизнь языку SQL.

Отношение — это двумерная таблица с уникальным именем. Она состоит из строк (записей) и столбцов (атрибутов).

Каждая строка таблицы представляет некоторый объект реального мира (экземпляр сущности) или соотношения между объектами.

Столбцы — это атрибуты сущности, для сущности каждого типа они свои.

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

Разберём устройство реляционной БД подробнее на примере. Позже это поможет нам понимать и сравнивать базы разных типов.

Допустим, у нас есть база данных, в которой всего одна таблица — Messages. В ней хранится информация о телефонных разговорах клиентов и операторов компании по ремонту техники.

Каждая строка этой таблицы содержит данные о звонке клиента по его проблеме и ответ оператора, а также дату обращения.

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

Messages

clientclient_phoneoperatoroperator_phonequestionanswerdateВася8 (902) 111-11-11Оператор 18 (800) 111-11-11Когда принтер готов будет?!Готов, забирайте.10.02.2021Лера8 (910) 222-22-22Оператор 18 (800) 111-11-11На планшете стекло поменяете?Конечно, приносите.10.02.2021Вася8 (902) 111-11-11Оператор 28 (800) 222-22-22Принтер не работает ваще!!!Приносите, посмотрим.20.02.2021

А теперь представьте, что записей в такой таблице десятки тысяч. И возникает такая ситуация: в компанию звонит самый любимый клиент и говорит, что сменил номер телефона. А нерешённых вопросов по этому клиенту в базе, скажем, сотня. Значит, придётся заменить номер телефона на новый по крайней мере в 100 записях, то есть внести изменения сразу во много строк таблицы Messages.

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

О подобном заботятся ещё на этапе проектирования базы, а предотвращают это путём нормализации отношений.

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

Избыточность данных — это когда одни и те же данные хранятся в базе сразу в нескольких местах.

Каждая строка таблицы Messages содержит имя клиента и никнейм оператора, а также их телефоны. Причём в 1-й и 3-й строках мы видим звонки от одного и того же клиента, а в 1-й и во 2-й — ответы одного и того же менеджера. То есть в 1-й и 3-й строках дублируются имя и телефон клиента — Васи, а в 1-й и 2-й — никнейм менеджера «Оператор1».

Чтобы избавиться от дублирования информации, выделим сущности Клиент и Оператор. И вынесем специфичные для каждой атрибуты в отдельные таблицы.

В первой (Clients) будут храниться имена и телефоны клиентов, а во второй (Operators) — операторов. Кроме того, каждой записи в этих таблицах мы присвоим атрибут id — так называемый первичный ключ (его значение уникально, то есть не может повторяться в пределах таблицы). С его помощью мы установим связь с записями таблицы Messages.

Для этого к каждой записи в Messages (напомним, она всё ещё представляет сущность «звонок») добавим два новых атрибута (внешних ключа): id_client и id_oper. Они будут ссылаться на первичные ключи из таблиц Clients и Operators соответственно. Столбцы с именами и телефонами из таблицы Messages уберём.

И вот что получим:

В такой базе, чтобы поменять телефон клиента сразу для всех записей, достаточно изменить всего одно поле в таблице Clients.

Всего существует шесть форм нормализации реляционных баз данных — в порядке уменьшения избыточности отношений. Все они описаны формальными правилами. Наше отношение мы привели ко второй нормальной форме.

Данные в таблицах не лежат мёртвым грузом — с ними работают системы управления базами данных (СУБД).

С их помощью создают базы (метасхемы), заполняют их данными и проводят операции над всем этим: добавляют, удаляют, меняют структуру, анализируют и так далее.

Основное средство для общения с реляционными базами данных — язык структурированных запросов SQL.

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

Например, чтобы выбрать все данные из таблицы Messages за 10.11.2020, делается запрос:

SELECT * FROM messages WHERE date = ‘10.11.2020’

Язык структурированных запросов делится на несколько частей (группы операторов) и позволяет:

  • определять данные (DDL),
  • манипулировать ими (DML),
  • контролировать доступ к данным (DCL)
  • и управлять транзакциями (TCL).

В SQL изначально нет средств для создания печатных отчётов, экранных форм и других инструментов для разработки программ. Хотя SQL сам по себе не является полноценным (Тьюринг-полным) языком программирования, но его стандарт позволяет создавать процедурные расширения. Они доводят его функциональность до полноценного языка программирования.

При этом синтаксис SQL в разных СУБД может различаться. Кое-где даже используются его отдельные диалекты, например:

  • T-SQL — для работы с Microsoft SQL Server;
  • на PL / SQL пишут хранимые процедуры и функции в Oracle;
  • на PL / pgSQL — в PostgreSQL.

Это такие базы, в которые включены средства работы с объектными типами данных. А возникли они в связи с развитием объектно-ориентированных языков программирования.

В структуре таких баз и языке запросов используются классы, объекты, наследование. В этом направлении развиваются, например, Oracle и PostgreSQL.

Это открытая СУБД, купленная Oracle в придачу к Sun Microsystems. С ней работают более половины (55,6%) всех разработчиков (по результатам опроса, который в 2020 году провёл сайт StackOverflow.com среди 65 тысяч респондентов).

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

MySQL пользуется мощной поддержкой у создателей языков программирования: практически во всех популярных языках есть интерфейс для работы с ней.

Эта СУБД использует большую часть стандартного языка SQL.

Главное преимущество SQlight — встраиваемость. Это объясняется тем, что SQlight не приложение типа «клиент-сервер» (в отличие от других реляционных СУБД), а библиотека, которую подключают непосредственно к программе.

И она тоже весьма популярна: достаточно сказать, что SQLite есть в каждом смартфоне. Например, в смартфонах на Android там хранятся контакты и медиа, а в iOS её используют многие приложения.

Её можно назвать самой продвинутой. Это не просто реляционная, а объектно-реляционная свободная СУБД.

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

Реляционные СУБД просты, удобны и предсказуемы. А их рынок один из самых консервативных в IT-отрасли. Поэтому даже при появлении множества NoSQL реляционные базы остаются самым востребованным инструментом в очень разных отраслях.

По данным DB-Engines за февраль 2021 года, мировая доля реляционных СУБД составляет 74% от всех:

Однако реляционные БД не лишены недостатков.

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

Поэтому растущую базу приходится помещать на более мощный и дорогой сервер, то есть масштабировать вертикально.

Но возможности даже самой мощной машины ограничены, поэтому реляционные базы плохо приспособлены для хранения действительно больших данных.

Из-за нормализации реляционная база данных имеет сложную структуру. А скорость обработки запроса зависит от числа таблиц, к которым запрос обращается.

Представьте себе, что таблиц 100, 200, 1000, — СУБД будет работать медленно, а код запроса будет очень громоздким.

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

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

И вот, в начале 2000-х появились нереляционные базы. Помимо решения новых задач, их разработчики сделали упор на исправление главных недостатков реляционных баз — проблем с гибкостью, низкой производительностью и масштабируемостью.

В NoSQL нет таких понятий, как строки, столбцы, таблицы и их соединения. Данные в нереляционных базах хранятся как объекты с произвольными атрибутами: это могут быть пары «ключ-значение», документы в формате JSON, графы и так далее.

Базы NoSQL делятся на четыре основные категории (в зависимости от решаемых с их помощью задач).

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

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

Например:

keyvalueuser1{Кузнецов В., отдел маркетинга}user2{name:Лена, position:секретарь}user3{ООО «Вектор»}user4{Трофимова Таня, отд.2, дизайнер}user5{Галина Николаевна, гл. бух.}user6{65,84,236}

Базы «ключ-значение» часто используют для кэширования данных и организации очередей.

Их достоинства — быстрый поиск и простое масштабирование.

Их недостаток — нельзя производить операции со значениями. Например — сортировать их или анализировать.

Базы «ключ-значение» применяют в поисковой системе Google, «Википедии», «Фейсбуке*», интернет-магазине Amazon.

Одна из самых популярных — Redis. Её используют Uber, Slack, Stack Overflow, сайты гостиниц и туристические, социальная сеть Twitter.

В таких данные хранятся в виде иерархических структур (документов) с произвольным набором полей и их значений. Документы объединяются в коллекции.

Если провести аналогию с реляционными СУБД, то коллекциям соответствуют таблицы, а документам — строки в них.

Например, фрагмент документа с информацией о фильмах:

[ { "year" : 2020, "title" : "Душа!", "produced" : "Pixar Animation Studios", "directors" : [ "Пит Доктер", " Кемп Пауэрс"], "tagline" : "Everybody has a soul. Joe Gardner is about to find his", "rating" : 8.3, "genres" : ["Мультфильм", "Комедия"] }, { "year": 2020, "title": "Ход королевы", "created" : "Allan Scott", "book" : "Уолтер Тевис", "actors" : ["Аня Тейлор-Джой", "Мариэль Хеллер", "Моусес Ингрэм"], "rating" : 8.4, "genres" : ["Драма", "Спорт"] }, { "year": 1972, "title": "Зита и Гита", "рroduced" : "Sippy Films", "actors" : ["Хема Малини", "Санджив Кумар"], "genres" : ["Драма", “Мюзикл”, "Мелодрама"] } ]

Документоориентированные базы используют в системах управления содержимым (CMS) — для хранения каталогов и пользовательских профилей.

Одна из самых популярных — MongoDB (там можно создавать процедуры на JavaScript).

Эти базы отличаются от реляционных лишь способом хранения данных на накопителе.

Если реляционная база создаёт для каждой таблицы по файлу, то в колоночной отдельный файл создаётся для каждого столбца таблицы.

Например, если реляционная таблица выглядит так:

namecolorpropertyволксерыйзубастыйкозабелаярогатаякапустазелёная

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

Что это даёт? Представьте, что вам нужны только названия объектов, а их свойства вас не интересуют.

При выполнении запроса в реляционной таблице просматривается каждая запись и из неё выбираются нужные данные. В колоночной базе с диска будет считана только одна колонка с названиями. Это сокращает время выполнения запроса, причём намного.

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

Одна из самых популярных СУБД такого типа — Apache Cassandra.

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

Вершины (или узлы графа) — это объекты (сущности), а рёбра графа — взаимосвязи между ними.

Например, информация о друзьях в социальных сетях просто идеальна для представления в виде графа:

Графовые базы применяют в социальных сетях, сервисах рекомендаций, системах выявления мошенничества и им подобных.

Одна из популярнейших графовых СУБД с открытым кодом и собственным языком запросов — это Neo4j.

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

* Решением суда запрещена «деятельность компании Meta Platforms Inc. по реализации продуктов — социальных сетей Facebook и Instagram на территории Российской Федерации по основаниям осуществления экстремистской деятельности.

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу