SQL и NoSQL в чем разница?
SQL и NoSQL в чем же всё таки разница? Всё выше пытаются поднять флаг NoSQL, утверждая, что реляционные базы данных устарели. Новые горизонты требуют новых решений, кто хочет быть лидером завтра должен сегодня начать использовать NoSQL. Действительно ли это так? Действительно ли NoSQL – это завтра, а привычные базы данных уже вчера? Попробуем разобраться в этом.
Хранение данных – традиционные реляционные базы данных SQL хранят данные в таблицах. Где каждая строка представляет отдельный элемент данных, а столбец характеризует один из параметров элемента данных. По сути, строка данных таблицы плоский объект со своими свойствами (столбцами). При этом каждый столбец несет в себе единицу информации/свойства, и все свойства вместе образуют объект данных (строку). NoSQL с классической точки зрения хаотичен, каждый элемент не так структурирован. Да и вообще любой узел, элемент хранения может представлять из себя совершенно другую объектную модель, нежели соседний элемент. Один элемент может быть документом, следующий таблицей, а третий набором ключ-значение.
Схемы и гибкость – в традиционных базах данных всё четко разложено по полочкам. Сначала определяем модель (описываем структуру таблицы, какие поля, какие типы данных, размеры и т.д.) и уже потом вводим данные. При этом вводить в столбец строки мы можем только данные, которые соответствуют определению столбца (его типу и размеру). Если захотим добавить новое поле, нам придется останавливать работу с таблицей и менять ее схему. Что может занять очень много времени. Да и вообще что бы внести большие изменения в структуру, неплохо было бы останавливать работу всех клиентов с базой данных. В NoSQL с этим проще, схемы данных или динамические или вообще отсутствуют. Можно добавить данные буквально на лету не внося изменения в схему данных.
Масштабируемость – масштабирование еще один тяжелый момент для реляционных баз данных. Если нам необходимо увеличить вычислительную мощность, то по сути это перенос базы данных на другой более мощный сервер. Что разумеется приводит к значительным финансовым затратам. Есть конечно решения для переноса части вычислительных мощностей на другой сервер, сравнимый по характеристикам с текущим. Фактический NoSQL далеко не ушел, масштабирование осуществляется горизонтально, за счет переложения определённых вычислений на другие сервера.
ACID – атомарность, согласованность, изолированность, долговечность определенный набор правил, которому соответствуют большинство реляционных баз данных. В NoSQL может, как быть, так и отсутствовать. При этом в большинстве решений, правила ACID пали жертвой в борьбе с производительностью и масштабируемостью.
Присутствие в название NoSQL слова SQL может навести на мысль что всё таки что то общее есть между моделями данных которые обрабатываются в NoSQL. Но на самом деле NoSQL хранит и обрабатывает разные типы данных. Если понадобится обработать элемент данных, NoSQL вызовет механизм обработки данных соответствующий данной модели. Существует ряд моделей данных которые наиболее часто встречаются в NoSQL:
Документальные модели – вместо хранения строк данных, как в реляционных базах, данные хранятся в виде документов. Которые в свою очередь могут группироваться в наборы. Каждый документ может иметь свою собственную структуру. Это очень напоминает процесс организации документов на компьютере. Многие пользователи стараются сохранять документы структурированно. Документы по одной теме в одну папку, по другой в другую. И не обязательно, что в одной папке окажутся документы одного формата, например DOC, могут быть и картинки и электронные таблицы. Наиболее упоминаемым из представителей документно-ориентированных баз данных является MongoDB. В отчете по хранилищам данных на 2016 год Gartner ставит MongoDB в группу нишевых решений. Но при этом ее позиция достаточно близка к переходу в группу «провидцев» которые могут предложить новые функции хранилищ данных.
Хранилища ключ-значение – по сути, представляют собой подобие словарей, где по ключу можно получить значение с ним связанное. Самыми известными хранилищами подобного рода являются Redis, Voldemort и Dynamo.
Базы данных графов – сохраняют данные в виде графов. В которых есть узлы (объекты), свойства (характеристики объекта) и определены ребра отношений между графами. Такой способ применяют Neo4J и InfiniteGraph.
Базы столбцов (колонок) – хранят данные не в таблицах, как реляционные базы, а в наборах столбцов (семействах столбцов) являющихся контейнерами для строк. При этом строка может содержать разное количество столбцов, другими словами представляют собой разреженные матрицы. Лучшие из таких баз Cassandra и HBase.
Вместо заключения
Так какой же будет ответ, NoSQL – это завтрашний день или нет. На самом деле всё зависит от ситуации, от тех данных, что необходимо обрабатывать и хранить, от скорости с которой могут поступать новые данные и от их структуры. Если всё меняется быстро, нужна высокая производительность при обработке разнотипных данных то, скорее всего NoSQL будет правильным выбором. Однако если данные хорошо структурированы и структура данных меняется медленно, при этом объем данных растет не лавинообразно то традиционные реляционные базы данных подойдут больше. Решает всё контекст использования.
Говорить что SQL вчерашний день тоже нельзя, если посмотреть на новые функции, которые вводятся в SQL Server 2016, то становится, очевидно, что реляционные базы данных живут и развиваются, предлагая новые возможности и решения программистам и пользователям.