3.1. Слаби киселинни свойства
Дълго време последователността на данните е била свещена крава за архитекти и разработчици. Всички релационни бази данни предоставят известно ниво на изолация, or чрез заключване на актуализиране и блокиране на четене, or чрез журнали за отмяна. С появата на огромни количества информация и разпределени системи стана ясно, че е невъзможно да се осигури транзакционен набор от операции за тях, от една страна, и да се получи висока наличност и бързо време за реакция, от друга.
Освен това дори актуализирането на един запис не гарантира, че всеки друг потребител незабавно ще види промените в системата, тъй като промяната може да се случи например в главния възел и репликата се копира асинхронно в подчинения възел, с който друг потребител върши работа. В този случай той ще види резултата след определен период от време. Това се нарича евентуална последователност и към това се стремят всички най-големи интернет компании в света, включително Facebook и Amazon. Последните гордо заявяват, че максималният интервал, през който потребителят може да види непоследователни данни, е не повече от секунда. Пример за такава ситуация е показан на фигурата:
Логичният въпрос, който възниква в подобна ситуация, е Howво да правим със системи, които класически поставят високи изисквания към атомарността-съгласуваност на операциите и в същото време се нуждаят от бързо разпределени клъстери - финансови, онлайн магазини и т.н.? Практиката показва, че тези изисквания вече не са актуални: ето Howво каза един дизайнер на финансовата банкова система: „Ако наистина чакахме завършването на всяка транзакция в глобалната мрежа от банкомати (АТМ), транзакциите щяха да отнемат толкова време, че клиентите би избягал в ярост. Какво се случва, ако вие и вашият партньор изтеглите пари едновременно и надвишите лимита? „И двамата ще получите парите и ще го оправим по-късно.“
Друг пример е хотелската резервация, показана на снимката. Онлайн магазините, чиято политика за данни предполага евентуална съгласуваност, са длъжни да осигурят мерки в случай на такива ситуации (автоматично разрешаване на конфликти, връщане назад на операции, актуализиране с други данни). На практика хотелите винаги се опитват да поддържат „пул“ от свободни стаи в случай на спешност и това може да бъде решение на спорна ситуация.
Всъщност слабите свойства на КИСЕЛИНАТА не означават, че изобщо не съществуват. В повечето случаи приложение, работещо с релационна база данни, използва транзакция за промяна на логически свързани обекти (поръчка - елементи на поръчка), което е необходимо, тъй като това са различни таблици. С правилния дизайн на модела на данни в база данни NoSQL (агрегатът е поръчка заедно със списък от елементи на поръчка), можете да постигнете същото ниво на изолация при промяна на единичен запис, Howто в релационна база данни.
3.2. Разпределени системи, без споделени ресурси (не споделяйте нищо)
Отново, това не се отнася за графики на бази данни, чиято структура по дефиниция не се разпространява добре в отдалечени възли.
Това е може би основният лайтмотив на развитието на NoSQL бази данни. С лавинообразното нарастване на информацията в света и необходимостта тя да се обработва за разумно време, възникна проблемът с вертикалната мащабируемост - растежът на скоростта на процесора спря на 3,5 GHz, скоростта на четене от диска също расте с бавно темпо, плюс цената на един мощен сървър винаги е повече от общата цена на няколко прости сървъра. В тази ситуация конвенционалните релационни бази данни, дори групирани върху масив от дискове, не са в състояние да решат проблема със скоростта, мащабируемостта и пропускателната способност.
Единственият изход от ситуацията е хоризонталното мащабиране, когато няколко независими сървъра са свързани с бърза мрежа и всеки притежава / обработва само част от данните и / or само част от заявките за четене-актуализация. В тази архитектура, за да увеличите капацитета за съхранение (капацитет, време за реакция, пропускателна способност), трябва само да добавите нов сървър към клъстера - и това е всичко. Шардинг, репликация, толерантност към грешки (резултатът ще бъде получен дори ако един or повече сървъри спрат да отговарят), преразпределението на данни в случай на добавяне на възел се обработва от самата база данни NoSQL.
Ще представя накратко основните свойства на разпределените NoSQL бази данни:
Репликация - копиране на данни към други възли при актуализиране. Позволява едновременно постигане на по-голяма мащабируемост и увеличаване на наличността и безопасността на данните. Прието е да се разделя на два вида:
master-slave :
и peer-to-peer : 
Първият тип предполага добра скалируемост за четене (може да се случи от всеки възел), но немащабируемо писане (само към главния възел). Има и тънкости с осигуряването на постоянна наличност (в случай на главен срив, ръчно or автоматично на негово място се назначава един от останалите възли). Вторият тип репликация предполага, че всички възли са равни и могат да обслужват Howто заявки за четене, така и за запис.
Шардингът е разделянето на данни по възли:
Шардингът често се използва като „патерица“ на релационните бази данни с цел увеличаване на скоростта и пропускателната способност: потребителското приложение разделя данните в няколко независими бази данни и когато потребителят поиска съответните данни, получава достъп до конкретна база данни. В NoSQL базите данни шардингът, подобно на репликацията, се извършва автоматично от самата база данни и потребителското приложение е отделно от тези сложни механизми.
3.3. NoSQL базите данни са предимно с отворен code и са създадени през 21 век
На второ основание Садалай и Фаулър не са класифицирали обектните бази данни като NoSQL (въпреки че http://nosql-database.org/ ги включва в общия списък), тъй като са създадени през 90-те години и никога не са придобor голяма популярност ..
NoSQL движението набира популярност с гигантски темпове. Това обаче не означава, че релационните бази данни стават рудиментарни or нещо архаично. Най-вероятно те ще бъдат използвани и използвани Howто преди активно, но все повече и повече NoSQL бази данни ще действат в симбиоза с тях. Навлизаме в ера на полиглотско постоянство, ера, в която различни хранorща на данни се използват за различни нужди. Вече няма монопол върху релационните бази данни като безспорен източник на данни. Все по-често архитектите избират съхранение въз основа на естеството на самите данни и How искаме да ги манипулираме, Howви обеми информация се очакват. И така всичко става още по-интересно.
По-долу ще се опитаме да разберем работата на разпределена база данни, като използваме NoSQL Cassandra DBMS като пример ...