На этапе планирования проекта, над которым я сейчас работаю, мне было любопытно, какие варианты баз данных доступны для кого-то с моим набором навыков. Я в основном знаком с базами данных SQL и форматом JSON, и я начал читать о MongoDB, о том, как он работает, и, что самое важное, о том, чем он отличается от SQL как базы данных NoSQL. Когда я могу использовать какую базу данных и в чем разница между ними? В этой статье я надеюсь выделить некоторые различия между SQL и NoSQL, достоинства и недостатки обоих, а также причины, по которым вы можете применять одно по сравнению с другим.

Начнем с SQL. Начнем с того, что SQL не является строго базой данных. Это язык (SQL означает язык структурированных запросов), который позволяет писать такие команды, как

SELECT id, name, price FROM products

Вкратце, так вы создаете запросы в SQL. У вас есть команда (ВЫБРАТЬ), набор параметров (идентификатор, имя, цена), другая команда (ОТ) и таблица (товары). На самом деле это очень красивый и простой язык, и он может привести к очень элегантным манипуляциям с данными (включая полный CRUD), особенно при использовании его в сочетании с другими фреймворками и языками.

Данные в базе данных SQL хранятся в таблицах, и эти таблицы имеют отношения с другими таблицами в базе данных для создания оптимизированного набора данных с очень небольшим количеством повторяющихся данных. Эти отношения делятся на несколько категорий, таких как «многие ко многим», «один ко многим» и «один к одному».

Каждая таблица имеет набор параметров, которые должен содержать каждый элемент в этой таблице. Эти наборы параметров составляют так называемую схему ваших данных. Таким образом, если таблица User имеет параметры id, name и email, то каждый элемент в этой таблице должен иметь связанный с ним идентификатор, имя и адрес электронной почты (даже если эти значения равны нулю). Кроме того, каждый элемент не может иметь никаких параметров, кроме тех, которые указаны в схеме, а это означает, что если вы переносите сторонние данные в свою базу данных SQL, вам нужно будет сформировать их в соответствии с требованиями вашей схемы. Это дает нам некоторую негибкость, когда данные имеют очень строгую структуру, которой необходимо придерживаться.

Итак, мы можем начать видеть, что данные в базе данных SQL имеют некоторые плюсы и минусы. Наличие схемы может быть хорошей вещью, поскольку она помогает легко понять ваши данные, и вы точно знаете, что содержит каждый элемент в таблице, потому что каждый элемент должен строго придерживаться схемы. Однако при этом возникают проблемы, например масштабируемость. Что делать, если вы хотите добавить новую информацию в свою таблицу пользователей, например номер телефона? Вы можете добавить этот параметр в схему, однако каждый существующий объект User должен иметь нулевой атрибут номера телефона, пока он не будет заполнен позже.

Базы данных NoSQL (такие как MongoDB, сокращенно от слова «огромные») созданы для хранения невероятно больших наборов данных. У них нет таблиц, а есть нечто, называемое коллекциями, которое в конечном итоге действует как таблица, хотя и не требует схемы. Это гибко, потому что в одной коллекции может быть несколько элементов с разными параметрами.

Примером того, что можно использовать, является приложение, которое ищет лучшие предложения на нескольких веб-сайтах. Эти веб-сайты, вероятно, будут иметь совершенно разные типы данных, и вместо того, чтобы кропотливо согласовывать входящие данные с внешних веб-сайтов во что-то, что соответствует вашей схеме, вы можете просто собрать все данные в одну коллекцию, а затем создать другую коллекцию, которая фильтрует только определенные ключевые параметры, такие как название товара, цена и местонахождение. Однако это означает, что вы получаете две (или более) коллекции, которые используют одни и те же данные, что может вызвать проблемы, касающиеся времени загрузки и хранения. Это также может вызвать проблему, если не принять во внимание, что некоторые данные внешнего веб-сайта могут не содержать определенных полей, на которые полагается внутренний инженер. Поэтому, если вы получаете лучшие предложения с нескольких веб-сайтов, но один из этих веб-сайтов вместо этого называет свой параметр имени «product_title», вам нужно будет найти способ правильно извлечь имя этого элемента.

Теперь самое время быстро перейти к горизонтальному и вертикальному масштабированию. Существует два основных способа масштабирования вычислительной мощности и хранилища в сети серверов. Один из них - «горизонтальный», когда вы добавляете больше серверов (и, следовательно, больше мощности) к существующей сети. Другой - «вертикальный», когда вы берете сервер и увеличиваете его вычислительную мощность или объем хранилища, например, добавляя дополнительные жесткие диски или оперативную память. У каждого из них есть свои преимущества и преимущества. Горизонтальный, например, имеет гораздо более высокий потенциал для общей мощности, но занимает больше физического пространства. Вертикальный, однако, имеет гораздо меньший энергетический потенциал, но занимает меньше физического места. Есть много других, более конкретных и технических проблем, связанных с этим, но вкратце, так работает горизонтальное и вертикальное масштабирование.

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

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

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

Ожидаете ли вы, что вам придется читать / писать много данных, но не обязательно часто обновлять эти данные? Может быть, в вашем приложении есть несколько функций, которые используются часто, а другие - не так часто? Обеспокоены возможностью как можно быстрее прочитать все нужные данные без сложных таблиц соединения? Имеет ли значение для вас масштабирование? Тогда вам лучше выбрать NoSQL.