NoSQL

от Уикипедия, свободната енциклопедия
Направо към: навигация, търсене

Нерелационната база данни (на английски: Not only Structured Query Language, NoSQL) предоставя механизъм за съхранение и възстановяване на данни, който използва свободен съгласуван модел за разлика от по–често ползваната релационна база данни. Ползите на този подход включват изчистен дизайн, хоризонтално мащабиране и фин контрол върху наличнaта информация. Нерелационната база данни е най-често добре оптимизирано хранилище, съдържащо информация от тип ключ-стойност. Предназначението ѝ е да улесни процесите по възстановяване и добавяне на информация, с цел оптимизиране на производителността в условия на неумишлено забавяне на системата и въвеждане на прекалено големи количества данни. Нерелационната база данни намира значима и нарастваща роля в real-time web и big data приложенията. Нерелационните системи са наричани „Not only SQL“ в превод „Не само база данни“ за да се подчертае, че те в действителност позволяват употребата на езици за търсене различни, но сходни на тези в SQL.

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

ACID vs BASE. Нерелационната база данни не могат непременно да дадат пълна гаранция за ACID (Atomicity, Consistency, Isolation, Durability). Обикновено съгласуваността е гарантирана или транзакциите са ограничени до един обект с информация. Това означава, че ако се даде достатъчно дълъг период от време, по време на който не се пращат промени, може да се очаква всички обновления да се разпространят в системата.

История[редактиране | edit source]

За първи път терминът нерелационна база данни бива използван от Карло Строци през 1998 г. за да наименува неговата лека релационна база данни с отворен код, която не излага стандартния SQL интерфейс.[1] Строци предлага, че поради отклоняването на NoSQL движението от релационния модел, следователно би трябвало да бъде наименуван по – подходящо като „NoREL“.[2]

Ерик Еванс (по това време служител на Rackspace) отново използва терминът нерелационната база данни в началото на 2009 г., когато Йоан Оскарсон от музикалния уебсайт Last.fm поисква от него да организира събитие относно разпределени бази от данни[3] с отворен код. Името използвано да постави етикет на наскоро появилите се и нарастващи по брой нерелационни, разпределени data stores (хранилище на данни на набор от интегрирани обекти), които не се опитват да гарантират ACID, който от своя страна е ключов атрибут на класическите релационни системи за управление на бази данни.[4]

Класификация[редактиране | edit source]

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

  • Колона: Hbase, Cassandra, Accumulo
  • Документ : MongoDB, Couch, Raven
  • Ключ - стойност: Dynamo, Riak, Azure, Redis, Cache, GT.m
  • Граф: Neo4J, Allegro, Virtuoso, Bigdata


По-пълен списък с над 150 различни вида нерелационни база данни е достъпен от следния линк: http://nosql-database.org/


Класификации, базирани на модела на данните[редактиране | edit source]

Щефан Йен в своя пост "A yes for NoSQL taxonomy" предлага следната класификация:

Тип Бази данни, в които се използва
KV Хранилище Keyspace Flare SchemaFree RAMCloud
KV Store - Eventually consistent Dynamo Voldemort Dynomite SubRecord Mo8onDb Dovetaildb
KV Подредено хранилище (KV Store - Ordered) TokyoTyrant Lightcloud NMDB Luxio MemcacheDB Actord
KV кеш ( KV Cache) Memcached Repcached Coherence Infinispan EXtremeScale JBossCache Velocity Terracoqua
Tuple хранилище ( хранилище от тип наредена n-орка) (Tuple Store) Gigaspaces Coord ApacheRiver
Обектни бази данни (Object Database) ZopeDB DB40 Shoal
Документно хранилище (Document Store) CouchDB MongoDB Jackrabbit XML-Databases ThruDB CloudKit Prsevere Riak-Basho Scalaris
Широко-колонно хранилище (Wide Columnar Store) Bigtable Hbase Cassandra Hypertable KAI OpenNeptune Qbase KDI

Класификация, която се базира на функционалност[редактиране | edit source]

Бен Скофилд категоризира нерелационните бази данни (cf. [Sco10]) въз основа на нефункционални категори и („(il)ities“) и рейтинг на съвкупността от функциите, които покриват.

Модел на данните Производителност Мащабируемост Гъвкавост Сложност Функционалност
Хранилище ключ-стойност Висока Висока Висока Няма Променлива

(нулева)

Колонно хранилище Висока Висока Средна Ниска Минимална
Документно хранилище Висока Променлива(висока) Висока Ниска Променлива (ниска)
Граф бази данни Променива променлива Висока Висока Теория на графите
Релациоонни бази данни Променлива променлива Ниска Средна Релационна алгебра


Примери[редактиране | edit source]

Документни хранилища[редактиране | edit source]

Централната концепция, която стои зад документното хранилище е нотацията за „документ“. Докато всяка документно-ориентирана имплементация се различава според детайлите на тази дефиниция, като цяло, всички те приемат, че документите енкапсулират и кодират данните (или информацията) в някакви стандартни формати. Използваните формати са: XML, YAML, JSON както и бинарни формати като BSON, PDF and Microsoft Office документи (MS Word, Excel и др.).

Различните имплементации предлагат различен подход към организирането и групираненето на документите:

  • Колекции
  • Тагове
  • Невидими метаданни
  • Йерархия на директориите

Ако направим аналогия с релационните бази данни, колекциите могат да се възприемат като таблици, а документите могат да се приемат за записи. Нерелационните и релационните база данни все пак има съществена разлика: всеки запис в таблицата при релационните бази данни има еднаква последователност от полета, докато документите в колекцията могат да имат полета, които са напълно различни.

Адресът на документите се представя в базата данни чрез уникален ключ, които идентифицира документа. Една от другите основни характеристики на документно-ориентираните бази данни е, че освен простото търсенето по ключ-документ или ключ-стойност, което може да се използва за извличане на документа, базите данни предоставят и потребителски интерфейс или език за заявки, които ще позволи докуметите да бъдат откривани въз основа на тяхното съдържание. Някои NoSQL документни хранилища предлагат алтернативен начин за извличане на информация, като използват MapReduce технологии. В CouchDB използването на MapReduce е задължително, ако се цели документиете да бъдата извличани на базата на съдържание. Това се нарича „Изгледи“ и представлява индексирана колекция с резултата от алгоритмите на MapReduce.

Име Език Бележки
BaseX Java, XQuery XML база данни XML database
Cloudant Erlang, Java, Scala, C JSON хранилище (online услуга)
Clusterpoint C++ XML, добавен за пълно текстово търсене Full text search
Couchbase Server Erlang, C++ Поддържа JSON и документи в бинарен вид
Apache CouchDB Erlang JSON база данни
djondb[5][6][7] C++ JSON, ACID документно хранилище
ElasticSearch Java JSON, Търсачки
eXist Java, XQuery XML база данни
Jackrabbit Java Реализирана е като Java Content Repository
IBM Lotus Notes и Lotus Domino LotusScript, Java, IBM X Pages MultiValue
MarkLogic Server XQuery, Java, REST XML database – поддържа JSON, текст и бинарни формати
MongoDB C++, C#, Go BSON хранилище (бинарен формат JSON)
Oracle NoSQL Database Java, C
OrientDB Java Поддържа JSON и SQL
Sedna XQuery, C++ XML база данни
SimpleDB Erlang online услуга
OpenLink Virtuoso C++, C#, Java, SPARQL Хибрид между мидълуеър (софтуер, който стои между два или повече типа софтуер и превежда информацията между тях) и машина за база данни (database engine)


Граф бази данни[редактиране | edit source]

Граф базите данни (на английски: Graph database) са създадени за данни, чиито елементи са добре представени както графи (взаимосвързани елементи с неопределен брой отношения между тях). Типовете отношения могат да бъдат например социални отношения, връзки межу линиите на градския транспорт, пътни карти, мрежови топологии и др.

Име Език Бележки
AllegroGraph SPARQL RDF GraphStore
IBM DB2 SPARQL RDF GraphStore добавена в DB2 10
DEX Java, C++, .NET Високо производителна граф база данни
FlockDB Scala
InfiniteGraph Java Високо производителна, мащабируема разпределена граф база данни
Neo4j Java
OpenLink Virtuoso C++, C#, Java, SPARQL Хибрид между мидълуеър (софтуер, който стои между два или повече типа софтуер и превежда информацията между тях) и машина за база данни (на английски: database engine)
OrientDB Java
Sones GraphDB C#
OWLIM Java, SPARQL 1.1 RDF граф хранилище с аргументи


Ключ–стойност хранилища[редактиране | edit source]

Ключ–стойност хранилищата (на английски: key-value stores) позволяват да съхранявате данни във формат, който не е таблица или схема. Данните могат да бъдат записани като стандартни типове данни, ползвани в програмните езици или като обект. Ето защо няма нужда да се използва фиксиран модел за данни. Съществуващите видове ключ–стойност хранилища са:

Условно консистентни[редактиране | edit source]

Йерархични[редактиране | edit source]

Съхраняващи данните в памет с произволен достъп[редактиране | edit source]

Съхраняващи на твърдия диск[редактиране | edit source]

Подредени[редактиране | edit source]

Обектни бази данни[редактиране | edit source]

Източници[редактиране | edit source]

  1. Lith, Adam и др. Investigating storage solutions for large data: A comparison of well performing and scalable data storage solutions for real time extraction and batch insertion of data (PDF). // Department of Computer Science and Engineering, Chalmers University of Technology, 2010. с. 70. Посетен на 12 May 2011. Carlo Strozzi first used the term NoSQL in 1998 as a name for his open source relational database that did not offer a SQL interface[...]
  2. NoSQL Relational Database Management System: Home Page. // Strozzi.it, 2 October 2007. Посетен на 29 March 2010.
  3. NoSQL 2009. // Blog.sym-link.com, 12 May 2009. Посетен на 29 March 2010.
  4. Mike Chapple. The ACID Model. //
  5. http://djondb.com
  6. http://tinman.cs.gsu.edu/~raj/8711/sp13/djondb/Report.pdf
  7. http://undefvoid.blogspot.com/2013/03/meeting-with-djondb.html