Сравнение SQL и NoSQL: как выбрать систему хранения данных

Согласно рейтингу DB-Engines, в топе самых популярных СУБД четыре реляционных (SQL) и одна нереляционная (NoSQL). Реляционные базы данных занимают львиную долю рынка и наиболее известны. Однако в ряде случаев лучше выбрать NoSQL-решения различного типа.

Мы подготовили небольшой гайд по типам баз данных, чтобы вы могли принять верное решение.

Что такое реляционные и нереляционные базы данных

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

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

Реляционные базы данных, или базы данных SQL

Особенности. Основная особенность — надежность и неизменяемость данных, низкий риск потери информации. При обновлении данных их целостность гарантирована, они заменяются в одной таблице.

Реляционные базы данных, в отличие от нереляционных, соответствуют ACID — это требования к транзакционным системам. Соответствие им гарантирует сохранность данных и предсказуемость работы базы данных:

1. Atomicity, или атомарность — ни одна транзакция не будет зафиксирована в системе частично.
2. Consistency, или непротиворечивость — фиксируются только допустимые результаты транзакций.
3. Isolation, или изолированность — на результат транзакции не влияют транзакции, проходящие параллельно ей.
4. Durability, или долговечность — изменения в базе данных сохраняются несмотря на сбои или действия пользователей.

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

Реляционные БД идеальны для работы со структурированными данными, структура которых не подвержена частым изменениям.

Так выглядит хранение данных в реляционной базе, по сути, это просто таблица:

Клиент	Средний чек	Число покупок за период
1	1000	10
2	1500	5
3	800	6

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

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

Самые известные SQL-базы данных

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

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

PostgreSQL — вторая по популярности open source SQL СУБД. У нее много встроенных функций и дополнений, в том числе для масштабирования в кластер и шардинга таблиц. Подходит, если важна сохранность данных, предполагается их сложная структура. Позволяет работать со структурированными данными, но поддерживает JSON/BSON, что дает некоторую гибкость в схеме данных.

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

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

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

Нереляционные базы данных, или базы данных NoSQL

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

Базы данных NoSQL подходят для хранения больших объемов неструктурированной информации, а также хороши для быстрой разработки и тестирования гипотез.

В них можно хранить данные любого типа и добавлять новые в процессе работы.

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

Четыре вида нереляционных баз данных

Документоориентированные базы данных — данные хранятся в коллекциях документов, обычно с использованием форматов JSON, XML или BSON. Одна запись может содержать столько данных, сколько нужно, в любом типе данных (или типах) — ограничений нет. Внутри одного документа есть внутренняя структура, однако, она может отличаться от одного документа к другому. Также документы можно вкладывать друг в друга.

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

Пример такой базы данных: MongoDB.

Вот так будет выглядеть хранение данных в отдельных документах вместо таблицы со столбцами и строками:

Документ 1	Документ 2	Документ 3
клиент — 1 средний чек — 1000 число покупок за период — 6	клиент — 2 средний чек — 1500 число покупок за период — 10	клиент — 3 средний чек — 800 число покупок за период — 8

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

Пример такой базы данных: Redis.

Данные в базе данных ключ-значение выглядят примерно, как в примере ниже — здесь к каждому городу мы привязали адреса пунктов выдачи товаров. Понятно, что такая структура подходит не для всех данных:

Ключ	Значение
Город 1	адрес 1, адрес 2, адрес 3
Город 2	адрес 1, адрес 2, адрес 3

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

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

Примеры таких баз данных: Neo4j, OrientDB.

Графовые базы данных хранят сами данные и взаимосвязи между ними

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

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

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

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

Пример такой базы данных: Cassandra.

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

Популярные нереляционные базы данных

MongoDB — опенсорсная база данных документного типа. Может работать и со структурированными, и с неструктурированными данными. При этом при работе с моделями реляционных данных могут возникать проблемы с производительностью. Подходит для проектов, работающих с разнородными данными, с трудом поддающимися классификации, или если в будущем ожидается значительное изменение структуры данных, в том числе для OLAP-сценариев.

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

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

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

Сравнение реляционных и нереляционных баз данных: что лучше SQL или NoSQL?

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

1. Реляционные SQL-базы — подходят для хранения структурированных данных, особенно в тех случаях, когда крайне важна их целостность. Также эту модель лучше выбрать, если на проекте нужна технология, основанная на стандартах, при использовании которой можно рассчитывать на большое количество дополнений и большой опыт разработчиков.
2. Нереляционные NoSQL-базы данных — нужны, если требования к данным нечеткие, неопределенные, могут меняться с ростом и развитием проекта. А также в тех случаях, когда одно из основных требований к базам данных — высокая скорость работы.

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