Skip to content

SQL vs NoSQL

Jump to bottom
Sᴛѧʀʟɪɴɢ edited this page Feb 24, 2019 · 3 revisions

Где можно хранить данные?

Простой пример: регистрация пользователя.

Хранение данных в глобальной переменной

Можем хранить пользователей в глобальной переменной, которая будет храниться
в памяти в течение всего срока жизни приложения.

var users = []
app.post('/users', (req, res) => {
  const user = req.body;
  users.push(user);
  res.send('successfully registered')
});

Проблемы:

  • оперативная память дорогая
  • память очищается каждый раз, когда приложение перезапускается
  • возможно переполнение памяти, если её не чистить

Хранение данных в файле

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

const fs = require('fs')
app.post('/users', (req, res) => {
  const user = req.body
  fs.appendToFile('users.txt', JSON.stringify(user), err => res.send('successfully registered'));
});

Проблемы:

  • добавление данных работает хорошо, но что насчёт изменения и удаления?
  • нет простого решения для параллельного доступа к файлу
  • мы не можем разделить файлы между серверами - сложно масштабировать приложение

Поэтому данные хранят в базах данных.

СУБД

Системы управления базами данных (СУБД) — это высокоуровневое ПО, работающее
с низкоуровневыми API.

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

Модели баз данных

СУБД основаны на моделях баз данных — определённых структурах для обработки данных.

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

Реляционная модель

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

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

Безмодельный (NoSQL) подход

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

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

Документальный подход

Документальные модели – вместо хранения строк данных, как в реляционных базах,
данные хранятся в виде документов. Которые в свою очередь могут группироваться в
наборы. Каждый документ может иметь свою собственную структуру. Это очень
напоминает процесс организации документов на компьютере. Многие пользователи
стараются сохранять документы структурированно. Документы по одной теме в одну
папку, по другой в другую. Наиболее упоминаемым из представителей
документно-ориентированных баз данных является MongoDB.

Реляционные СУБД

РСУБД реализуют реляционную модель.
Они гарантируют надёжность, прозводительность и защиту информации от потерь.

РСУБД требуют чётких и ясных схем.
Эти рамки, определённые пользователем, задают способ их хранения и использования.
Схемы очень похожи на таблицы, столбцы которых отражают порядковый номер и тип
информации в каждой записи, а строки — содержимое этих записей.
Перед тем, как сохранить данные, нужно задать типы различных значений. (имя - строка, количество - число).

SQL - язык запросов, предназначенный для работы с реляционными базами данных.

Примеры: SQLite, MySQL, PostgreSQL

NoSQL-СУБД

NoSQL-СУБД не используют реляционную модель структуризации данных.

Существует много реализаций NoSQL-СУБД.
Они не имеют схему и допускают неограниченное формирование записей и хранение данных в виде ключ-значение.

В отличие от традиционных РСУБД, некоторые базы данных NoSQL, например, MongoDB,
позволяют группировать коллекции данных с другими базами данных. Такие СУБД
хранят данные как одно целое. Эти данные могут представлять собой одиночный
объект наподобие JSON (что хорошо сочетается с JS) и вместе с тем корректно
отвечать на запросы к полям.

Никогда нельзя гарантировать, что данные консистентны и никогда нельзя узнать,
какая структура находится в базе данных.

NoSQL базы данных не используют общий формат запроса (как SQL в реляционных
базах данных). Каждое решение использует собственную систему запросов.

Сравнение SQL и NoSQL

Структура и тип хранящихся данных

SQL/реляционные базы данных требуют наличия однозначно определённой
структуры хранения данных, а NoSQL базы данных таких ограничений не ставят.

Традиционные реляционные базы данных SQL хранят данные в таблицах., где каждая строка
представляет отдельный элемент данных, а столбец характеризует один из параметров
элемента данных. По сути, строка данных таблицы плоский объект со своими свойствами
(столбцами). При этом каждый столбец несет в себе единицу информации/свойства,
и все свойства вместе образуют объект данных (строку).

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

Гибкость

В традиционных базах данных всё четко разложено по полочкам. Сначала определяем
модель (описываем структуру таблицы, какие поля, какие типы данных, размеры и т.д.)
и уже потом вводим данные. При этом вводить в столбец строки мы можем только данные,
которые соответствуют определению столбца (его типу и размеру). Если захотим добавить
новое поле, нам придется останавливать работу с таблицей и менять ее схему. Что может
занять очень много времени. Да и вообще что бы внести большие изменения в структуру,
неплохо было бы останавливать работу всех клиентов с базой данных. В NoSQL с этим
проще, схемы данных или динамические или вообще отсутствуют. Можно добавить данные
буквально на лету не внося изменения в схему данных.

Запросы

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

Каждая NoSQL база данных реализует свой способ работы с данными.

Масштабируемость

Оба решения легко растягиваются вертикально.

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

Если нам необходимо увеличить вычислительную мощность, то по сути это перенос
базы данных на другой более мощный сервер. Что разумеется приводит к
значительным финансовым затратам. Есть конечно решения для переноса части
вычислительных мощностей на другой сервер, сравнимый по характеристикам с
текущим. Фактический NoSQL далеко не ушел, масштабирование осуществляется
горизонтально, за счет переложения определённых вычислений на другие сервера.

Надёжность

SQL базы данных однозначно впереди.

Поддержка

Для SQL существует больше готовых решений и известных проблем, что связано
с возрастом РСУБД.

Заключение сравнения

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

Если всё меняется быстро, нужна высокая производительность при обработке разнотипных
данных то, скорее всего NoSQL будет правильным выбором.

Если данные хорошо структурированы и структура данных меняется медленно, при этом
объем данных растет не лавинообразно то традиционные реляционные базы данных
подойдут больше.

https://medium.com/devschacht/node-hero-chapter-5-dd79607858f2 http://wisedata.ru/2016/04/13/rec-sql-nosql-whatdif/ https://tproger.ru/translations/sql-nosql-database-models/

Clone this wiki locally