Vuonna tietojenkäsittelytiede ja tietokannat , NoSQL viittaa perheen tietokannan hallintajärjestelmät (DBMS), joka poikkeaa klassisesta paradigma on relaatiotietokantojen . Lyhenteen suosituin selitys on paitsi SQL, vaikka tämä tulkinta on kiistanalainen.
NoSQL DBMS -perheen tarkka määritelmä on edelleen keskustelun kohteena. Termi liittyy yhtä paljon teknisiin ominaisuuksiin kuin DBMS: n historialliseen sukupolveen, joka syntyi noin vuoden 2010 aikana. Pramod J. Sadalagen ja Martin Fowlerin mukaan tärkein syy DBMS: n NoSQL: n syntymiseen ja käyttöönottoon olisi palvelinkeskusten kehittäminen. ja tarve omistaa tietokantaparadigma, joka on mukautettu tähän laitteistoinfrastruktuurin malliin.
Klusteroitu konearkkitehtuuri saa aikaan hajautetun ohjelmistorakenteen, joka toimii eri palvelimille hajautettujen aggregaattien kanssa, mikä sallii samanaikaisen pääsyn ja muokkaukset, mutta asettaa myös kyseenalaistamaan perinteisen relaatio-DBMS-arkkitehtuurin monet perusteet, erityisesti ACID-ominaisuudet .
1970-luvulla luodut relaatiotietojärjestelmät vakiinnuttivat itsensä vähitellen, kunnes niistä tuli hyvin hallitseva tietokantaparadigma 1990-luvun alussa.
On syntynyt useita muita tietokantamalleja, kuten DBMS: n olio-orientoitu , hierarkkinen DBMS , objektisuhteellinen DBMS , mutta niiden käyttö on ollut hyvin rajallista.
Suhdemallin jakamaton dominointi palautettiin 2000-luvulla, kun suuret Internet-yritykset (Google, Amazon, eBay jne.) Sekoittivat valtavia määriä dataa ja kehittyivät klusterilaskenta . kärsivät näiden uusien käytäntöjen lamauttavista rajoista.
Suurten verkkoyritysten oli käsiteltävä erittäin suuria määriä dataa, jotka kohtasivat ensimmäiset perinteisten relaatio-DBMS: ien luontaiset rajoitukset. Nämä järjestelmät, jotka perustuvat ACID-ominaisuuksien tiukkaan toimeenpanoon ja jotka on yleensä suunniteltu toimimaan yksittäisissä tietokoneissa, kohtasivat nopeasti skaalautuvuusongelmia .
Näiden rajoitusten täyttämiseksi nämä yritykset ovat alkaneet kehittää omia tietokantojen hallintajärjestelmiä, jotka voivat toimia hajautetuilla laitteistoarkkitehtuureilla ja pystyä käsittelemään suuria tietomääriä. Tuloksena olevat omat järjestelmät, Google ( BigTable ), Amazon ( Dynamo (en) ), LinkedIn ( Voldemort ), Facebook ( Cassandra sitten HBase ), SourceForge.net ( MongoDB ), Ubuntu One ( CouchDB ), Baidu ( Hypertable ) olivat edelläkävijöitä. NoSQL-mallin.
Suorituskyky pysyy hyvänä kuormituksen kasvaessa yksinkertaisesti kertomalla palvelimien määrä, mikä on kohtuullinen ratkaisu pienemmillä kustannuksilla, varsinkin jos tulot kasvavat toiminnan lisääntyessä. Jättijärjestelmät ovat ensinnäkin huolissaan: valtavat tietomäärät, heikko relaatiorakenne (tai vähemmän tärkeä kuin erittäin nopean pääsyn kapasiteetti, vaikka se tarkoittaisi palvelimien monistamista).
NoSQL: n tyypillinen malli on avainarvojärjestelmä, jossa on tietokanta, joka topologisesti voidaan tiivistää yksinkertaiseksi yksidimensionaaliseksi assosiatiiviseksi taulukoksi, jossa on miljoonia tai jopa miljardeja merkintöjä. Tyypillisiä sovelluksia ovat reaaliaikainen analyysi, tilastot, lokitallennus jne.
Näitä omia järjestelmiä esittelevien artikkeleiden julkaiseminen on johtanut useiden avoimen lähdekoodin projektien kehittämiseen, jotka ottavat uudelleen käyttöön 2000-luvun lopulla / 2010-luvun alussa nämä pääperiaatteet, nimittäin hajautettujen laitteistoarkkitehtuurien skaalautuvat järjestelmät , jotka eivät kohdistu sovellukseen. tiukka ACID-standardi .
11. kesäkuuta 2009, Johan Oskarsson , atk-insinööri Lontoossa, haluaa järjestää tapaaminen vuonna San Franciscossa antaa yleiskuva näitä uusia ”avoimen lähdekoodin, hajautettujen ja ei-relaatio” järjestelmiä . Hän halusi kovan ja helposti muistettavan nimen tälle konferenssille, kuultuaan IRC-kanavaa #Cassandra, nimi "NoSQL" säilytettiin. Tämä nimi oli alun perin tarkoitettu vain nimeämään tämä yleissopimus, mutta se siirtyy jälkeläisille tulemalla tämän sukupolven työkalujen nimeksi. Tulkinta " ei vain SQL " keksitaan myöhemmin vain lyhenteinä .
Monet tutkijat ovat valittaneet termin "NoSQL" epätarkkuudesta ja sen mahdollisesti aiheuttamasta sekaannuksesta. Joskus he ovat pitäneet parempana termiä "NoRel" (" ei vain relaatio ") tai muita tarkempia nimityksiä, mutta termi on edelleen suosituin.
Yli sata ohjelmistokehittäjät osallistui esityksiä ratkaisuja, kuten Project Voldemortin , Cassandra , Dynomite , HBase , Hypertable , CouchDB ja MongoDB .
San Franciscossa pidettyä vuoden 2009 kokousta pidetään NoSQL-ohjelmistokehittäjäyhteisön vihkimisenä. Kehittäjät, jotka mukaan Computerworld -lehden , "kertomaan, kuinka he kumosi tyrannian kalliita ja hitaita relaatio DBMS kanssa helpompaa ja nopeampaa tapaa manipuloida tietoja . " Jonkin konferenssin esittäjän Jon Travisin mukaan "Relaatio-DBMS: t tekevät liikaa, kun taas NoSQL-tuotteet tekevät mitä tarvitset . " Tämän yhteisön johtajat ovat pääasiassa aloittelevia yrityksiä, joilla ei ollut keinoja hankkia Oracle- lisenssejä , ja kehittivät siksi oman DBMS: n jäljittelemällä Googlen ja Amazon.comin tuotteita . Heidän luomansa tuotteet pystyvät käsittelemään erittäin suuria tietomääriä (satoja teratavuja ) ja tarjoavat skaalautuvuuden Web 2.0 -sovellusten tarpeisiin räätälöidyllä kuormalla , mikä tekee niistä merkityksellisiä. Kirjoittajat kuvailevat tuotteitaan olevan DBMS: n sijaan pikemminkin tietojen tallennusohjelmia .
Ei-relaatio-DBMS, vanhempi kuin relaatio-DBMS, on klassinen keskusyksiköissä ja hakemisto- ohjelmistoissa , ja se toimii siellä, missä lukeminen on paljon useammin kuin kirjoittaminen (esim. LDAP ). Heidän periaatteena on saada uusi elämä NoSQL : n kanssa Internet-palvelujen alalla, koska suurin osa NoSQL-ohjelmistoista on tarkoitettu suurten Internet-palveluiden kuormituksen tasapainottamiseen .
Vuonna 2011 standardoidun manipulointikielen määritystyö alkoi nimellä UnQL ( Unstructured Query Language ). Siinä ehdotetaan virallistamaan tapa, jolla NoSQL-tietokannat tekevät kyselyjä kokoelmissa (relaatiotietokantojen tietotaulukoiden vastine). Vaikka UnQL esitettiin abstraktina SQL: n päällä, joka vastasi hyvin rajoitettua UnQL: ää, muistutettiin, että UnQL ei kata kaikkea SQL: n LDD : tä. Todellisuudessa kaksi aluetta, relaatiotietokannat ja NoSQL, jotka vastaavat erilaisiin tarpeisiin ja rajoituksiin, esiintyvät usein rinnakkain liiketoiminta- arkkitehtuureissa .
NoSQL DBMS: n pääominaisuudet ovat suurten tietomäärien käsittely ja horisontaalinen skaalautuvuus . Nämä järjestelmät eivät yleensä noudata relaatio-DBMS: n standardeja: se ei ole tiukasti haluttu ominaisuus, vaan pikemminkin myönnytys, joka mahdollistaa nopeamman käsittelyn tietyntyyppisille sovelluksille.
Sellaisena DBMS-rakenteet ovat edelleen hyvin heterogeenisiä vuodesta 2016. Voimme kuitenkin mainita muutaman tärkeimmän nousevan perheen.
Yksi monien NoSQL-DBMS: ien ominaisuuksista on "data-aggregaattien" käyttö, jotka koostuvat joukosta tietoja, joita "usein tarkastellaan / muokataan samanaikaisesti" ja jotka voidaan ottaa käyttöön itsenäisille palvelimille.
Tarkastellaan esimerkkinä verkkokauppasovellusta, joka on suunniteltu siten, että sillä on usein pääsy asiakkaan tietoihin (osoitteet jne.) Ja hänen ostohistoriaansa (esimerkiksi tarjoamaan hänelle alennuksia).
Kaavio suuntautunut tietokantoja käytetään tallentaa tietoja graafisessa muodossa ja helpottaa kirjoittamista kyselyt poistamalla useimmat liitokset. Relaatiotietokantoihin verrattuna näiden tietokantojen tehokkuus vaihtelee järjestelmien ja tehtävien sekä kokoonpanojen mukaan. Nämä tiedot ovat tyypillisesti sosiaalisten verkostojen, liikenneverkkojen, topologioiden tai asiakirjasuositussysteemien tietoja.
Erotamme yleensä triplestoreet graafikeskeisistä tietokannoista. Kuvaajatietokannat toimivat erityyppisten kaavioiden kanssa (esim. Painotetut, klusterit, kaaviot ja sekataulukot) ja tarjoavat usein paremman suorituskyvyn kaavioiden läpikäynneille. Triplestores hoitaa yksinomaan binary kuvaajat RDF kolminkertaistaa (siis keskitetty suhteet), mutta tarjoavat päätelmiä. Kyselyn kielet riippuvat tietokannoissa triplestores toimivat yksinomaan SPARQL kielen , katso yksityiskohtainen artikkeli siitä kyselykielten.
Saat kuvaajan suuntautunut tietokannat , tietojen käytön skeema ei ole aina välttämätöntä.
Ensimmäinen vaihe relaatiotietokannan luomisessa on määritellä sen kaava, toisin sanoen kaikki sen muodostavat taulukot ja näiden taulukoiden kaikki kentät. Tämä vaihe luo tietyn jäykkyyden toteutuksessa, merkitsee melko selkeää näkemystä sovelluksen kehityksestä ja voi aiheuttaa ongelman, jos kerättyjen tietojen rakenne muuttuu ajan myötä. Skeemattomat NoSQL-järjestelmät voivat ohittaa tämän vaiheen ja tallentaa heterogeenisiä tietoja syötettäessä. Tämä käyttö mahdollistaa suuren joustavuuden ja mukautuvuuden tietokantatasolla. Haittapuoli on, että tietokannan lukevien sovellusten on kyettävä integroimaan heterogeenisempi data monimutkaisemmalle rakenteelle.
ACID ominaisuudet varmistaa, että jos useat käyttäjät ovat samanaikaisesti tietojen muuttuessa, kaikki muutokset sisällytetään tietyssä järjestyksessä ja hallitusti siten, että niillä johdonmukainen tulos (tietojen eheys) kanssa Muutoshistorian tekemä kukin. ACID-ominaisuuksien tiukka käyttöönotto johtaa merkittäviin ohjelmistokustannuksiin ja heikompaan suorituskykyyn vastaavalla laitteistoinfrastruktuurilla.
DBMS hakemistot toimi mallina nostaa joidenkin näiden rajoitusten käyttöön perustuvan, erityisesti tapauksissa, joissa valtaosa tietokantojen muuttamatta koostuu lukemat (tässä tapauksessa vain pysyvyys omaisuuden alalla).
Selviytyäkseen suurista tietomääristä, joita voidaan käyttää eri puolilta maailmaa, on välttämätöntä pystyä toistamaan nämä tiedot fyysisissä koneissa, tätä kutsutaan hajautetuksi ympäristöksi. CAP teoreema osoittaa, että se ei ole mahdollista täysin taata HAPPO liiketoimet hajautetussa ympäristössä.
Paxos protokolla on suorituskyvyltään, että algoritmin konsensus Chandra-Toueg (in) hajautetussa ympäristössä ja joita voidaan käyttää käytännön sovelluksissa, erityisesti pilvi. Tämä protokolla on mahdollista sisällyttää sovellukseen pitäen osittain ACID-rajoitukset.
Markkinoilla olevat ratkaisut toteuttavat tämän protokollan lisäämällä omat tekniikkansa rajoittamaan ACID: n mahdottomuuden seurauksia tietoja kirjoitettaessa ja päivitettäessä.
Relaatiotietojärjestelmiä käytetään yrityksissä laajalti. Mitoitettu tietomäärälle ja useille yrityksen tyypillisille käyttäjille heidän päätehtävänsä on tapahtumien käsittely .
Heillä on kuitenkin rajoituksia, kun niitä käytetään laajemmassa laajuudessa, kuten suosittu verkkosivusto kuormituksen jakautumisessa ( kuormituksen tasapainottaminen ), jota miljoonat kävijät käyttävät ympäri maailmaa: edellyttävät sitten relaatiotietojärjestelmien kalliita ohjelmistoja ja tietokoneita sekä vähän tunnettuja optimointitaitoja.
Siksi tällä markkinasegmentillä on NoSQL- ohjelmisto , joka on suunniteltu erityisesti Internet- tyyppiseen käyttöön . Nämä tuotteet hylkäävät tiedon matriisiesityksen ja SQL- komentokielen vastineeksi yksinkertaisuuden, suorituskyvyn ja ennen kaikkea skaalautuvuuden lisäämiseksi . Täytäntöönpanon monimutkaisuuteen liiketoimen käsittelyn on pienennetty, jotta saavutetaan yksinkertaisempi ja erikoistuneita palveluita.
Helppo toteuttaa, tietojen tallennus assosiatiivisten matriisien avulla (kutsutaan avaimeksi / arvoksi ) on ollut olemassa tietokantahistorian alusta lähtien vuonna 1970. Kielet, kuten Perl ja PHP, ovat tehneet heistä tuttuja ohjelmoijia. Uusiin vaatimuksiin nähden ja suuren yleisön sivustoja, jotka ilmestyivät 2000-luvulla ja helppous täytäntöönpanon yhdistys pöydät ovat johtaneet syntymistä näitä ratkaisuja. Heillä on yhteistä SQL-kielen hylkääminen, ja siksi niitä kutsutaan NoSQL: ksi . Tämä ei tarkoita, ettei kukaan koskaan tarjoa tätä kieltä vaihtoehtona .
Vuonna NoSQL DBMS markkinoilla ovat Cassandra , MongoDB , Voldemortin, CouchDB ja SimpleDB . IT-ammattilaisten vuonna 2010 tekemässä kyselyssä 44% vastaajista vastasi, etteivät olleet koskaan kuulleet NoSQL: stä.
Esimerkkejä NoSQL-tuotteista:
Relaatiotietokannat, joissa on NoSQL-käyttöliittymä: