Nosql, бази данни: преглед, примери и приложения

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

Собствените типове са нова методология за разработване на нерелационни бази данни NoSQL, прилагана от големи компании за задоволяване на корпоративни нужди, като например BigTable на Google, която се счита за първата система NoSQL, и Amazon DynamoDB. Успехът на тези системи доведе до появата на редица подобни системи за бази данни с отворен код и патентовани системи за бази данни, най-популярните от които са Hypertable, Cassandra, MongoDB, DynamoDB,

Еволюция на NoSQL

Проблемът с мащабируемостта на SQL е признат от Web 2 компании.0 с огромни, нарастващи нужди от данни и инфраструктура, като Google, Amazon и Facebook. Те са намерили свои собствени решаване на проблеми, въвеждане на технологиите BigTable, DynamoDB и Cassandra. Нарастващият интерес доведе до появата на редица системи за управление на бази данни NoSQL (СУБД) с акцент върху производителността, надеждността и последователността. Редица съществуващи структури за индексиране са използвани отново и са подобрени, за да се подобри производителността при търсене и четене.

Терминът е въведен от Калор Строци през 1998 г., а през 2009 г. е възобновен от Ерик Евънс от Rackspace, за да се справи с проблемите на уеб базираните компании с големи обеми транзакции и информация.

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

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

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

Видове информационни хранилища

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

Всички, какво е необходимо да работите с елементи, съхранявани в базата данни - това е ключовият момент. Данните се съхраняват в Тип JSON низ или BLOB (голям двоичен обект). един от най-големият Недостатъкът на тази форма е липсата на последователност на ниво база данни. Това може да бъде добавено по време на разработката на NoSQL база данни от програмистите със собствен код, но изисква и повече усилия поради сложността и времето за реализация. Най-известната NoSQL база данни, изградена на базата на хранилище за ключове и стойности, е Amazon DynamoDB.

Хранилищата за документи са подобни на хранилищата за ключове и стойности, тъй като не съдържат схема и се основават на модел на стойността. Следователно и двата типа имат еднакви предимства и недостатъци. И в двата случая липсва последователност на ниво база данни, което пречи на приложенията да предоставят по-стабилни функции. Въпреки това има някои основни разлики между тях. В хранилищата за документи стойностите (документите) осигуряват кодиране на съхраняваните данни. Кодировките могат да бъдат XML, JSON или BSON (двоичен JSON). Най-популярното приложение за бази данни, което използва хранилище за документи, е MongoDB.

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

Колонните хранилища имат бърз достъп за четене/запис до съхраняваните данни. В него колоните на един ред съответстват на една колона и се съхраняват като един запис на диска. Това осигурява по-бърз достъп при операции за четене/запис. Най-популярните бази данни, които използват хранилището за колони на NoSQL бази данни, примери: Google BigTable, HBase и Cassandra.

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

Принцип на работа на DB

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

1. Хоризонтална мащабируемост с възможност за увеличаване на размера им, което увеличава пространството за съхранение в базата данни без да жертвате за работа.
2. Облачна технология. Повечето бази данни NoSQL съхраняват данните си в облака, за да освободят повече пространство. Те имат и възли за репликация на информация.
3. Ефективно използване на ресурсите. Понастоящем компаниите са в процес на технологичен преход, така че е почти задължително да разполагат с база данни, която им позволява да прилагат нови технологични инструменти. Данните от NoSQL са подходящи именно за това - гъвкавият модел позволява бързо адаптиране към нови инструменти.
4. Схема за безплатно функциониране. NoSQL нямат твърда система, така че програмистите имат свободата да променят данните при необходимост. Това означава, че ако трябва да промените дефиницията на поле или тип данни, това не е проблем, за разлика от SQL базите данни, където подобни промени са много сложни.
5. Скорост на реакция. Скоростта на една база данни се измерва чрез латентността, която е времето за отговор, а NoSQL се стреми да намали латентността колкото е възможно повече.
6. Използване на индекси. SQL и NoSQL се нуждаят от индекси, защото не могат да се правят заявки за милиони записи, ако не е конфигуриран индекс. В NoSQL индексите се генерират под формата на B-дърво, т.е. възлите са балансирани и по този начин се увеличава скоростта на търсене.

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

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

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

REST е архитектурен стил, състоящ се от координиран набор от архитектурни ограничения, прилагани към компоненти, конектори и елементи на данни в уеб. Той се основава на комуникационен протокол с възможност за кеширане "клиент-сървър" без съхраняване на състояние, като например протокола HTTP. RESTful приложенията използват HTTP заявки за публикуване, четене и изтриване на данни. Що се отнася до бази данни с колони, Hypertable е NoSQL база данни, написана на C ++ и базирана на Google BigTable. Hypertable поддържа разпределение на съхранението по възли за максимална мащабируемост, подобно на MongoDB и CouchDB.

Хибридна система Cassandra

Една от най-широко използваните NoSQL бази данни е Cassandra, разработена от Facebook. Целта на Cassandra беше да създаде СУБД, която няма единствена точка на отказ и осигурява максимална наличност. Cassandra е предимно база данни за съхранение на колони. В някои проучвания тя се споменава като хибридна система, базирана на Google BigTable, която е база данни за съхранение на колони, и Amazon DynamoDB, която е от типа ключ-стойност. Ключовете в Cassandra сочат към набор от фамилии колони, разчитащи на разпределената файлова система Google BigTable и функциите за достъпност на Dynamo (разпределена хеш таблица).

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

1. Няма единична точка на отказ. За тази цел тя трябва да работи на клъстер от възли, а не на една машина. Това не означава, че данните във всеки клъстер са еднакви. Когато в един възел възникне повреда, данните в този възел са недостъпни. Въпреки това други възли и данни все още ще бъдат на разположение.
2. Разпределеното хеширане е схема, която осигурява функционалност на хеш-таблицата по такъв начин, че добавянето или премахването на един слот не променя значително съпоставянето на ключовете към слотовете. Тя ви позволява да балансирате натоварването на сървърите или възлите според техния капацитет и да сведете до минимум времето за престой.
3. Сравнително лесен за използване клиентски интерфейс. Той използва Apache Thrift за своя клиентски интерфейс, който предоставя RPC клиент на няколко езика, но повечето разработчици предпочитат алтернативи с отворен код, базирани на Apple Thrift, като Hector.
4. Репликация на данни. По същество той отразява данни за други възли в клъстера. Репликирането може да бъде ad hoc или да бъде определено така, че да се постигне максимална защита на данните, например чрез разполагане в друг възел на центъра за данни.
5. Политиката на разделяне решава къде и в кой възел да се постави ключът. Това може да бъде случаен или подреден процес. С двата вида политики за разделяне Cassandra може да намери баланс между натоварването и оптимизираната производителност на заявките.
6. Последователност. Репликацията затруднява последователността. Това е така, защото всички възли трябва да бъдат актуализирани във всеки един момент с най-новите стойности или по време на операция за четене.
7. Операции за четене/запис. Клиентът изпраща заявка до един възел. В съответствие с политиката за репликация даден възел съхранява данни в клъстер. Всеки възел първо променя данните в дневника на предаването и актуализира структурата на таблицата, като и двете промени се извършват синхронно. Изпраща се заявка за четене до един възел, който съдържа данни в съответствие с политика за разделяне/разпределение.

Структури за индексиране

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

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

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

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

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

Често срещани грешки в приложенията за бази данни

Има три често срещани грешки, които организациите правят, когато става въпрос за NoSQL:

1. NoSQL е нещо повече от мащабируемост, не можете да приравните NoSQL към уеб мащаба. Родоначалници на съвременните нерелационни бази данни са компании като Google и Amazon, които се фокусират върху решаването на проблеми с мащабируемостта в уеб среда.
2. Разработчиците трябва да се развиват. В един високотехнологичен уеб проект лошо подбран екип за интеграция създаде огромен проблем, чието отстраняване отне време и милиони долари.
3. Сложна дистрибуция. Няма заместител на знанията и опита в областта на прилагането или администрирането. Случва се заявка, която работи бързо на локална машина за разработка, да не може да се мащабира хоризонтално на стотици машини. Модерното приложение има разпределена архитектура и много потребители едновременно, което изисква бързи реакции.

Предимства на NoSQL

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

1. имат проста и гъвкава структура.
2. Не разполага със схеми.
3. Основава се на двойки "ключ-стойност".
4. Някои типове включват колонарни, документални, ключ-стойностни, графични, обектни, XML и други режими на данни.
5. Всяка стойност в базата данни обикновено има ключ. Някои хранилища позволяват на разработчиците да съхраняват сериализирани обекти, а не само прости символни стойности.
6. NoSQL с отворен код не изискват скъпи лицензионни такси и могат да работят на евтин хардуер, което прави внедряването им рентабилно.
7. С NoSQL, независимо дали са с отворен код или патентовани, разширяването е по-лесно и по-евтино, отколкото при работа с При релационните бази данни. Това става чрез хоризонтално мащабиране и разпределяне на натоварването между всички възли, а не чрез вертикално мащабиране, което обикновено се прави в системите за релационни бази данни, и замяна на основния хост с по-мощен.

Недостатъци на системата No-system

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

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

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

Приложения за бази данни NoSQL

Академиците, инженерите, софтуерните архитекти, дизайнерите на приложения и програмистите изискват по-задълбочени познания за структурите от данни, които досега не се изискваха за релационните бази данни. Пазарните лидери са - Hadoop и MongoDB, следвани от "Касандра", "Redis", CouchDB и "Riacom". Настоящите проучвания показват, че има два продукта на NOSQL, които доминират сред системните инженери, архитектите софтуер, разработчици сред дузина подобни технологии са MongoDB и Hadoop.

Пазарът показва, че големите компании използват нови методологии за разработване на бази данни NoSQL и ги интегрират в своите продукти (Oracle, IBM). Пазарът на бази данни бавно се превръща в стандарт с PasS, Redis и MongoDB, Едлих. Продукти като Neo4j, MongoDb и CouchDb са получили подкрепа и инвестиции от рисков капитал.