Актуальные сообщения на SitePoint сегодня:
- 7 способов сделать WordPress проще для пользователей
- Мне нужен сайт. Что мне нужно знать о хостинге?
- Контроль версий WordPress с помощью Git
- 10 простых советов по безопасности WordPress
- Какой формат изображения подходит для вашего сайта?
Базы данных SQL (язык структурированных запросов) были основным механизмом хранения данных более четырех десятилетий. Использование взорвалось в конце 1990-х годов с появлением веб-приложений и опций с открытым исходным кодом, таких как MySQL, PostgreSQL и SQLite.
Базы данных NoSQL существуют с 1960-х годов, но в последнее время набирают популярность такие опции, как MongoDB, CouchDB, Redis и Apache Cassandra.
Вы найдете много учебных пособий, объясняющих, как использовать тот или иной вариант SQL или NoSQL, но немногие обсуждают, почему вы должны выбрать один из них предпочтительнее другого. Я надеюсь заполнить этот пробел. В этой статье мы рассмотрим фундаментальные различия. В следующей статье мы рассмотрим типичные сценарии и определим оптимальный выбор.
Большинство примеров применимо к популярным системам баз данных MySQL SQL и MongoDB NoSQL. Другие базы данных SQL / NoSQL аналогичны, но их функциональные возможности и синтаксис будут незначительными.
Священная война SQL против NoSQL
Прежде чем идти дальше, давайте развеем ряд мифов …
МИФ: NoSQL заменяет SQL
Это все равно, что сказать, что лодки были заменены автомобилями, потому что они — более новая технология. SQL и NoSQL делают одно и то же: хранят данные. Они используют разные подходы, которые могут помочь или помешать вашему проекту. Несмотря на то, что он чувствует себя более новым и захватывает последние заголовки, NoSQL не является заменой SQL — это альтернатива .
МИФ: NoSQL лучше / хуже SQL
Некоторые проекты лучше подходят для использования базы данных SQL. Некоторые лучше подходят для NoSQL. Некоторые могут использовать либо взаимозаменяемо. Эта статья никогда не может быть SitePoint Smackdown, потому что вы не можете применять одни и те же общие предположения везде.
МИФ: SQL против NoSQL — четкое различие
Это не обязательно правда. Некоторые базы данных SQL используют функции NoSQL и наоборот. Выбор, вероятно, будет становиться все более размытым, и гибридные базы данных NewSQL могут предоставить некоторые интересные варианты в будущем.
МИФ: язык / структура определяет базу данных
Мы привыкли к технологиям, таким как —
- ЛАМПА: Linux, Apache, MySQL (SQL), PHP
- СРЕДСТВО: MongoDB (NoSQL), Express, Angular, Node.js
- .NET, IIS и SQL Server
- Java, Apache и Oracle.
Существуют практические, исторические и коммерческие причины, почему эти стеки эволюционировали, но не предполагайте, что они являются правилами. Вы можете использовать базу данных MongoDB NoSQL в своем проекте PHP или .NET . Вы можете подключиться к MySQL или SQL Server в Node.js. Вы можете не найти столько учебников и ресурсов, но ваши требования должны определять тип базы данных, а не язык .
(Тем не менее, не делайте жизнь преднамеренно трудной для себя! Выбор необычной комбинации технологий или комбинации SQL и NoSQL возможен, но вам будет сложнее найти поддержку и нанять опытных разработчиков.)
Имея это в виду, давайте посмотрим на основные различия …
Таблицы SQL против документов NoSQL
Базы данных SQL предоставляют хранилище связанных таблиц данных. Например, если вы запускаете онлайн-магазин книг, информацию о книге можно добавить в таблицу с именем book
:
ISBN | заглавие | автор | формат | цена |
---|---|---|---|---|
9780992461225 | JavaScript: от новичка до ниндзя | Даррен Джонс | электронная книга | 29,00 |
9780994182654 | Jump Start Git | Шаумик Дайтари | электронная книга | 29,00 |
Каждый ряд — это отдельная книжная запись. Конструкция жесткая; Вы не можете использовать одну и ту же таблицу для хранения различной информации или вставки строки, где ожидается число.
В базах данных NoSQL хранятся JSON-подобные документы пары полей-значений, например
{ ISBN: 9780992461225, title: "JavaScript: Novice to Ninja", author: "Darren Jones", format: "ebook", price: 29.00 }
Подобные документы могут храниться в коллекции , которая аналогична таблице SQL. Однако вы можете хранить любые данные в любом документе; база данных NoSQL не будет жаловаться Например:
{ ISBN: 9780992461225, title: "JavaScript: Novice to Ninja", author: "Darren Jones", year: 2014, format: "ebook", price: 29.00, description: "Learn JavaScript from scratch!", rating: "5/5", review: [ { name: "A Reader", text: "The best JavaScript book I've ever read." }, { name: "JS Expert", text: "Recommended to novice and expert developers alike." } ] }
Таблицы SQL создают строгий шаблон данных, поэтому ошибаться сложно. NoSQL более гибок и простителен, но возможность хранить любые данные в любом месте может привести к проблемам согласованности.
Схема SQL против NoSQL Schemaless
В базу данных SQL невозможно добавить данные, пока вы не определите таблицы и типы полей в так называемой схеме . Схема необязательно содержит другую информацию, такую как —
- первичные ключи — уникальные идентификаторы, такие как ISBN, которые применяются к одной записи
- индексы — часто запрашиваемые поля индексируются для быстрого поиска
- отношения — логические связи между полями данных
- функциональные возможности, такие как триггеры и хранимые процедуры .
Ваша схема данных должна быть спроектирована и реализована до того, как будет разработана какая-либо бизнес-логика для манипулирования данными. Возможно сделать обновления позже, но большие изменения могут быть сложными.
В базе данных NoSQL данные можно добавлять где угодно и когда угодно. Нет необходимости указывать дизайн документа или даже коллекцию заранее. Например, в MongoDB следующий оператор создаст новый документ в новой коллекции book
если он не был создан ранее:
db.book.insert( ISBN: 9780994182654, title: "Jump Start Git", author: "Shaumik Daityari", format: "ebook", price: 29.00 );
(MongoDB автоматически добавит уникальное значение _id
к каждому документу в коллекции. Вы все еще можете определить индексы, но это можно сделать позже, если это необходимо.)
База данных NoSQL может быть более подходящей для проектов, в которых сложно определить исходные требования к данным. Тем не менее, не путайте трудности с ленью: пренебрежение проектированием хорошего хранилища данных в начале проекта приведет к проблемам позже.
Нормализация SQL против денормализации NoSQL
Предположим, мы хотим добавить информацию об издателе в нашу базу данных книжного магазина. Один издатель может предложить несколько заголовков, поэтому в базе данных SQL мы создаем новую таблицу publisher
:
Я бы | имя | страна | Эл. адрес |
---|---|---|---|
SP001 | SitePoint | Австралия | [email protected] |
Затем мы можем добавить поле publisher_id
в нашу таблицу book
, которая ссылается на записи от publisher.id
:
ISBN | заглавие | автор | формат | цена | publisher_id |
---|---|---|---|---|---|
9780992461225 | JavaScript: от новичка до ниндзя | Даррен Джонс | электронная книга | 29,00 | SP001 |
9780994182654 | Jump Start Git | Шаумик Дайтари | электронная книга | 29,00 | SP001 |
Это минимизирует избыточность данных; мы не повторяем информацию об издателе для каждой книги — только ссылку на нее. Этот метод известен как нормализация и имеет практические преимущества. Мы можем обновить одного издателя без изменения данных book
.
Мы можем использовать методы нормализации в NoSQL. Документы в коллекции book
—
{ ISBN: 9780992461225, title: "JavaScript: Novice to Ninja", author: "Darren Jones", format: "ebook", price: 29.00, publisher_id: "SP001" }
— ссылка на документ в коллекции publisher
:
{ id: "SP001" name: "SitePoint", country: "Australia", email: "[email protected]" }
Однако это не всегда практично по причинам, которые станут очевидны ниже. Мы можем выбрать денормализацию нашего документа и повторить информацию об издателе для каждой книги:
{ ISBN: 9780992461225, title: "JavaScript: Novice to Ninja", author: "Darren Jones", format: "ebook", price: 29.00, publisher: { name: "SitePoint", country: "Australia", email: "[email protected]" } }
Это приводит к более быстрым запросам, но обновление информации об издателе в нескольких записях будет значительно медленнее.
SQL реляционное соединение против NoSQL
SQL-запросы предлагают мощное предложение JOIN. Мы можем получить связанные данные в нескольких таблицах, используя один оператор SQL. Например:
SELECT book.title, book.author, publisher.name FROM book LEFT JOIN book.publisher_id ON publisher.id;
Это возвращает все названия книг, авторов и связанные имена издателей (при условии, что один был установлен).
NoSQL не имеет эквивалента JOIN, и это может шокировать тех, кто имеет опыт работы с SQL. Если бы мы использовали нормализованные коллекции, как описано выше, нам нужно было бы выбрать все документы book
, извлечь все связанные документы publisher
и вручную связать их в логике нашей программы. Это одна из причин, почему денормализация часто имеет важное значение.
SQL против NoSQL целостности данных
Большинство баз данных SQL позволяют вам применять правила целостности данных с помощью ограничений внешнего ключа (если вы до сих пор не используете старый, более не функционирующий механизм хранения MyISAM в MySQL). Наш книжный магазин мог бы —
- убедитесь, что все книги имеют действительный код
publisher_id
который соответствует одной записи в таблицеpublisher
, и - не разрешать удаление издателей, если им назначена одна или несколько книг.
Схема обеспечивает соблюдение этих правил для базы данных. Разработчики или пользователи не могут добавлять, редактировать или удалять записи, что может привести к неверным данным или потерянным записям.
Те же параметры целостности данных недоступны в базах данных NoSQL; Вы можете хранить то, что вы хотите, независимо от любых других документов. В идеале, один документ будет единственным источником всей информации о предмете.
SQL против NoSQL транзакций
В базах данных SQL в транзакции могут выполняться два или более обновлений — оболочка «все или ничего», гарантирующая успех или неудачу. Например, предположим, что наш книжный магазин содержит таблицы order
и stock
. Когда книга заказывается, мы добавляем запись в таблицу order
и уменьшаем количество stock
таблице stock
. Если мы выполним эти два обновления по отдельности, одно из них может быть успешным, а другое — неудачным — таким образом, наши цифры будут не синхронизированы. Размещение одних и тех же обновлений в транзакции обеспечивает либо успешное выполнение, либо оба сбоя.
В базе данных NoSQL модификация одного документа является атомарной. Другими словами, если вы обновляете три значения в документе, либо все три обновляются успешно, либо оно остается неизменным. Однако нет эквивалента транзакции для обновлений нескольких документов. Существуют опции , подобные транзакциям , но на момент написания они должны быть обработаны вручную в вашем коде.
Синтаксис SQL против NoSQL CRUD
Создание, чтение, обновление и удаление данных является основой всех систем баз данных. По сути —
- SQL — это легкий декларативный язык. Он обманчиво мощен и стал международным стандартом, хотя большинство систем реализуют несколько иные синтаксисы.
- Базы данных NoSQL используют JavaScripty-выглядящие запросы с JSON-подобными аргументами! Основные операции просты, но вложенный JSON может становиться все более сложным для более сложных запросов.
Быстрое сравнение:
SQL | NoSQL |
---|---|
вставить новую запись книги | |
|
|
обновить запись книги | |
|
|
вернуть все названия книг за 10 долларов | |
|
Второй объект JSON известен как проекция : он устанавливает, какие поля будут возвращены ( |
посчитать количество книг SitePoint | |
|
Это предполагает использование денормализованных документов. |
вернуть количество типов формата книги | |
|
Это называется агрегацией : новый набор документов вычисляется из исходного набора. |
удалить все книги SitePoint | |
В качестве альтернативы можно удалить запись |
|
SQL против производительности NoSQL
Пожалуй, самое противоречивое сравнение, NoSQL регулярно цитируется как более быстрый, чем SQL. Это не удивительно; Более простое денормализованное хранилище NoSQL позволяет вам получать всю информацию о конкретном элементе за один запрос. Нет необходимости в связанных JOIN или сложных SQL-запросах.
Тем не менее, ваш дизайн проекта и требования к данным будут иметь наибольшее влияние. Хорошо спроектированная база данных SQL почти наверняка будет работать лучше, чем плохо спроектированный эквивалент NoSQL, и наоборот.
SQL против NoSQL Scaling
По мере роста ваших данных может возникнуть необходимость распределить нагрузку между несколькими серверами. Это может быть сложно для систем на основе SQL. Как вы размещаете связанные данные? Кластеризация, возможно, самый простой вариант; Несколько серверов имеют доступ к одному и тому же центральному хранилищу, но даже у этого есть проблемы
Более простые модели данных NoSQL могут упростить этот процесс, и многие с самого начала были построены с возможностью масштабирования. Это обобщение, поэтому обратитесь за советом к специалисту, если столкнетесь с такой ситуацией.
SQL против NoSQL Практичность
Наконец, давайте рассмотрим проблемы безопасности и системы. Самые популярные базы данных NoSQL были около нескольких лет; они более подвержены проблемам, чем более зрелые продукты SQL. Сообщалось о многих проблемах , но большинство сводится к одной проблеме: знаниям .
Разработчики и системные администраторы имеют меньший опыт работы с новыми системами баз данных, поэтому ошибки допускаются. Выбор NoSQL, потому что он кажется более свежим или потому что вы хотите избежать неизбежного проектирования схемы, приводит к проблемам позже.
SQL против NoSQL Сводка
Базы данных SQL и NoSQL делают одно и то же по-разному. Можно выбрать один вариант и переключиться на другой позже, но небольшое планирование может сэкономить время и деньги.
Проекты, где SQL идеален:
- логически связанные требования к дискретным данным, которые могут быть определены заранее
- целостность данных имеет важное значение
- проверенная стандартами технология с хорошим опытом и поддержкой разработчиков.
Проекты, где NoSQL идеален:
- несвязанные, неопределенные или развивающиеся требования к данным
- более простые или более свободные цели проекта, способные немедленно начать кодирование
- скорость и масштабируемость является обязательным условием.
В случае нашего книжного магазина база данных SQL представляется наиболее практичным вариантом, особенно когда мы вводим средства электронной коммерции, требующие надежной поддержки транзакций. В следующей статье мы обсудим дальнейшие сценарии проекта и определим, будет ли база данных SQL или NoSQL лучшим решением.