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

Еволюцията на NoSQL

Проблемът с мащабируемостта на SQL беше признат от компаниите Web 2.0 с огромни, нарастващи нужди от данни и инфраструктура, като Google, Amazon и Facebook. Те излязоха със собствени решения на проблема - технологии като BigTable , DynamoDB , и Касандра .

Този нарастващ интерес доведе до редица системи за управление на бази данни NoSQL (СУБД), с фокус върху производителността, надеждността и последователността. Редица съществуващи структури за индексиране бяха повторно използвани и подобрени с цел подобряване на производителността при търсене и четене.

Първо, имаше собствени (затворени) типове бази данни NoSQL, разработени от големи компании, за да отговорят на техните специфични нужди, като например BigTable на Google, за която се смята, че е първата NoSQL система и DynamoDB на Amazon.

Успехът на тези собствени системи инициира разработването на редица подобни системи с отворен код и собствени бази данни, като най-популярните са Hypertable, Cassandra, MongoDB, DynamoDB, HBase и Redis.

Какво прави NoSQL различен?

Една ключова разлика между базите данни NoSQL и традиционните релационни бази данни е фактът, че NoSQL е форма на неструктурирано съхранение .

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

Предимства и недостатъци на базите данни NoSQL

Предимства

Базите данни NoSQL имат много предимства в сравнение с традиционните, релационни бази данни.

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

За разлика от релационните бази данни, базите данни NoSQL се базират на двойки ключ-стойност.

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

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

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

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

Недостатъци

Разбира се, базите данни NoSQL не са перфектни и не винаги са правилният избор.

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

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

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

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

NoSQL срещу релационни бази данни

Тази таблица предоставя кратко сравнение на характеристиките между NoSQL и релационни бази данни:

Особеност	Бази данни NoSQL	Релационни бази данни
производителност	Високо	Ниска
Надеждност	Бедно	добре
Наличност	добре	добре
Последователност	Бедно	добре
Хранилище за данни	Оптимизиран за огромни данни	Средни до големи
Мащабируемост	Високо	Високо (но по-скъпо)

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

Типове хранилища на данни NoSQL

Магазин за ключови стойности

В типа хранилище на ключова стойност се използва хеш таблица, в която уникален ключ сочи към елемент.

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

Ключ	Стойност
'Белфаст'	{„Университет в Ълстър, кампус в Белфаст, Йорк Стрийт, Белфаст, BT15 1ED“}
„Колерейн“	{„Университет в Ълстър, кампус на Coleraine, Cromore Road, Co. Londonderry, BT52 1SA“}

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

Всичко, което е необходимо за справяне с елементите, съхранявани в базата данни, е ключът. Данните се съхраняват под формата на низ, JSON или BLOB (двоичен голям обект).

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

Най-известната база данни NoSQL, която е изградена върху хранилище на ключови стойности, е DynamoDB на Amazon.

Магазин за документи

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

Има обаче ключови разлики между двете.

В Document Stores стойностите (документите) осигуряват кодиране на съхранените данни. Тези кодировки могат да бъдат XML, JSON или BSON (двоично кодиран JSON) .

Също така може да се направи заявка въз основа на данни.

Най-популярното приложение за бази данни, което разчита на Document Store, е MongoDB.

Магазин за колони

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

Магазин за колони се състои от едно или повече семейства колони, които логически групират определени колони в базата данни. Ключът се използва за идентифициране и насочване към определен брой колони в базата данни, с атрибут пространство на ключовете, който определя обхвата на този ключ. Всяка колона съдържа купчини имена и стойности, подредени и разделени със запетая.

Магазините за колони имат бърз достъп за четене / запис до съхраняваните данни. В хранилище на колони редове, които съответстват на една колона, се съхраняват като единичен запис на диск. Това прави по-бърз достъп по време на операции за четене / запис.

Най-популярните бази данни, които използват хранилището на колони, включват BigTable на Google, HBase и Cassandra.

Графична основа

В база данни на Graph Graph NoSQL се използва насочена структура на графиката за представяне на данните. Графиката се състои от ръбове и възли.

Формално графика е представяне на набор от обекти, където някои двойки от обектите са свързани чрез връзки. Взаимосвързаните обекти са представени от математически абстракции, наречени върхове, а връзките, които свързват някои двойки върхове, се наричат ​​ръбове. Казва се, че набор от върхове и ръбовете, които ги свързват, са графика.

Това илюстрира структурата на база данни на графика, която използва ръбове и възли за представяне и съхраняване на данни. Тези възли са организирани от някои взаимоотношения помежду си, което е представено с ръбове между възлите. Както възлите, така и връзките имат определени дефинирани свойства.

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

В момента InfoGrid и InfiniteGraph са най-популярните бази данни за графики.

Системи за управление на база данни NoSQL

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

	Тип съхранение	Метод на заявката	Интерфейс	Програмен език	Отворен код	Репликация
Касандра	Магазин за колони	Икономичен API	Пестеливост	Java	Да	Асинхронизиране
MongoDB	Магазин за документи	Заявка за Монго	TCP / IP	C ++	Да	Асинхронизиране
HyperTable	Магазин за колони	HQL	Пестеливост	Java	Да	Асинхронизиране
CouchDB	Магазин за документи	MapReduce	ПОЧИВКА	Ерланг	Да	Асинхронизиране
BigTable	Магазин за колони	MapReduce	TCP / IP	C ++	Не	Асинхронизиране
HBase	Магазин за колони	MapReduce	ПОЧИВКА	Java	Да	Асинхронизиране

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

Други системи за бази данни NoSQL, като Apache CouchDB, също са база данни от тип хранилище на документи и споделят много функции с MongoDB, с изключение на това, че базата данни може да бъде достъпна с помощта на RESTful API.

REST е архитектурен стил, състоящ се от координиран набор от архитектурни ограничения, приложени към компоненти, съединители и елементи от данни в рамките на World Wide Web. Той разчита на комуникационен протокол за клиент-сървър без възможност за съхранение (напр. HTTP протокол).

RESTful приложения използват HTTP заявки за публикуване, четене на данни и изтриване на данни.

Що се отнася до базовите бази данни на колони, Hypertable е база данни NoSQL, написана на C ++ и се основава на BigTable на Google.

Hypertable поддържа разпределение на хранилища за данни между възли, за да увеличи максимално мащабируемостта, точно както MongoDB и CouchDB.

Една от най-често използваните бази данни NoSQL е Cassandra, разработена от Facebook.

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

Вместо да предоставят задълбочен поглед на всяка NoSQL СУБД, Cassandra и MongoDB, две от най-широко използваните системи за управление на бази данни NoSQL, ще бъдат разгледани в следващите подраздели.

Касандра

Cassandra е система за управление на бази данни, разработена от Facebook.

Целта зад Cassandra беше да се създаде СУБД, която няма нито една точка на отказ и осигурява максимална наличност.

Cassandra е предимно база данни за колони. Някои проучвания посочват Касандра като хибридна система, вдъхновена от BigTable на Google, която е база данни за колони, и DynamoDB на Amazon, която е база данни с ключови стойности.

Това се постига чрез осигуряване на система ключ-стойност, но ключовете в Касандра сочат към набор от семейства колони, като се разчита на разпределената файлова система BigTable на Google и функциите за наличност на Dynamo (разпределена хеш таблица).

Cassandra е проектирана да съхранява огромни количества данни, разпределени между различни възли. Cassandra е СУБД, предназначена да обработва огромни количества данни, разпределени в много сървъри, като същевременно предоставя високодостъпна услуга без нито една точка на отказ, което е от съществено значение за голяма услуга като Facebook.

Основните характеристики на Касандра включват:

• Няма нито една точка на провал. За да бъде постигнато това, Касандра трябва да работи на клъстер от възли, а не на една машина. Това не означава, че данните за всеки клъстер са еднакви, но софтуерът за управление е такъв. Когато се случи повреда в един от възлите, данните за този възел ще бъдат недостъпни. Други възли (и данни) обаче ще продължат да бъдат достъпни.
• Разпределено хеширане е схема, която осигурява функционалност на хеш таблица по начин, по който добавянето или премахването на един слот не променя значително картографирането на ключове към слотовете. Това осигурява възможността за разпределяне на товара към сървъри или възли според техния капацитет и от своя страна минимизиране на престоя.
• Относително лесен за използване клиентски интерфейс . Касандра използва Apache Thrift за своя клиентски интерфейс. Apache Thrift предоставя междуезичен RPC клиент, но повечето разработчици предпочитат алтернативи с отворен код, изградени върху Apple Thrift, като Hector.
• Други функции за наличност. Една от характеристиките на Касандра е репликацията на данни. По принцип той отразява данни на други възли в клъстера. Репликацията може да бъде произволна или специфична, за да се увеличи максимално защитата на данните чрез поставяне на възел в различен център за данни, например. Друга характеристика, открита в Cassandra, е политиката за разделяне. Политиката за разделяне решава къде на кой възел да поставите ключа. Това може да бъде произволно или по ред. Когато използва и двата типа политики за разделяне, Cassandra може да постигне баланс между балансиране на натоварването и оптимизация на производителността на заявките.
• Последователност. Функции като репликацията правят последователността предизвикателна. Това се дължи на факта, че всички възли трябва да бъдат актуализирани по всяко време с най-новите стойности или в момента, в който се задейства операция за четене. В крайна сметка обаче Касандра се опитва да поддържа баланс между действията за репликация и действията за четене / запис, като предоставя тази адаптивност на разработчика.
• Действия за четене / писане. Клиентът изпраща заявка до един възел на Касандра. Възелът, според политиката за репликация, съхранява данните в клъстера. Всеки възел първо извършва промяната на данните в дневника на фиксиране и след това актуализира структурата на таблицата с промяната, и двете извършени синхронно. Операцията за четене също е много подобна, заявка за четене се изпраща до един възел и този единичен възел е този, който определя кой възел съдържа данните, в съответствие с политиката за разделяне / разположение.

MongoDB

MongoDB е база данни, ориентирана към документи, без схеми, написана на C ++. Базата данни е базирана на хранилище на документи, което означава, че съхранява стойности (наричани документи) под формата на кодирани данни.

Изборът на кодиран формат в MongoDB е JSON. Това е мощно, защото дори ако данните са вложени в JSON документи, те пак ще бъдат подлежи на заявка и индексируем .

Следващите подраздели описват някои от основните функции, налични в MongoDB.

Парчета

Sharding е разделянето и разпространението на данни в множество машини (възли). Шард е колекция от MongoDB възли, за разлика от Cassandra, където възлите са симетрично разпределени. Използването на парчета също означава възможност за хоризонтално мащабиране на множество възли. В случай, че има приложение, използващо един сървър на база данни, то може да бъде преобразувано в рязък клъстер с много малко промени в оригиналния код на приложението, тъй като начинът на рязане се извършва от MongoDB. oftware е почти напълно отделен от публичните API, изложени на клиентската страна.

Mongo Query Language

Както беше обсъдено по-рано, MongoDB използва RESTful API. За извличане на определени документи от db колекция се създава документ за заявка, съдържащ полетата, на които трябва да съвпадат желаните документи.

Действия

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

Подобно на Касандра, парчето в MongoDB има схема за репликация на данни, която създава набор от реплики на всеки парче, който съдържа абсолютно същите данни. В MongoDB има два типа схеми за реплика: репликация Master-Slave и Replica-Set репликация. Replica-Set осигурява повече автоматизация и по-добро боравене с откази, докато Master-Slave понякога изисква намеса на администратора. Независимо от схемата за репликация, във всеки момент от време в набор от реплики само един парче действа като първичен парче, всички останали парчета реплики са вторични парчета. Всички операции за писане и четене преминават към основния парче и след това се разпределят равномерно (ако е необходимо) към останалите вторични парчета в комплекта.

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

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

Индексиращи структури за NoSQL бази данни

Индексирането е процес на свързване на ключ с местоположението на съответния запис на данни в СУБД. Има много структури за индексиране на данни, използвани в базите данни NoSQL. Следващите раздели ще обсъдят накратко някои от най-често срещаните методи; а именно B-Tree индексиране, T-Tree индексиране и O2-Tree индексиране.

Индексиране на B-Tree

B-Tree е една от най-често срещаните индексни структури в СУБД.

В B-дърветата вътрешните възли могат да имат променлив брой дъщерни възли в рамките на определен предварително определен диапазон.

Една от основните разлики от другите дървесни структури, като AVL, е, че B-Tree позволява на възлите да имат променлив брой дъщерни възли, което означава по-малко балансиране на дървета, но повече загубено пространство.

B + -Dree е един от най-популярните варианти на B-Trees. B + -Dree е подобрение спрямо B-Tree, което изисква всички клавиши да се намират в листата.

Индексиране на T-Tree

Структурата на данните на T-Trees е проектирана чрез комбиниране на функции от AVL-Trees и B-Trees.

AVL-дървета са вид самобалансиращи се бинарни дървета за търсене, докато B-дърветата са небалансирани и всеки възел може да има различен брой деца.

В T-Tree структурата е много подобна на AVL-Tree и B-Tree.

Всеки възел съхранява повече от един кортеж {ключ-стойност, указател}. Също така, бинарното търсене се използва в комбинация с многобройните възли за постигане на по-добро съхранение и производителност.

T-Tree има три вида възли: T-възел, който има дясно и ляво дете, листен възел без деца и полулистов възел само с едно дете.

Смята се, че T-Trees имат по-добри общи резултати от AVL-Trees.

Индексиране на O2-дърво

Дървото O2 е основно подобрение спрямо червено-черните дървета, форма на дърво за двоично търсене, в което листните възли съдържат кортежи {ключова стойност, показалец}.

O2-Tree беше предложено да подобри ефективността на текущите методи за индексиране. O2-дърво от порядък m (m ≥ 2), където m е минималната степен на дървото, отговаря на следните свойства:

• Всеки възел е или червен, или черен. Коренът е черен.
• Всеки листен възел е оцветен в черно и се състои от блок или страница, която съдържа двойки „ключова стойност, запис-указател“.
• Ако възелът е червен, тогава и двете му деца са черни.
• За всеки вътрешен възел всички прости пътища от възела до низходящи листови възли съдържат еднакъв брой черни възли. Всеки вътрешен възел съдържа една стойност на ключ.
• Листовите възли са блокове, които имат между ⌈m / 2⌉ и m двойки „ключ-стойност, запис-указател“.
• Ако едно дърво има един възел, то то трябва да е лист, който е коренът на дървото и може да има между 1 до m ключови елементи от данни.
• Листовите възли са двойно свързани в посока напред и назад.

Тук виждаме директно сравнение на производителността между O2-Tree, T-Tree, B + -Tree, AVL-Tree и Red-Black Tree:

Редът на използваното T-Tree, B + -Dree и O2-Tree беше m = 512.

Записва се време за операции на търсене, вмъкване и изтриване с коефициенти на актуализация, вариращи между 0% -100% за индекс от 50M записи, като операциите водят до добавяне на още 50M записи към индекса.

Ясно е, че при съотношение на актуализация от 0-10%, B-Tree и T-Tree се представят по-добре от O2-Tree. С увеличаването на съотношението на актуализация обаче индексът O2-Tree се представя значително по-добре от повечето други структури с данни, като структурите B-Tree и Red-Black Tree страдат най-много.

Случаят за NoSQL?

Бързо въведение в базите данни NoSQL, подчертавайки ключовите области, в които традиционните релационни бази данни не достигат, води до първото извеждане:

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

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

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

Не всички системи за бази данни NoSQL се представят по-добре от релационните бази данни.

MongoDB и Cassandra имат подобна и в повечето случаи по-добра производителност от релационните бази данни при операции за запис и изтриване.

Няма пряка връзка между типа на хранилището и производителността на СУБД NoSQL. Внедряванията на NoSQL претърпяват промени, така че производителността може да варира.

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

Въпреки че не мога да предложа окончателна присъда за ефективността, имаме няколко точки, които трябва да имате предвид:

• Традиционното индексиране на B-Tree и T-Tree често се използва в традиционните бази данни.
• Едно проучване предлага подобрения и подобрения чрез комбиниране на характеристиките на множество структури за индексиране, за да се получи O2-Tree.
• O2-Tree превъзхожда останалите структури в повечето тестове, особено с огромни набори от данни и високи коефициенти на актуализация.
• Структурата B-Tree осигури най-лошото представяне от всички структури за индексиране, обхванати в тази статия.

По-нататъшна работа може и трябва да се направи за подобряване на последователността на NoSQL СУБД. Интеграцията на двете системи, NoSQL и релационните бази данни, е област за допълнително изследване.

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

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

Свързани: Платформа за бизнес разузнаване: Урок, използващ агрегиращия тръбопровод MongoDB