Какво е NoSQL? Бази данни за бъдеще в облак

Един от най-фундаменталните избори, които трябва да се направи при разработването на приложение, е дали да се използва SQL или NoSQL база данни за съхранение на данните. Конвенционалните SQL (т.е. релационни) бази данни са плод на десетилетия на развитие на технологиите, добри практики и реални тестове за стрес. Те са предназначени за надеждни транзакции и ad hoc заявки, основни елементи на бизнес приложения. Но те също са обременени с ограничения - като твърда схема -, които ги правят по-малко подходящи за други видове приложения.

Базите данни NoSQL възникнаха в отговор на тези ограничения. Системите NoSQL съхраняват и управляват данни по начини, които позволяват висока оперативна скорост и голяма гъвкавост от страна на разработчиците. Много от тях са разработени от компании като Google, Amazon, Yahoo и Facebook, които търсят по-добри начини за съхраняване на съдържание или обработка на данни за масивни уебсайтове. За разлика от SQL базите данни, много NoSQL бази данни могат да се мащабират хоризонтално на стотици или хиляди сървъри.

Предимствата на NoSQL обаче не идват без разходи. Системите NoSQL обикновено не осигуряват същото ниво на съгласуваност на данните като SQL базите данни. Всъщност, докато SQL базите данни традиционно жертват производителността и мащабируемостта за свойствата на ACID зад надеждните транзакции, базите данни NoSQL до голяма степен отхвърлят тези ACID гаранции за скорост и мащабируемост.

Накратко, базите данни SQL и NoSQL предлагат различни компромиси. Въпреки че те могат да се конкурират в контекста на конкретен проект - като например, кой да изберат за това приложение или за това приложение - те се допълват в по-общата картина. Всеки е подходящ за различни случаи на употреба. Решението не е толкова случай на или / или колкото въпросът кой инструмент е подходящ за работата.

NoSQL срещу SQL

Основната разлика между SQL и NoSQL не е толкова сложна. Всеки има различна философия за това как данните трябва да се съхраняват и извличат.

С базите данни на SQL всички данни имат присъща структура. Конвенционална база данни като Microsoft SQL Server, MySQL или Oracle Database използва схема - формална дефиниция за това как ще бъдат съставени данните, вмъкнати в базата данни. Например, дадена колона в таблица може да бъде ограничена само до цели числа. В резултат на това данните, записани в колоната, ще имат висока степен на нормализиране. Твърдата схема на базата данни на SQL също улеснява сравнително лесното извършване на агрегиране на данните, например чрез JOINs.

С NoSQL данните могат да се съхраняват по безсхемен или свободен начин. Всички данни могат да се съхраняват във всеки запис. Сред базите данни NoSQL ще намерите четири често срещани модела за съхранение на данни, които водят до четири често срещани типа NoSQL системи:

  1. Бази данни на документи (напр. CouchDB, MongoDB). Вмъкнатите данни се съхраняват под формата на JSON структури в свободна форма или „документи“, където данните могат да бъдат всичко - от цели числа до низове до текст със свободна форма. Няма присъща необходимост да се посочва какви полета, ако има такива, ще съдържа документ.
  2. Магазини за ключови стойности (напр. Redis, Riak). Стойностите в свободна форма - от прости цели числа или низове до сложни JSON документи - са достъпни в базата данни чрез ключове.
  3. Магазини с широки колони (напр. HBase, Cassandra). Данните се съхраняват в колони вместо в редове, както в конвенционалната SQL система. Какъвто и да е брой колони (и следователно много различни видове данни) могат да бъдат групирани или обобщавани според нуждите за заявки или изгледи на данни.
  4. Графирайте бази данни (напр. Neo4j). Данните се представят като мрежа или графика на обекти и техните взаимоотношения, като всеки възел в графиката е част от данните в свободна форма.

Съхранението на данни без схеми е полезно в следните сценарии:

  1. Искате бърз достъп до данните и сте по-загрижени за скоростта и простотата на достъпа, отколкото за надеждните транзакции или последователността.
  2. Съхранявате голям обем данни и не искате да се заключвате в схема, тъй като промяната на схемата по-късно може да бъде бавна и болезнена.
  3. Вземате неструктурирани данни от един или повече източници, които ги произвеждат, и искате да запазите данните в оригиналния им вид за максимална гъвкавост.
  4. Искате да съхранявате данни в йерархична структура, но искате тези йерархии да бъдат описани от самите данни, а не от външна схема. NoSQL позволява на данните да бъдат небрежно саморефериращи се по начини, които са по-сложни за емулиране на бази данни на SQL.

Заявка за бази данни NoSQL

Езикът на структурираните заявки, използван от традиционните бази данни, осигурява еднакъв начин за комуникация със сървъра при съхранение и извличане на данни. Синтаксисът на SQL е силно стандартизиран, така че докато отделните бази данни могат да обработват определени операции по различен начин (например функции на прозореца), основите остават същите.

За разлика от това, всяка база данни NoSQL има свой собствен синтаксис за заявки и управление на данните. CouchDB например използва заявки под формата на JSON, изпратени чрез HTTP, за създаване или извличане на документи от своята база данни. MongoDB изпраща JSON обекти по двоичен протокол чрез интерфейс на командния ред или езикова библиотека.

Някои продукти на NoSQL могат да използват подобен на SQL синтаксис за работа с данни, но само в ограничена степен. Например Apache Cassandra, база данни за хранилище на колони, има свой собствен подобен на SQL език, Cassandra Query Language или CQL. Някои от синтаксиса на CQL са направо извън SQL playbook, като ключови думи SELECT или INSERT. Но няма начин да се извърши JOIN или подзаявка в Cassandra и следователно свързаните ключови думи не съществуват в CQL.

Архитектура със споделено нищо

Изборът на дизайн, общ за системите NoSQL, е архитектура „споделено нищо“. В дизайн на споделено нищо, всеки сървърен възел в клъстера работи независимо от всеки друг възел. Системата не трябва да получава консенсус от всеки отделен възел, за да върне част от данните на клиент. Заявките са бързи, защото могат да бъдат върнати от който и да е възел най-близо или най-удобно.

Друго предимство на споделеното нищо е устойчивостта и мащабирането. Мащабирането на клъстера е толкова лесно, колкото завъртането на нови възли в клъстера и изчакването на синхронизирането им с останалите. Ако възел NoSQL прекъсне, другите сървъри в клъстера ще продължат да се разменят. Всички данни остават на разположение, дори ако са налични по-малко възли за обслужване на заявки.

Имайте предвид, че дизайнът на споделено нищо не е изключителен за базите данни NoSQL. Много конвенционални SQL системи могат да бъдат настроени по споделен начин, въпреки че това обикновено включва жертване на последователност в клъстера за производителност.

NoSQL ограничения

Ако NoSQL предоставя толкова много свобода и гъвкавост, защо да не изоставим напълно SQL? Простият отговор: Много приложения все още изискват видовете ограничения, последователност и предпазни мерки, които предоставят SQL базите данни. В тези случаи някои „предимства“ на NoSQL могат да се превърнат в недостатъци. Други ограничения произтичат от факта, че NoSQL системите са сравнително нови. 

Няма схема

Дори ако приемате данни в свободна форма, почти винаги трябва да наложите ограничения върху тях, за да станат полезни. С NoSQL налагането на ограничения включва прехвърляне на отговорността от базата данни към разработчика на приложения. Например разработчикът може да наложи структура чрез обектна система за релационно картографиране или ORM. Но ако искате схемата да живее със самите данни , NoSQL обикновено не прави това.

Някои решения на NoSQL предоставят незадължителни механизми за въвеждане и проверка на данни за данни. Apache Cassandra, например, има множество естествени типове данни, които напомнят на тези, открити в конвенционалния SQL.

Евентуална последователност

Системите NoSQL търгуват със силна или незабавна последователност за по-добра наличност и производителност. Конвенционалните бази данни гарантират, че операциите са атомни (всички части на транзакцията са успешни или нито една), последователни (всички потребители имат еднакъв изглед на данните), изолирани (транзакциите не се конкурират) и трайни (след като приключат, ще оцелеят грешка в сървъра).

Тези четири свойства, наричани общо ACID, се обработват по различен начин в повечето системи NoSQL. Вместо незабавна съгласуваност в клъстера, имате евентуална последователност поради времето, необходимо за копиране на актуализации в други възли в клъстера. Данните, вмъкнати в клъстера, в крайна сметка са достъпни навсякъде, но не можете да гарантирате кога.

Семантиката на транзакциите, която в SQL система гарантира, че всички стъпки в транзакцията (например изпълнение на продажба и намаляване на инвентара) са или завършени, или върнати назад, обикновено не са налични в NoSQL. За всяка система, в която трябва да има „един източник на истината“, като банка, подходът NoSQL няма да работи добре. Не искате балансът ви в банката да бъде различен в зависимост от това до кой банкомат отивате; искате да се отчита като едно и също нещо навсякъде.

Някои бази данни NoSQL имат частични механизми за заобикаляне на това. Например MongoDB има гаранции за последователност за отделни операции, но не и за базата данни като цяло. Microsoft Azure CosmosDB ви позволява да изберете ниво на последователност при заявка, така че да можете да изберете поведението, което отговаря на вашия случай на употреба. Но с NoSQL очаквайте евентуална последователност като поведение по подразбиране.

NoSQL заключване

Повечето системи NoSQL са концептуално сходни, но се прилагат по много различен начин. Всяка има тенденция да има свои собствени метафори и механизми за това как данните се търсят и управляват.

Единият страничен ефект от това е потенциално висока степен на свързване между логиката на приложението и базата данни. Това не е толкова лошо, ако изберете система NoSQL и се придържате към нея, но тя може да се превърне в препъни камък, ако промените системата по пътя.

Ако мигрирате от, да речем, MongoDB към CouchDB (или обратно), трябва да направите нещо повече от мигриране на данни. Вие също трябва да навигирате в разликите в достъпа до данни и програмните метафори - с други думи, трябва да пренапишете частите на приложението си, които имат достъп до базата данни.

NoSQL умения

Друг недостатък на NoSQL е относителната липса на опит. Там, където пазарът на конвенционални SQL таланти е все още доста голям, пазарът на умения за NoSQL се заражда.

За справка Indeed.com съобщава, че към края на 2017 г. обемът на списъците с работни места за конвенционални бази данни на SQL - MySQL, Microsoft SQL Server, Oracle Database и т.н. - остава по-висок през последните три години от обема на заданията за MongoDB, Couchbase и Cassandra. Търсенето на експертни познания по NoSQL нараства, но все още е малка част от пазара за конвенционален SQL.

Обединяване на SQL и NoSQL

Можем да очакваме някои от разликите между SQL и NoSQL системите да изчезнат с времето. Вече много бази данни на SQL вече приемат JSON документи като естествен тип данни и могат да изпълняват заявки срещу тези данни. Някои дори имат местни начини за налагане на ограничения върху JSON данни, така че те да се обработват със същата строгост като конвенционалните данни за редове и колони.

От друга страна, базите данни NoSQL не само добавят подобни на SQL езици за заявки, но и други възможности на традиционните бази данни на SQL. Например поне две бази данни на документи - MarkLogic и RavenDB - обещават да бъдат съвместими с ACID.

Тук-там има признаци, че бъдещите поколения бази данни ще разпръснат парадигмите и ще предложат както NoSQL, така и SQL функционалност. Например Azure Cosmos DB на Microsoft използва набор от примитиви под капака, за да възпроизведе взаимозаменяемо поведението на двата вида системи. Google Cloud Spanner е SQL база данни, която съчетава силна последователност с хоризонталната мащабируемост на NoSQL системите.

И все пак, чист SQL и чист NoSQL системи ще имат своето място за много години напред. Потърсете NoSQL за бърз, силно мащабируем достъп до данни в свободна форма. Това идва с няколко разходи, като последователност на четенията и други предпазни мерки, общи за базите данни на SQL. Но за много приложения тези предпазни мерки може би си струва да се търгуват за това, което NoSQL предлага.