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

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

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

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

Така че, ако използвате релационни бази данни от сега или ще използвате за нов софтуерен проект, не се притеснявайте, придържайте се към решението си и то няма да умре в близко обозримо бъдеще. Освен това имайте предвид, че NoSQL не означава „Без SQL“, а означава „Не само SQL“.

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

Защо NoSQL е трудно?

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

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

NoSQL базите данни драстично се различават от другите си аналози в зависимост от типа на NoSQL базата данни (Document Database, Key-Value Database, Graph Database и т.н.) и специфичното изпълнение на доставчика (MongoDB, DynamoDB, Cassandra и т.н.). ). Поради това няма универсални най-добри практики или принципи за проектиране на схема на база данни или за заявки, които отговарят на всички типове бази данни NoSQL. Това създава предизвикателството при проектирането на уникален за съответния тип NoSQL база данни, придържайки се към собствените си най-добри практики.

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

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

Дублирането на данни може да се превърне в най-добра практика

Ако сте разработчик, който има нагласа да казва „не“ на дублирането на данни на ниво база данни, крайно време е да преразгледате NoSQL.

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

Например днес съхранението не е толкова скъпо, докато процесорната мощност е по-скъпа за разлика от тях. Следователно съхраняването на данни в различни форми, като се използва повече място за съхранение за директно извличане, може да има смисъл по-скоро от извършване на тежки изчислителни заявки.

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

Следователно е важно да се оцени как данните се консумират и актуализират от приложението и да се проектира базата данни по съответния начин.

Запитването на NoSQL е уникално за всяка NoSQL база данни

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

При определени типове бази данни NoSQL (напр. определени бази данни с документи и бази данни с ключ-стойност) не се изненадвайте, като видите, че е възможно да правите заявки само с ключови атрибути или да използвате предварително дефинирани индекси, за разлика от релационните бази данни, където можете да правите заявки почти от всеки атрибут.

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

Транзакциите не се обработват по един и същи начин

За повечето NoSQL бази данни е трудно да се създадат транзакции, подобни на релационните бази данни, където базата данни осигурява поддръжка на по-високо ниво за ангажименти и връщания назад. Следователно също така е важно да се идентифицира нивото на поддръжка от NoSQL базата данни за изпълнение на транзакции.

За повечето NoSQL бази данни ще трябва да управлявате транзакциите и връщането назад на ниво приложение. Много от тези NoSQL бази данни обаче предоставят някои основни функции, които ще улеснят живота ви.

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

Например, можете да създадете операция за актуализиране, казвайки, че ако сумата е само сума „x“, направете актуализацията на елемента (или хвърлете изключение, ако е променено, което трябва да се обработи съответно в приложението. Предимството е, че колекциите или таблиците не се заключват, докато се извършва транзакция, което се отразява положително върху производителността на базата данни.

Използване както на NoSQL, така и на Relational

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

Ако вашето приложение изисква специална поддръжка за висока пропускателна способност, наличност, мащабиране на съхранение, можете да обмислите използването на NoSQL бази данни за съответната област на използване в допълнение към релационната база данни.

През последните няколко години приемането на Microservices също направи логично използването на множество типове бази данни в зависимост от необходимите възможности на приложението.

Например можете да обмислите използването на In-Memory Key-Value NoSQL база данни като Redis за съхранение на сесии, използване на релационна база данни за съхраняване на бизнес обекти и т.н.

Така че запазвайки отговора кратък, става обичайна практика да се използват различни типове бази данни заедно за изграждане на приложения, вместо да се придържаме към една база данни за всички.

Заключение

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

Например, няколко предимства включват способността за обработка на големи количества данни за съхранение, мащабируемост, гъвкаво събиране на данни и т.н.

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