NoSQL
From Wikipedia, the free encyclopedia
Remove ads
Нерелационната база данни (на английски: Not only Structured Query Language, NoSQL) предоставя механизъм за съхранение и възстановяване на данни, който използва свободен съгласуван модел за разлика от по-често ползваната релационна база данни. Ползите на този подход включват хоризонтално мащабиране. Нерелационната база данни е най-често добре оптимизирано хранилище, съдържащо информация от тип ключ-стойност. Предназначението ѝ е да улесни процесите по възстановяване и добавяне на информация, с цел оптимизиране на производителността. Нерелационната база данни намира значима и нарастваща роля в real-time web и big data приложенията. Нерелационните системи са наричани „Not only SQL“ в превод „Не само база данни“ за да се подчертае, че те в действителност позволяват употребата на езици за търсене различни, но сходни на тези в SQL.
 | Тази статия се нуждае от подобрение. Необходимо е: дооправяне на превода от ен, оформление. Ако желаете да помогнете на Уикипедия, използвайте опцията редактиране в горното меню над статията, за да нанесете нужните корекции. |
Нерелационната база данни има разпределена и устойчива на повреди архитектура, като обектите с информация се съхраняват на няколко сървъра. По този начин системата може да се предпази като добавя повече сървъри и тогава при повреда на сървър продължава да работи. Този тип база данни се разширява хоризонтално и се използва за управлението на голямо количество от данни, когато производителността (в реално време) е по-важна от последователността (както в индексирането на голям брой документи, обслужващите страници на натоварените сайтове и предоставянето на стриймове).
ACID vs BASE. Нерелационната база данни не могат непременно да дадат пълна гаранция за ACID (Atomicity, Consistency, Isolation, Durability). Обикновено съгласуваността е гарантирана или трансакциите са ограничени до един обект с информация. Това означава, че ако се даде достатъчно дълъг период от време, по време на който не се пращат промени, може да се очаква всички обновления да се разпространят в системата.
Remove ads
История
За първи път терминът нерелационна база данни бива използван от Карло Строци през 1998 г. за да наименува неговата лека релационна база данни с отворен код, която не излага стандартния SQL интерфейс.[1] Поради отклоняването на NoSQL движението от релационния модел, Строци предлага като по-подходящо наименованието „NoREL“.[2]
Ерик Еванс (по това време служител на Rackspace) отново използва термина нерелационна база данни в началото на 2009 г., когато Йоан Оскарсон от музикалния уебсайт Last.fm поисква от него да организира събитие относно разпределени бази от данни[3] с отворен код. Името използвано да постави етикет на появилите се и нарастващи по брой нерелационни, разпределени data stores (хранилище на данни на набор от интегрирани обекти), които не се опитват да гарантират ACID, който от своя страна е ключов атрибут на класическите релационни системи за управление на бази данни.[4]
Remove ads
Класификация
Съществуват различни подходи за класифициране на нерелационните база данни с различни категории и подкатегории. Поради различните подходи за определяне на нефункционалните изисквания и съвкупността от характеристики е трудно да се направи конкретен преглед на нерелационните бази данни. Все пак, класификацията, която може би е най-общоприета се базира на модела на данните. Част от нерелационните база данни и техните прототипи, класифицирани на базата на модела на данните са представени в следния списък:
Remove ads
Класификации, базирани на модела на данните
Щефан Йен в своя пост „A yes for NoSQL taxonomy“ предлага следната класификация:
Класификация, която се базира на функционалност
Бен Скофилд категоризира нерелационните бази данни (cf. [Sco10]) въз основа на нефункционални категори и („(il)ities“) и рейтинг на съвкупността от функциите, които покриват.
Remove ads
Документни хранилища
Централната концепция, която стои зад документното хранилище е нотацията за „документ“. Докато всяка документно-ориентирана имплементация се различава според детайлите на тази дефиниция, като цяло, всички те приемат, че документите енкапсулират и кодират данните (или информацията) в някакви стандартни формати.
Използваните формати са: XML, YAML, JSON както и бинарни формати като BSON, PDF and Microsoft Office документи (MS Word, Excel и др.).
Различните имплементации предлагат различен подход към организирането и групираненето на документите:
- Колекции
- Тагове
- Невидими метаданни
- Йерархия на директориите
Ако направим аналогия с релационните бази данни, колекциите могат да се възприемат като таблици, а документите могат да се приемат за записи. Нерелационните и релационните база данни все пак има съществена разлика: всеки запис в таблицата при релационните бази данни има еднаква последователност от полета, докато документите в колекцията могат да имат полета, които са напълно различни.
Адресът на документите се представя в базата данни чрез уникален ключ, които идентифицира документа. Една от другите основни характеристики на документно-ориентираните бази данни е, че освен простото търсенето по ключ-документ или ключ-стойност, което може да се използва за извличане на документа, базите данни предоставят и потребителски интерфейс или език за заявки, които ще позволи докуметите да бъдат откривани въз основа на тяхното съдържание. Някои NoSQL документни хранилища предлагат алтернативен начин за извличане на информация, като използват MapReduce технологии. В CouchDB използването на MapReduce е задължително, ако се цели документиете да бъдата извличани на базата на съдържание. Това се нарича „Изгледи“ и представлява индексирана колекция с резултата от алгоритмите на MapReduce.
Remove ads
Граф бази данни
Граф базите данни (на английски: Graph database) са създадени за данни, чиито елементи са добре представени както графи (взаимосвързани елементи с неопределен брой отношения между тях). Типовете отношения могат да бъдат например социални отношения, връзки между линиите на градския транспорт, пътни карти, мрежови топологии и др.
Remove ads
Ключ–стойност хранилища
Ключ–стойност хранилищата (на английски: key-value stores) позволяват да съхранявате данни във формат, който не е таблица или схема. Данните могат да бъдат записани като стандартни типове данни, ползвани в програмните езици или като обект. Ето защо няма нужда да се използва фиксиран модел за данни. Съществуващите видове ключ–стойност хранилища са:
Условно консистентни
Йерархични
Съхраняващи данните в памет с произволен достъп
Съхраняващи на твърдия диск
Подредени
Remove ads
Обектни бази данни
Източници
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads