2.1 Поява на термина NoSQL

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

Най-интересното за термина е, че въпреки факта, че е използван за първи път в края на 90-те години, той придобива истинско meaning във формата, в която се използва сега, едва в средата на 2009 г. Първоначално това беше името на отворен -изходна база данни, създадена от Карло Строци, която съхранява всички данни като ASCII файлове и използва шел скриптове instead of SQL за достъп до данните. Нямаше нищо общо с "NoSQL" в сегашната му форма.

През юни 2009 г. Йохан Оскарсон организира среща в Сан Франциско, за да обсъди новите тенденции на пазара за ИТ съхранение и обработка. Основният стимул за срещата бяха нови продукти с отворен code като BigTable и Dynamo. За ярък знак за среща беше необходимо да се намери обемен и кратък термин, който да се впише идеално в хаштага на Twitter. Един от тези термини е предложен от Eric Evans от RackSpace - "NoSQL". Терминът беше планиран само за една среща и нямаше дълбоко семантично натоварване, но се случи така, че се разпространи в глобалната мрежа като вирусна реклама и стана фактическото име на цяла посока в ИТ индустрията. Между другото, Voldemort (клонинг на Amazon Dynamo), Cassandra, Hbase (аналози на Google BigTable), Hypertable, CouchDB, MongoDB говориха на конференцията.

Java webinar

Заслужава си да подчертаем още веднъж, че терминът „NoSQL“ е напълно спонтанен по произход и няма общоприето определение or научна институция зад него. Това име по-скоро характеризира вектора на развитие на ИТ далеч от релационните бази данни. Това означава Not Only SQL, въпреки че има поддръжници на директната дефиниция на No SQL. Прамод Садалай и Мартин Фаулър се опитаха да групират и систематизират знанията за света на NoSQL в неотдавнашната си книга „NoSQL Destilled“.

2.2 Основни характеристики на NoSQL базите данни

Има няколко общи характеристики за всички NoSQL, тъй като много разнородни системи вече са скрити под етикета NoSQL (може би най-пълният списък може да бъде намерен на http://nosql-database.org/). Много характеристики са характерни само за определени NoSQL бази данни, определено ще спомена това, когато изброявам.

1. Не се използва SQL

Имам предвид ANSI SQL DML, тъй като много бази данни се опитват да използват езици за заявки, подобни на добре познатия любим синтаксис, но никой не е успял да го приложи напълно и е малко вероятно да успее. Въпреки че има слухове за стартиращи компании, които се опитват да внедрят SQL, например в hadup ( http://www.drawntoscalehq.com/ и http://www.hadapt.com/ ).

2. Неструктуриран (без схема)

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

Например, когато преименувате поле в MongoDB:

BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"

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

Първият е да обходите всички documentи и да актуализирате това поле във всички съществуващи documentи. Поради обема на данните този процес протича без ниHowво заключване (сравнимо с командата alter table rename column), така че по време на актуализацията вече съществуващите данни могат да бъдат прочетени от други процеси. Следователно вторият вариант - проверка в codeа на приложението - е неизбежен:

BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum  == null)
totalSum = order.getDouble("totalSum"); // This is the updated model

И вече когато презаписваме, ще запишем това поле в базата данни в нов формат.

Приятна последица от липсата на схема е ефективността на работа с разредени данни. Ако един document има поле date_published, а вторият не, тогава няма да бъде създадено празно поле date_published за втория. Това по принцип е логично, но по-малко очевиден пример са NoSQL бази данни от семейство колони, които използват познатите концепции за таблици / колони. Въпреки това, поради липсата на схема, колоните не се декларират декларативно и могат да се променят/добавят по време на сесията на базата данни на потребителя. Това позволява по-специално използването на динамични колони за внедряване на списъци.

Неструктурираната схема има своите недостатъци - в допълнение към гореспоменатите допълнителни разходи в codeа на приложението при промяна на модела на данни - липсата на всички видове ограничения от базата (не е нула, уникално, ограничение за проверка и т.н.), плюс там са допълнителни трудности при разбирането и контролирането на структурните данни при паралелна работа с базата данни на различни проекти (няма речници отстрани на базата данни). Въпреки това, в бързо променящия се модерен свят, такава гъвкавост все още е предимство. Пример е Twitter, който преди пет години, заедно с туита, съхраняваше само малко допълнителна информация (време, Twitter манипулатор и още няколко byteа метаинформация), но сега, в допълнение към самото съобщение, още няколко килоbyteа метаданни се съхраняват в базата данни.

(По-нататък говорим основно за бази данни ключ-стойност, document и семейство колони, графичните бази данни може да нямат тези свойства)

2.3. Представяне на данни под формата на агрегати (агрегати)

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

Този пример демонстрира агрегации за standardн концептуален релационен модел за електронна търговия „Поръчка – Поръчкови артикули – Плащания – Продукт“. И в двата случая поръчката се комбинира с позиции в един логически обект, като всяка позиция съхранява връзка към продукта и някои от неговите атрибути, например името (такава денормализация е необходима, за да не се изисква обект на продукт при извличане ред - основното правило на разпределените системи е "съединяване" между обекти). В един агрегат плащанията се комбинират с поръчката и са неразделна част от обекта, в другия те се поставят в отделен обект. Това демонстрира основното правило за проектиране на структура от данни в NoSQL бази данни - тя трябва да отговаря на изискванията на приложението и да бъде максимално оптимизирана за най-честите заявки.

Мнозина ще възразят, отбелязвайки, че работата с големи, често денормализирани обекти е изпълнена с множество проблеми, когато се опитват произволни заявки за данни, когато заявките не се вписват в структурата на агрегатите. Какво ще стане, ако използваме поръчки заедно с редове за поръчки и плащания (така работи приложението), но бизнесът ни помоли да преброим колко единици от определен продукт са бor продадени миналия месец? В този случай, instead of да сканираме tableта OrderItem (в случай на релационен модел), ще трябва да извлечем целите поръчки в хранorщето на NoSQL, въпреки че няма да имаме нужда от голяма част от тази информация. За съжаление, това е компромис, който трябва да бъде напequals в разпределена система: не можем да нормализираме данните, Howто в конвенционална система с един сървър,

Опитах се да групирам плюсовете и минусите на двата подхода в table: