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

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

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

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

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

Как устроен SQL

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

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

• клиенты оставляют на сайте заказы;
• в каждом заказе есть несколько позиций с указанием товаров и их количества;
• заказы отправляются с учётом информации из записи о доставке.

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

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

Современные реляционные базы данных позволяют работать с такими табличками графически, но «под капотом» и в сценариях автоматизации используется специальный язык запросов к базе данных — 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 для отдельной СУБД

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

• SQLite позволяет записывать все данные в один файл. Это ограничивает возможности СУБД, но удобно для передачи и обслуживания. Поэтому базу данных применяют в мобильных приложениях и для создания прототипов.
• MySQL — самое распространённое решение с базовой реализацией возможностей стандарта SQL и простым администрированием. Но когда база данных становится большой, MySQL буксует и тяжело масштабируется.
• MariaDB — ответвление MySQL, которое синхронизировано с кодовой базой предшественника. Зато обладает лучшей производительностью.
• Percona Server — другое ответвление MySQL, отличается масштабируемостью на многоядерных серверах.
• PostgreSQL — главная альтернатива MySQL. Это СУБД с продуманной архитектурой, ясной документацией и поддержкой дополнительных типов данных, включая JSON.

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

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

Как устроен NoSQL

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

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

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

• документоориентированные базы данных,
• базы данных «ключ — значение».

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

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

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

• MongoDB умеет работать с большими потоками данных, крупными массивами хранения и легко масштабируется, но имеет сложную реализацию транзакций — важного типа защищённых запросов к базе данных. У MongoDB есть собственный язык запросов MQL, но, как и в случае реляционных СУБД, программисты чаще используют ORM-решения. Считается стандартом БД для онлайн-магазина.
• CouchDB — создана в первую очередь как БД для веб-приложений. Идеальна для статистических обработок, где данные в прошлом не меняются.

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

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

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

• Redis — часто используемая для кеширования данных. В таком применении Redis работает преимущественно с данными в оперативной памяти, а с данными на жёстких дисках взаимодействует более медленная реляционная база данных.
• Cassandra сочетает идею «ключ — значение» с концепцией семейства столбцов. Характерны быстрое время отклика, надёжность и высокая пропускная способность — особенно для записи данных. Эти свойства Cassandra используются для задач Big Data.

Когда лучше выбрать SQL, а когда NoSQL

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

Если:

• Сервис должен проводить операции с оплатой, а сведения обо всех участниках сделки или похожей операции легко описываются в форме таблиц — используйте реляционные базы данных.
• Объекты бизнес-задачи имеют схожую природу, но разную внутреннюю структуру — например, задача связана с управлением контентом. Здесь лучше подойдут документоориентированные базы данных.
• В сервисе есть объекты, которые нужно максимально быстро извлекать или добавлять в память, а долговременное хранение не так важно — подойдут базы данных типа «ключ — значение».