SQL или NoSQL — что выбрать, если нужна база данных

Статью подготовила хостинговая команда UltaHost. Наши партнеры предлагают аренду виртуальных и выделенных серверов, услуги хостинга с ispmanager.

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

Возможно, одной СУБД действительно достаточно. А, может, жизнь станет легче, если добавить еще одну или вовсе поменять.

В этой статье расскажем о двух популярных группах БД с разными подходами к хранению данных — SQL и NoSQL. Разберемся, под какие задачи они подходят.

Представьте, что вы делаете онлайн-магазин с доставкой товаров.

Веб-приложение оперирует связанными объектами:

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

В нашем примере с онлайн-магазином объектом будут «товары», а атрибутами для товаров будут «Название», «Тип», «Страна производства», «Срок годности», «Вес». Базы данных из таблиц, где строки соответствуют объектам, а столбцы описывают атрибуты объектов, называют реляционными.

Современные реляционные базы данных позволяют работать с такими табличками графически, но «под капотом» и в сценариях автоматизации используется специальный язык запросов к базе данных — SQL.

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

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

SELECT order_date, COUNT(order_id)
FROM orders
GROUP BY order_date
ORDER BY order_date DESC
LIMIT 20

Вот что есть в этом запросе:
— информация о заказах из таблицы orders по дням order_date,
— подсчитано общее число заказов в каждую дату,
— последние 20 записей выводятся в обратном хронологическом порядке (DESC).

Так с помощью запроса на SQL мы только описываем, что хотим получить. Как это эффективно сделать, решает СУБД.

ORM. Декларативный стиль языка SQL выглядит непривычно для начинающих программистов. Но есть хорошая новость: в большинстве популярных языков программирования реализована концепция object — relational mapping, сокращённо ORM.

Специальные библиотеки подменяют SQL-операции конструкциями, которые свойственны привычному языку программирования. Так, в мире Python роль ORM выполняет SQLAlchemy, а на Node. js используют Sequelize. В результате всю логику обработки запросов к базам данных можно хранить внутри исходного кода программы.

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

Вот примеры популярных реляционных баз данных:

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

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

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

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

Разберем пару наиболее популярных решения NoSQL:

Документоориентированные базы данных предполагают, что одной сущности могут соответствовать объекты с разной структурой. Здесь подойдет наш пример с веб-игрой.

Структуру данных в такой задаче описывают в виде документа — JSON-подобной структуры с ключами и значениями. При этом у объектов одной сущности могут быть разные наборы атрибутов.

Вот пара популярных документоориентированных СУБД:

Базы данных типа «ключ — значение». Полезны, когда не так уж нужна сложная структура объекта, а важнее побыстрее достать из памяти нужный объект.

Например, сервис предсказания погоды. Сайт хранит информацию обо всех предыдущих показаниях, но самая часто запрашиваемая пользователями информация — погода сегодня и предсказание на завтра. Эту информацию лучше хранить и обновлять непосредственно в памяти сервера. А на странице текущей погоды сопоставлять «ключ» — географическую локацию и «значение» — температуру в градусах Цельсия.

Пара популярных кейсов баз данных «ключ — значение»:

Иногда нормально использовать несколько типов СУБД — каждый под свою задачу.

Если: