NoSQL (fra engelsk ikke kun SQL - ikke kun SQL ) er en betegnelse for en bred klasse af heterogene databasestyringssystemer, der dukkede op i slutningen af 2000'erne - begyndelsen af 2010'erne og adskiller sig væsentligt fra traditionelle relationelle DBMS med dataadgang ved brug af SQL -sproget . Gælder for systemer, der forsøger at løse problemer med skalerbarhed og tilgængelighed på grund af fuldstændig eller delvis afvisning af kravene om atomicitet og datakonsistens [1] .
Ordet NoSQL var oprindeligt et akronym for to engelske ord: No ("Not") og SQL (forkortelse for English Structured Query Language - "structured query language"), som giver udtrykket betydningen af "denying SQL" . Det er muligt, at den første, der begyndte at bruge dette udtryk, ønskede at sige "Ingen RDBMS" ("ikke en relationel DBMS ") eller "ingen relationel" ("ikke relationel"), men NoSQL lød bedre og slog til sidst rod (som en alternativt blev det også foreslået NonRel). Senere blev NoSQL opfundet forklaringen "Not Only SQL" ("ikke kun SQL"). NoSQL er blevet en generel betegnelse for forskellige databaser og lagre, men det refererer ikke til nogen bestemt teknologi eller produkt [2] .
I sig selv er ideen om ikke-relationelle databaser ikke ny, og brugen af ikke-relationel lagring går tilbage til de første computeres dage. Ikke-relationelle databaser blomstrede i mainframens dage , og senere, i løbet af dagene med dominansen af relationelle DBMS, blev de brugt i specialiserede butikker, såsom hierarkiske katalogtjenester . Fremkomsten af en ny generation af ikke-relationelle DBMS skyldtes behovet for at skabe parallelt distribuerede systemer til meget skalerbare internetapplikationer såsom søgemaskiner [2] .
I begyndelsen af 2000'erne byggede Google sin meget skalerbare søgemaskine og applikationer: GMail , Google Maps , Google Earth osv., og løste problemerne med skalerbarhed og parallel behandling af store mængder data. Resultatet var et distribueret filsystem og et distribueret koordinationssystem, en kolonnefamiliebutik, et runtime -miljø baseret på MapReduce -algoritmen . Googles udgivelse af beskrivelser af disse teknologier førte til en bølge af interesse blandt open source-udviklere , hvilket resulterede i oprettelsen af Hadoop og lanceringen af relaterede projekter designet til at skabe Google-lignende teknologier. Et år senere, i 2007, fulgte Amazon.com Googles føring ved at udgive artikler om den meget tilgængelige database Amazon DynamoDB [3] .
Støtten fra industrigiganter på mindre end fem år har ført til den udbredte anvendelse af NoSQL (og lignende) teknologier til håndtering af "big data", og andre store og små virksomheder har tilsluttet sig sagen, såsom: IBM , Facebook , Netflix , eBay , Hulu , Yahoo! , med dets proprietære og open source-løsninger [3] .
Traditionelle DBMS er styret af ACID -krav til et transaktionssystem: atomicitet ( atomicitet ), konsistens ( engelsk konsistens ), isolation ( engelsk isolation ), holdbarhed ( engelsk holdbarhed ), mens der i NoSQL i stedet for ACID kan et sæt BASE-egenskaber være overvejet [1] :
Udtrykket "BASE" blev foreslået af Eric Brewer, forfatter til CAP-sætningen , ifølge hvilken kun to af de tre egenskaber i distribueret databehandling kan sikres: datakonsistens, tilgængelighed eller partitionstolerance [1] .
Naturligvis kan BASE-baserede systemer ikke bruges i alle applikationer: for at fungere af børs- og banksystemer er brugen af transaktioner en nødvendighed. Samtidig er ACID-funktioner, ønskværdige som de er, næsten umulige at opnå i systemer med en multi-million webpublikum som amazon.com [1] . NoSQL-systemdesignere ofrer således datakonsistens for at opnå de to andre egenskaber ved CAP-sætningen [4] . Nogle DBMS'er, såsom Riak , giver dig mulighed for at indstille de nødvendige tilgængelighedskonsistensegenskaber selv for individuelle anmodninger ved at angive antallet af noder, der kræves for at bekræfte succesen af en transaktion. [5]
NoSQL-løsninger adskiller sig ikke kun ved at designe til skalering. Andre fremtrædende træk ved NoSQL-løsninger er [6] [7] :
Beskrivelsen af dataskemaet i tilfælde af brug af NoSQL-løsninger kan udføres ved brug af forskellige datastrukturer: hashtabeller , træer og andre.
Afhængigt af datamodellen og tilgange til distribution og replikering er der fire hovedtyper af systemer i NoSQL-bevægelsen: "key-value" ( engelsk nøgleværdilager ), "familie af kolonner" ( kolonnefamiliebutik ), dokument -orienteret ( dokumentlager ), graf.
Nøgleværdi - modellen er den enkleste mulighed, ved at bruge en nøgle til at få adgang til en værdi. Sådanne systemer bruges til billedlagring, specialiserede filsystemer, objektcaches og systemer designet til skalerbarhed . Eksempler på sådanne lagringer er Berkeley DB , MemcacheDB , Redis , Riak , Amazon DynamoDB [6] .
En anden type system er "familien af kolonner", stamfaderen til denne type er Google BigTable -systemet . I sådanne systemer lagres data som en sparsom matrix, hvis rækker og kolonner bruges som nøgler. En typisk applikation til denne type DBMS er webindeksering såvel som big data- opgaver med reducerede konsistenskrav . Eksempler på denne type DBMS er: Apache HBase , Apache Cassandra , ScyllaDB , Apache Accumulo , Hypertable [6] [8] .
Kolonnefamiliesystemer og dokumentorienterede systemer har lignende use cases: indholdsstyringssystemer, blogs, hændelseslogning. Brugen af tidsstempler gør det muligt at anvende denne type systemer til organisering af tællere, samt registrering og behandling af forskellige tidsrelaterede data [8] .
I modsætning til kolonneopbevaring, der bruges i nogle relationelle DBMS'er , som gemmer data efter kolonner i en komprimeret form for effektivitet i OLAP -scenarier, gemmer "kolonnefamilie"-modellen data række for række og giver høj ydeevne primært i operationelle scenarier , mens forespørgsler, der kræver crawling af en stor mængde data med aggregering af resultater er som regel ineffektive [8] [9] .
Dokumentorienteret DBMS bruges til at lagre hierarkiske datastrukturer. De finder deres anvendelse i indholdsstyringssystemer , publicering, dokumentarsøgning . Eksempler på denne type DBMS er CouchDB , Couchbase , MongoDB , eXist , Berkeley DB XML [6] .
Graph DBMS bruges til opgaver, hvor data har et stort antal links, for eksempel sociale netværk , afsløring af svindel. Eksempler: Neo4j , OrientDB , AllegroGraph , Blazegraph [10] , InfiniteGraph , FlockDB , Titan [6] [8] .
Da kanterne af grafen er materialiseret , det vil sige, at de er lagret, kræver grafgennemløb ikke yderligere beregninger (som en joinforbindelse i SQL ), men indekser er nødvendige for at finde det indledende toppunkt for gennemkørslen. Graph DBMS'er understøtter generelt ACID og understøtter også specialiserede forespørgselssprog såsom Gremlin , Cypher , SPARQL , GraphQL .
I juli 2011 annoncerede Couchbase, udvikleren af CouchDB , Memcached og Membase , oprettelsen af et nyt SQL - lignende forespørgselssprog - UnQL (Unstructured Data Query Language). Oprettelsen af det nye sprog blev udført af SQLite-skaberen Richard Hipp og CouchDB- projektets grundlægger Damien Katz . Udviklingen er blevet overført til fællesskabet som et offentligt domæne [11] [12] [13] . Sidst UnQL blev opdateret i august 2011 [14] modtog projektet faktisk ingen støtte.