NoSQL ( englanniksi ei vain SQL - ei vain SQL ) on nimitys laajalle heterogeenisten tietokantojen hallintajärjestelmien luokalle, joka ilmestyi 2000-luvun lopulla - 2010-luvun alussa ja eroaa merkittävästi perinteisestä relaatiotietokantajärjestelmästä , jossa tietojen käyttö on SQL -kieltä . Koskee järjestelmiä, jotka yrittävät ratkaista skaalautuvuuden ja käytettävyyden ongelmia, jotka johtuvat atomiteetti- ja tietojen johdonmukaisuuden vaatimusten täydellisestä tai osittaisesta hylkäämisestä [1] .
Alun perin sana NoSQL oli lyhenne kahdesta englanninkielisestä sanasta: No ("Ei") ja SQL ( lyhenne sanoista Englanti Structured Query Language - "strukturoitu kyselykieli"), mikä antaa termille merkityksen "SQL:n kieltäminen". . On mahdollista, että ensimmäinen, joka alkoi käyttää tätä termiä, halusi sanoa "No RDBMS" ("ei relaatiotietokantajärjestelmä ") tai "ei relaatiota" ("ei relaatiollinen"), mutta NoSQL kuulosti paremmalta ja juurtui lopulta. vaihtoehtona ehdotettiin myös NonRel). Myöhemmin NoSQL keksittiin selitykseksi "Ei vain SQL" ("ei vain SQL"). NoSQL:stä on tullut yleinen termi erilaisille tietokannoille ja varastoille, mutta se ei viittaa mihinkään tiettyyn teknologiaan tai tuotteeseen [2] .
Ei-relaatiotietokantojen idea sinänsä ei ole uusi, ja ei-relaatiotallennusten käyttö juontaa juurensa ensimmäisten tietokoneiden päiviin. Ei-relaatiotietokannat kukoistivat keskustietokoneiden päivinä , ja myöhemmin, relaatiotietokantajärjestelmän hallitsevana aikana, niitä käytettiin erikoisliikkeissä, kuten hierarkkisissa hakemistopalveluissa . Uuden sukupolven ei-relaatiotietokantajärjestelmän ilmaantuminen johtui tarpeesta luoda rinnakkaisia hajautettuja järjestelmiä erittäin skaalautuville Internet-sovelluksille, kuten hakukoneille [2] .
2000-luvun alussa Google rakensi erittäin skaalautuvan hakukoneensa ja sovelluksensa: GMail , Google Maps , Google Earth jne., jotka ratkaisivat skaalautuvuuden ja suurten tietomäärien rinnakkaiskäsittelyn ongelmat. Tuloksena oli hajautettu tiedostojärjestelmä ja hajautettu koordinointijärjestelmä, sarakeperhekauppa , MapReduce - algoritmiin perustuva ajonaikainen ympäristö . Googlen julkaisema kuvaukset näistä teknologioista johti kiinnostuksen nousuun avoimen lähdekoodin kehittäjien keskuudessa , mikä johti Hadoopin luomiseen ja siihen liittyvien projektien käynnistämiseen Googlen kaltaisten tekniikoiden luomiseksi. Vuotta myöhemmin, vuonna 2007, Amazon.com seurasi Googlen esimerkkiä julkaisemalla artikkeleita erittäin saatavilla olevasta Amazon DynamoDB -tietokannasta [3] .
Alan jättiläisten tuki alle viidessä vuodessa on johtanut NoSQL:n (ja vastaavien) teknologioiden laajaan käyttöönotossa "big datan" hallintaan, ja muut suuret ja pienet yritykset ovat liittyneet asiaan, kuten: IBM , Facebook , Netflix , eBay , Hulu , Yahoo! , ja sen omat ja avoimen lähdekoodin ratkaisut [3] .
Perinteisiä DBMS-järjestelmiä ohjaavat transaktiojärjestelmän ACID -vaatimukset : atomiteetti ( atomicity ), johdonmukaisuus ( englanniksi johdonmukaisuus ), eristys ( englanniksi isolation ), kestävyys ( englanninkielinen kestävyys ), kun taas NoSQL:ssä ACIDin sijaan voidaan määrittää joukko BASE-ominaisuuksia. harkittu [1] :
Termiä "BASE" ehdotti Eric Brewer, CAP-lauseen kirjoittaja , jonka mukaan hajautetussa laskennassa voidaan varmistaa vain kaksi kolmesta ominaisuudesta: tietojen johdonmukaisuus, saatavuus tai osion toleranssi [1] .
BASE-pohjaisia järjestelmiä ei tietenkään voi käyttää kaikissa sovelluksissa: valuutanvaihto- ja pankkijärjestelmien toiminnan kannalta transaktioiden käyttö on välttämätöntä. Samaan aikaan ACID-ominaisuuksia, niin haluttuja kuin ne ovat, on lähes mahdotonta saavuttaa järjestelmissä, joissa on useita miljoonia verkkoyleisöjä, kuten amazon.com [1] . Siten NoSQL-järjestelmän suunnittelijat uhraavat tietojen johdonmukaisuuden saavuttaakseen CAP-lauseen kaksi muuta ominaisuutta [4] . Jotkin tietokantajärjestelmät, kuten Riak , antavat sinun säätää vaadittuja käytettävyyden yhdenmukaisuusominaisuuksia jopa yksittäisille pyynnöille määrittämällä tapahtuman onnistumisen vahvistamiseen tarvittavien solmujen lukumäärän. [5]
NoSQL-ratkaisut eroavat toisistaan paitsi skaalautuvan suunnittelun suhteen. Muita NoSQL-ratkaisujen merkittäviä ominaisuuksia ovat [6] [7] :
Tietoskeeman kuvaus NoSQL-ratkaisuja käytettäessä voidaan suorittaa käyttämällä erilaisia tietorakenteita: hash-taulukoita , puita ja muita.
Tietomallista sekä jakelu- ja replikointimenetelmistä riippuen NoSQL-liikkeessä on neljä päätyyppiä järjestelmät: "avainarvo" ( englanninkielinen avainarvovarasto ), "sarakkeiden perhe" ( pylväs-perhekauppa ), dokumentti -suuntautunut ( asiakirjavarasto ), kaavio.
Avainarvomalli on yksinkertaisin vaihtoehto, jossa arvoa käytetään avaimella. Tällaisia järjestelmiä käytetään kuvien tallentamiseen, erikoistuneisiin tiedostojärjestelmiin, objektivälimuistiin ja skaalautuviin järjestelmiin . Esimerkkejä tällaisista varastoista ovat Berkeley DB , MemcacheDB , Redis , Riak , Amazon DynamoDB [6] .
Toinen järjestelmätyyppi on "sarakeperhe", tämän tyypin esi-isä on Google BigTable -järjestelmä . Tällaisissa järjestelmissä tiedot tallennetaan harvaan matriisina, jonka rivejä ja sarakkeita käytetään avaimina. Tyypillinen sovellus tämän tyyppisille DBMS-järjestelmille on verkkoindeksointi sekä isot datatehtävät , joiden johdonmukaisuusvaatimukset ovat pienemmät . Esimerkkejä tämän tyyppisistä tietokantajärjestelmistä ovat: Apache HBase , Apache Cassandra , ScyllaDB , Apache Accumulo , Hypertable [6] [8] .
Kolumniperhejärjestelmillä ja dokumenttisuuntautuneilla järjestelmillä on samanlaisia käyttötapauksia: sisällönhallintajärjestelmät, blogit, tapahtumaloki. Aikaleimojen käyttö mahdollistaa tämän tyyppisen järjestelmän käytön laskurien järjestämiseen sekä erilaisten aikatietojen tallentamiseen ja käsittelyyn [8] .
Toisin kuin joissakin relaatiotietokantajärjestelmissä käytetty sarakevarasto , joka tallentaa tiedot sarakkeittain pakatussa muodossa tehostaakseen OLAP -skenaarioita, "sarakeperhe"-malli tallentaa tiedot rivi riviltä ja tarjoaa korkean suorituskyvyn ensisijaisesti käyttöskenaarioissa , kun taas kyselyissä, jotka vaativat suuren datamäärän indeksointi tulosten yhdistämisellä on yleensä tehotonta [8] [9] .
Asiakirjasuuntautuneita DBMS- järjestelmiä käytetään hierarkkisten tietorakenteiden tallentamiseen. He löytävät sovelluksensa sisällönhallintajärjestelmissä , julkaisuissa, dokumenttien haussa . Esimerkkejä tämän tyyppisistä tietokantajärjestelmistä ovat CouchDB , Couchbase , MongoDB , eXist , Berkeley DB XML [6] .
Graph DBMS :iä käytetään tehtäviin, joissa tiedoissa on suuri määrä linkkejä, esimerkiksi sosiaaliset verkostot , petosten havaitseminen. Esimerkkejä: Neo4j , OrientDB , AllegroGraph , Blazegraph [10] , InfiniteGraph , FlockDB , Titan [6] [8] .
Koska graafin reunat materialisoituvat eli ne tallennetaan , graafin läpikulku ei vaadi lisälaskutoimituksia (kuten liitos SQL:ssä ), mutta indeksejä tarvitaan läpikäynnin alkupisteen löytämiseksi. Graph DBMS:t tukevat yleensä ACID :ää ja myös erikoistuneita kyselykieliä, kuten Gremlin , Cypher , SPARQL , GraphQL .
Heinäkuussa 2011 Couchbase, CouchDB:n , Memcachedin ja Membasen kehittäjä , ilmoitti luovansa uuden SQL :n kaltaisen kyselykielen - UnQL (Unstructured Data Query Language). Uuden kielen loivat SQLiten luoja Richard Hipp ja CouchDB - projektin perustaja Damien Katz . Kehitys on siirretty yhteisön käyttöön julkisena [11] [12] [13] . Edellisen kerran UnQL päivitettiin elokuussa 2011 [14] , itse asiassa hanke ei saanut tukea.