Что такое NoSQL

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

Но одно реше­ние не может под­хо­дить всем и все­гда. Сего­дня пого­во­рим обо всех осталь­ных вари­ан­тах, кото­рые собра­ны под еди­ным боль­шим тер­ми­ном NoSQL — это общее назва­ние для нере­ля­ци­он­ных баз дан­ных.

Способ организации данных

В SQL-базах всё про­сто: есть, услов­но гово­ря, таб­ли­цы, и есть свя­зи меж­ду ними. Все дан­ные хра­нят­ся в этих таб­ли­цах.

В NoSQL-базах всё ина­че — там может не быть таб­лиц, а вме­сто них — свои моде­ли дан­ных. Каж­дая из них под­хо­дит под свои зада­чи, уни­вер­саль­ной нет. Вот основ­ные моде­ли:

Ключ-значение

У каж­дой запи­си есть назва­ние поля и его зна­че­ние. Напри­мер:

name: ‘Миша’
today: ‘9/09/2020’
president: ‘Путин’
writer: ‘Пуш­кин’
pogoda: ‘ну такая’

Пер­вая часть — это ключ, вто­рая часть — зна­че­ние. И мож­но под­сы­пать сколь­ко хочешь новых клю­чей.

Это полез­но, напри­мер, для сло­ва­рей или меха­низ­мов авто­за­ме­ны: «Если встре­ти­лось такое сло­во — заме­ни на вот такое».

Колонки

Пред­ставь­те себе одну огром­ную таб­ли­цу, в кото­рой хра­нят­ся все дан­ные в базе. Отли­чие от тра­ди­ци­он­ной схе­мы в том, что в SQL-базах рабо­та идёт со стро­ка­ми, а здесь — с колон­ка­ми. Напри­мер, если в такую базу зане­сти спи­сок из 250 луч­ших филь­мов с назва­ни­я­ми, актё­ра­ми и режис­сё­ра­ми, то все назва­ния мож­но полу­чить с помо­щью толь­ко одно­го запро­са и одно­го обра­ще­ния к базе. В слу­чае с SQL таких обра­ще­ний к базе было бы 250 — по одно­му на каж­дую стро­ку.

Что такое NoSQL

Графы

Если ваши дан­ные мож­но пред­ста­вить в виде гра­фа или дере­ва, то вам подой­дёт и база дан­ных с таким же под­хо­дом к хра­не­нию и поис­ку. 

Дере­во — это когда дан­ные хра­нят­ся по систе­ме «роди­тель — отпрыс­ки». Есть некий роди­тель­ский кусок дан­ных, у него есть свя­зан­ные с ним отпрыс­ки. У тех тоже могут быть свои отпрыс­ки и так далее. Каж­дая еди­ни­ца дан­ных может быть чьим-то отпрыс­ком (но толь­ко кого-то одно­го) и иметь сколько-то соб­ствен­ных отпрыс­ков.

В дере­вьях удоб­но хра­нить дан­ные, напри­мер, для поис­ко­вых алго­рит­мов. В «дере­вьях» так­же хра­нят­ся фай­лы на вашем ком­пью­те­ре: есть кор­не­вой ката­лог, в нём вло­жен­ные пап­ки, в них ещё пап­ки, в них фай­лы. Один и тот же файл не может хра­нить­ся одно­вре­мен­но в двух местах. 

Гра­фы — это когда дан­ные свя­за­ны вооб­ще как хочешь. Один кусок дан­ных может быть свя­зан с любы­ми дру­ги­ми в любом коли­че­стве и в любом направ­ле­нии. Дере­во — част­ный слу­чай гра­фа. 

❤️ Про дере­вья мы недав­но писа­ли: что такое Trie и как рабо­та­ет бустинг

Что такое NoSQL

Документы

Вот это кос­мос, смот­ри­те. 

Если мы хра­ним дан­ные в таб­ли­це, у нас есть столб­цы и стро­ки. И если у нас про кого-то есть дан­ные, а про дру­го­го нет, — где-то в таб­ли­це будут про­пус­ки. А если в таб­ли­це нет нуж­но­го столб­ца, а нам нуж­но поло­жить в неё новый тип дан­ных, нам при­дёт­ся созда­вать новый стол­бец, и он для всех будет пустым:

ИмяВоз­растГородРоль
Миша35БрянскРедак­тор
ЖеняМоскваДирек­тор
Роди­онУлья­новск

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

Теперь пред­ставь­те, что есть меха­низм, кото­рый поз­во­ля­ет хра­нить эти дан­ные в более сво­бод­ном фор­ма­те. Напри­мер: 

name: Миша
age: 35
city: Брянск
job: Редак­тор
stickerpack: Док­тор Хаус

<name>Женя</name> сей­час про­жи­ва­ет в <city>Москве</city> и рабо­та­ет <job>директором</job>, а в сво­бод­ное вре­мя <hobby>сплавляется на байдарке</hobby>

Родион.City=Ульяновск
Родион.Boroda=true

Каж­дая из этих запи­сей (про Мишу, Женю и Роди­о­на) — это три отдель­ных доку­мен­та. И база дан­ных настоль­ко умна, что может при необ­хо­ди­мо­сти рас­по­знать, что там где лежит. Если мы запро­сим у нее Boroda, то она про­шер­стит все доку­мен­ты и поищет там раз­мет­ку со сло­вом «Боро­да». В пер­вых двух доку­мен­тах этой раз­мет­ки не будет, а в тре­тьем — будет. Имен­но этот доку­мент нам база дан­ных и вер­нёт. 

Работа с SQL-запросами

Уже по назва­нию вид­но, что NoSQL не под­дер­жи­ва­ет SQL-запросы. Это зна­чит, что у каж­дой такой базы своя мето­ди­ка рабо­ты с дан­ны­ми и обще­го стан­дар­та нет. Не полу­чит­ся выучить опе­ра­ции в Redis, кото­рый рабо­та­ет по прин­ци­пу «ключ-значение» и быст­ро осво­ить MongoDB, где всё осно­ва­но на доку­мен­тах.

Неко­то­рые NoSQL-базы пыта­ют­ся под­дер­жи­вать что-то из SQL, но на прак­ти­ке это рабо­та­ет пло­хо.

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

Что­бы реля­ци­он­ная база дан­ных мог­ла рабо­тать с боль­шим объ­ё­мом дан­ных, нуж­но поста­вить желе­зо помощ­нее или доба­вить несколь­ко копий такой базы, что­бы мож­но было быст­рее читать из неё.

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

Надёжность и безопасность

Реля­ци­он­ная база дан­ных надёж­на как ска­ла, в ней не может слу­чить­ся ниче­го пло­хо­го, пото­му что она сама за этим сле­дит. А если такое слу­ча­ет­ся, то все­гда мож­но вер­нуть­ся на шаг назад и вос­ста­но­вить все дан­ные без потерь. За это при­хо­дит­ся пла­тить ско­ро­стью рабо­ты.

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

Применение

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

Но если вам нуж­на ско­рость, мас­штаб и боль­шая мощ­ность — посмот­ри­те на NoSQL. Един­ствен­ный минус — у каж­дой базы свои пра­ви­ла рабо­ты с дан­ны­ми, поэто­му быст­ро перей­ти от одной к дру­гой не полу­чит­ся.

Текст и иллю­стра­ции:
Миша Поля­нин

Редак­тор:
Мак­сим Илья­хов

Кор­рек­тор:
Ира Михе­е­ва

Иллю­стра­тор:
Даня Бер­ков­ский

Вёрст­ка:
Маша Дро­но­ва

Достав­ка:
Олег Веш­кур­цев