Olen nähnyt paljon sekaannusta monien uusien tietokantaratkaisujen (”NoSQL-tietokannat”) paikasta ja tarkoituksesta verrattuna relaatiotietokantaratkaisuihin, jotka ovat olleet käytössä jo vuosia. Yritän siis selittää erot ja parhaat käyttötapaukset kummallekin.
Kerrataan ensin nämä tietokantaratkaisut kahteen ryhmään:
1) Relaatiotietokannat, joita voidaan kutsua myös relaatiotietokantojen hallintajärjestelmiksi (Relational Database Management Systems, RDBMS) tai SQL-tietokannoiksi. Näistä suosituimpia ovat Microsoft SQL Server, Oracle Database, MySQL ja IBM DB2. Näitä RDBMS-tietokantoja käytetään enimmäkseen suurten yritysten skenaarioissa, lukuun ottamatta MySQL:ää, jota käytetään enimmäkseen web-sovellusten tietojen tallentamiseen, tyypillisesti osana suosittua LAMP-pinoa (Linux, Apache, MySQL, PHP/Python/Perl).
2) Ei-relationaaliset tietokannat, joita kutsutaan myös nimellä NoSQL-tietokannat, ja joista suosituimpia ovat MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis, ja Neo4j. Nämä tietokannat ryhmitellään yleensä neljään luokkaan:
Kaikkea relaatiotietokantoja voidaan käyttää tapahtumasuuntautuneiden sovellusten (OLTP) hallintaan, ja useimpia ei-relaatiotietokantoja, jotka kuuluvat luokkiin Dokumenttivarastot ja Pylväsvarastot, voidaan käyttää myös OLTP:hen, mikä lisää sekaannusta. OLTP-tietokantoja voidaan pitää ”operatiivisina” tietokantoina, joille on ominaista usein toistuvat, lyhyet transaktiot, joihin sisältyy päivityksiä ja jotka koskevat pientä tietomäärää ja joissa tuhansien transaktioiden samanaikaisuus on hyvin tärkeää (esimerkkeinä pankkisovellukset ja verkkovaraukset). Tietojen eheys on erittäin tärkeää, joten ne tukevat ACID-tapahtumia (Atomicity, Consistency, Isolation, Durability). Tämä on vastakohta tietovarastoille, joita pidetään ”analyyttisinä” tietokantoina, joille on ominaista pitkät, monimutkaiset kyselyt, jotka koskevat suurta tietomäärää ja vaativat paljon resursseja. Päivitykset ovat harvinaisia. Esimerkkinä voidaan mainita viime vuoden myynnin analysointi.
Relationaaliset tietokannat työskentelevät yleensä strukturoidun datan kanssa, kun taas ei-relationaaliset tietokannat työskentelevät yleensä puolistrukturoidun datan (esim. XML, JSON) kanssa.
Katsotaanpa kumpaakin ryhmää yksityiskohtaisemmin:
Relationaaliset tietokannat
Relationaalinen tietokanta organisoituu relationaaliseen tietomalliin (relational model of data) perustuen, sellaisena kuin se on ehdotettu vuonna 1970, jonka on laatinut E.F. Codd. Tässä mallissa tiedot järjestetään yhdeksi tai useammaksi riveistä ja sarakkeista koostuvaksi tauluksi (tai ”relaatioksi”), joissa jokaisella rivillä on yksilöllinen avain. Yleensä jokaisella tietokannassa kuvatulla oliotyypillä on oma taulukkonsa, jonka rivit edustavat kyseisen oliotyypin esiintymiä ja sarakkeet kyseiselle esiintymälle annettuja arvoja. Koska jokaisella taulukon rivillä on oma yksilöllinen avaimensa, taulukon rivit voidaan linkittää muiden taulukoiden riveihin tallentamalla sen rivin yksilöllinen avain, johon rivi halutaan linkittää (jolloin tällainen yksilöllinen avain tunnetaan nimellä ”vierasavain”). Codd osoitti, että mielivaltaisen monimutkaiset tietokantasuhteet voidaan esittää tämän yksinkertaisen käsitejoukon avulla.
Periaatteessa kaikki relaatiotietokantajärjestelmät käyttävät SQL:ää (Structured Query Language) tietokannan kysely- ja ylläpitokielenä.
Syitä relaatiotietokantojen hallitsevaan asemaan ovat seuraavat: yksinkertaisuus, vankkuus, joustavuus, suorituskyky, skaalautuvuus ja yhteensopivuus geneerisen datan hallitsemisessa.
Mutta jotta ne voisivat tarjota kaiken tämän, relaatiotietokantojen on oltava sisäisesti uskomattoman monimutkaisia. Esimerkiksi suhteellisen yksinkertaisella SELECT-lausekkeella voi olla kymmeniä potentiaalisia kyselyn suorituspolkuja, joita kyselyn optimoija arvioi suoritusaikana. Kaikki tämä on käyttäjiltä piilossa, mutta konepellin alla RDBMS määrittää parhaan ”suoritussuunnitelman” pyyntöihin vastaamiseksi käyttämällä esimerkiksi kustannuspohjaisia algoritmeja.
Suurissa tietokannoissa, erityisesti web-sovelluksissa käytettävissä tietokannoissa, suurin huolenaihe on skaalautuvuus. Kun yhä useampia sovelluksia luodaan ympäristöihin, joissa on massiivinen työmäärä (esim. Amazon), niiden skaalautuvuusvaatimukset voivat muuttua hyvin nopeasti ja kasvaa hyvin suuriksi. Relaatiotietokannat skaalautuvat hyvin, mutta yleensä vain silloin, kun skaalautuminen tapahtuu yhdellä palvelimella (”scale-up”). Kun yksittäisen palvelimen kapasiteetti on saavutettu, kuormitus on jaettava useille palvelimille, jolloin siirrytään niin sanottuun hajautettuun tietojenkäsittelyyn. Tällöin relaatiotietokantojen monimutkaisuus alkaa aiheuttaa ongelmia niiden skaalautuvuuden kanssa. Jos yrität skaalautua satoihin tai tuhansiin palvelimiin, monimutkaisuus käy ylivoimaiseksi. Ominaisuudet, jotka tekevät relaatiotietokannoista niin houkuttelevia, ovat juuri ne samat, jotka myös vähentävät jyrkästi niiden elinkelpoisuutta suurten hajautettujen järjestelmien alustoina.
Ei-relationaaliset tietokannat
NoSQL-tietokanta tarjoaa mekanismin sellaisten tietojen tallentamiseen ja hakemiseen, jotka on mallinnettu muilla keinoin kuin relaatiotietokannoissa käytetyillä taulukkomuotoisilla relaatiorelaatiokuvioilla.
Tälle lähestymistavalle löytyvät muun muassa seuraavat perustelut:
- Suunnittelun yksinkertaisuus. Ei tarvitse käsitellä ”impedanssin epäsuhtaa” sovellusten kirjoittamiseen käytettävän oliopohjaisen lähestymistavan ja relaatiotietokannan skeemapohjaisten taulukoiden ja rivien välillä. Esimerkiksi kaikkien asiakastilaustietojen tallentaminen yhteen asiakirjaan sen sijaan, että jouduttaisiin yhdistämään useita taulukoita toisiinsa, jolloin kirjoitettavaa, debugattavaa ja ylläpidettävää koodia on vähemmän
- Parempi ”horisontaalinen” skaalautuminen koneiden klustereihin, mikä ratkaisee ongelman, kun samanaikaisten käyttäjien määrä nousee räjähdysmäisesti sovelluksissa, joihin pääsee käsiksi verkon ja mobiililaitteiden kautta. Asiakirjojen käyttäminen helpottaa huomattavasti skaalautumista, koska kaikki asiakastilausta koskevat tiedot ovat yhdessä paikassa sen sijaan, että ne olisi hajautettu useisiin taulukoihin. NoSQL-tietokannat jakavat tiedot automaattisesti eri palvelimille ilman, että sovellukseen tarvitsee tehdä muutoksia (auto-sharding), mikä tarkoittaa, että ne jakavat tiedot natiivisti ja automaattisesti mielivaltaiselle määrälle palvelimia ilman, että sovelluksen tarvitsee edes olla tietoinen palvelinpoolien koostumuksesta. Tieto ja kyselykuorma tasapainotetaan automaattisesti palvelinten välillä, ja kun palvelin kaatuu, se voidaan korvata nopeasti ja läpinäkyvästi ilman sovelluksen häiriöitä
- Saatavuuden tarkempi hallinta. Palvelimia voidaan lisätä tai poistaa ilman sovelluksen käyttökatkoksia. Useimmat NoSQL-tietokannat tukevat datan replikointia, mikä tarkoittaa useiden kopioiden tallentamista eri puolille klusteria tai jopa eri datakeskuksiin korkean saatavuuden ja katastrofista toipumisen varmistamiseksi
- Kaikenlaisen datan ”Big Data”, johon kuuluu myös strukturoimatonta ja puolistrukturoitua dataa, helppo tallentaminen. Mahdollistetaan joustava tietokanta, johon voidaan helposti ja nopeasti sisällyttää mitä tahansa uudentyyppistä dataa ja jota sisällön rakenteen muutokset eivät häiritse. Tämä johtuu siitä, että dokumenttitietokannat ovat skeemattomia, jolloin JSON-dokumentteihin voidaan vapaasti lisätä kenttiä ilman, että muutoksia tarvitsee ensin määritellä (schema-on-read eikä schema-on-write). Asiakirjoissa voi olla eri määrä kenttiä kuin muissa asiakirjoissa. Esimerkiksi potilastietue, joka voi sisältää tai olla sisältämättä kenttiä, joissa luetellaan allergiat
- Nopeus. NoSQL-tietokantojen käyttämät tietorakenteet (eli JSON-dokumentit) poikkeavat relaatiotietokannoissa oletusarvoisesti käytetyistä rakenteista, mikä tekee monista operaatioista nopeampia NoSQL-tietokannoissa kuin relaatiotietokannoissa, koska taulukoita ei tarvitse liittää toisiinsa (kustannuksella, että tallennustila lisääntyy tietojen päällekkäisyyksien vuoksi – mutta tallennustila on nykyään niin halpaa, että tämä ei yleensä ole ongelma). Itse asiassa useimmat NoSQL-tietokannat eivät edes tue liitoksia
- Kustannukset. NoSQL-tietokannat käyttävät yleensä halpojen perushyödykepalvelimien klustereita, kun taas RDBMS-tietokannat tukeutuvat yleensä kalliisiin omiin palvelimiin ja tallennusjärjestelmiin. Myös RDBMS-järjestelmien lisenssit voivat olla melko kalliita, kun taas monet NoSQL-tietokannat ovat avoimen lähdekoodin tietokantoja ja siten ilmaisia
Jonkin NoSQL-tietokannan erityinen soveltuvuus riippuu ongelmasta, joka sen on ratkaistava
NoSQL-tietokantoja käytetään yhä enemmän suuressa tietomäärässä (big data) ja reaaliaikaisissa verkkosovelluksissa. Niistä tuli suosittuja webin käyttöönoton myötä, jolloin tietokannat nousivat yrityksen sisäisen sovelluksen maksimissaan muutamasta sadasta käyttäjästä web-sovelluksen tuhansiin tai miljooniin käyttäjiin. NoSQL-järjestelmiä kutsutaan myös nimellä ”Not only SQL” korostamaan sitä, että ne voivat tukea myös SQL:n kaltaisia kyselykieliä.
Monet NoSQL-tietokantakaupat tinkivät johdonmukaisuudesta (CAP-teoremin merkityksessä) käytettävyyden ja ositusten sietokyvyn hyväksi. Joitakin syitä, jotka estävät NoSQL-varastojen käyttöönoton, ovat muun muassa matalan tason kyselykielten käyttö, standardoitujen rajapintojen puute ja valtavat investoinnit olemassa olevaan SQL:ään. Useimmissa NoSQL-tietovarastoissa ei myöskään ole todellisia ACID-transaktioita tai ne tukevat transaktioita vain tietyissä olosuhteissa ja tietyillä tasoilla (esim. dokumenttitasolla). Lopuksi, RDBMS:t ovat yleensä paljon yksinkertaisempia käyttää, koska niissä on graafinen käyttöliittymä, kun taas monet NoSQL-ratkaisut käyttävät komentorivikäyttöliittymää.
Vertailu
Yksi relaatiotietokantojen vakavimmista rajoituksista on se, että kukin kohde voi sisältää vain yhden attribuutin. Jos käytämme esimerkkinä pankkia, jokainen osa-alue asiakkaan ja pankin välisestä suhteesta tallennetaan erillisinä riviyksikköinä erillisiin taulukoihin. Asiakkaan päätiedot ovat siis yhdessä taulukossa, tilitiedot toisessa taulukossa, lainatiedot taas toisessa taulukossa, sijoitukset toisessa taulukossa ja niin edelleen. Kaikki nämä taulukot on yhdistetty toisiinsa relaatioiden, kuten primääriavainten ja vierasavainten, avulla.
Ei-relationaaliset tietokannat, tarkemmin sanottuna tietokannan avain-arvosäilöt eli avain-arvoparit, eroavat tästä mallista radikaalisti. Avainarvoparit mahdollistavat useiden toisiinsa liittyvien kohteiden tallentamisen samaan ”tietoriviin” samassa taulukossa. Laitamme sanan ”rivi” lainausmerkkeihin, koska rivi ei tässä tapauksessa ole oikeastaan sama asia kuin relaatiotaulukon rivi. Esimerkiksi saman pankin ei-relationaalisessa taulukossa jokainen rivi sisältäisi asiakkaan tiedot sekä hänen tili-, laina- ja sijoitustietonsa. Kaikki yhteen asiakkaaseen liittyvät tiedot tallennettaisiin kätevästi yhteen tietueeseen.
Tämä vaikuttaa selvästi paremmalta tavalta tallentaa tietoja, mutta sillä on suuri haittapuoli: toisin kuin relaatiotietokannat, avainarvosäilöt eivät voi pakottaa tietokohteiden välisiä suhteita. Esimerkiksi avainarvotietokannassamme asiakkaan tiedot (nimi, sosiaaliturva, osoite, tilinumero, lainan käsittelynumero jne.) tallennettaisiin kaikki yhdeksi tietueeksi (sen sijaan, että ne tallennettaisiin useisiin taulukoihin, kuten relaatiomallissa). Asiakkaan tapahtumat (tilin nostot, tilitalletukset, lainan takaisinmaksut, pankkimaksut jne.) tallennettaisiin myös toisena yksittäisenä tietueena.
Relaatiomallissa on sisäänrakennettu ja idioottivarma menetelmä, jolla varmistetaan ja pannaan täytäntöön liiketoimintalogiikka ja -säännöt tietokantakerroksessa, esimerkiksi se, että nosto veloitetaan oikealta pankkitililtä, ensisijaisten avainten (primary keys) ja vierasavainten (foreign keys) avulla. Avainarvosäilöissä tämä vastuu lankeaa täysin sovelluslogiikalle, ja monet ihmiset eivät halua jättää tätä ratkaisevaa vastuuta pelkästään sovellukselle. Tämä on yksi syy siihen, miksi relaatiotietokantoja käytetään jatkossakin.
Tietokantoja käyttävissä web-pohjaisissa sovelluksissa liiketoimintalogiikan tinkimättömän noudattamisen varmistaminen ei kuitenkaan useinkaan ole ensisijainen asia. Tärkein prioriteetti on kyky palvella suuria määriä käyttäjien pyyntöjä, jotka tyypillisesti ovat pelkkiä lukukyselyjä. Esimerkiksi eBayn kaltaisella sivustolla suurin osa käyttäjistä vain selaa ja tarkastelee julkaistuja kohteita (vain lukutoiminnot). Vain murto-osa näistä käyttäjistä todella tekee tarjouksia tai varaa kohteita (luku- ja kirjoitusoperaatiot). Muista, että kyse on miljoonista, joskus miljardeista, sivujen katselukerroista päivässä. eBay-sivuston ylläpitäjät ovat kiinnostuneempia nopeasta vasteajasta, jolla varmistetaan nopeampi sivunlataus sivuston käyttäjille, kuin perinteisistä prioriteeteista, jotka koskevat liiketoimintasääntöjen noudattamista tai luku- ja kirjoitusoperaatioiden välisen tasapainon varmistamista.
Relationaalisen mallin mukaisia tietokantoja voidaan virittää ja asettaa suorittamaan laajamittaisia pelkkiä lukutoimintoja tietovarastoinnin avulla ja siten mahdollisesti palvelemaan suurta määrää käyttäjiä, jotka tekevät kyselyjä suuresta tietomäärästä, varsinkin kun käytetään relationaalisia MPP-arkkitehtuureja, kuten Analytics Platform Systemiä, Teradataa, Oraclen Exadataa tai IBM:n Netezza-arkkitehtuuria, jotka kaikki tukevat skaalautumista. Kuten edellä mainittiin, tietovarastot eroavat tyypillisistä tietokannoista siinä, että niitä käytetään tietojen monimutkaisempaan analysointiin. Tämä eroaa transaktiotietokannasta (OLTP-tietokannasta), jonka pääasiallinen käyttötarkoitus on tukea operatiivisia järjestelmiä ja tarjota päivittäistä, pienimuotoista raportointia.
Todellinen haaste on kuitenkin relaatiomallin skaalautuvuuden puute OLTP-sovelluksissa tai missä tahansa ratkaisussa, jossa on paljon yksittäisiä kirjoituksia, mikä on relaationaalisten SMP-arkkitehtuurien ala. Tässä ei-relationaaliset mallit voivat todella loistaa. Ne voivat helposti jakaa tietokuormat kymmenille, sadoille ja ääritapauksissa (ajatelkaa Google-hakua) jopa tuhansille palvelimille. Kun kukin palvelin käsittelee vain pienen osan käyttäjiltä tulevista pyynnöistä, vasteaika on erittäin hyvä jokaiselle yksittäiselle käyttäjälle. Vaikka tämä hajautettu laskentamalli voidaan rakentaa relaatiotietokantoja varten, sen toteuttaminen on todella hankalaa erityisesti silloin, kun kirjoituksia on paljon (eli OLTP), ja se edellyttää jakamisen kaltaisia tekniikoita, jotka yleensä edellyttävät huomattavaa koodausta sovelluksen liiketoimintalogiikan ulkopuolella. Tämä johtuu siitä, että relaatiomalli vaatii tietojen eheyttä kaikilla tasoilla, jotka on säilytettävä, vaikka tietoja käytettäisiin ja muutettaisiin useilla eri palvelimilla. Tämä on syy siihen, että ei-relationaalinen malli on web-sovellusten, kuten pilvilaskennan ja sosiaalisten verkostojen, ensisijainen arkkitehtuuri.
Yhteenvetona voidaan siis todeta, että RDBMS-tietokannat kärsivät siitä, että ne eivät ole horisontaalisesti skaalautuvia suurille transaktiokuormille (miljoonat luku- ja kirjoituskerrat), kun taas NoSQL-tietokannat ratkaisevat suurten transaktiokuormien ongelman, mutta se tapahtuu tietojen eheyden ja yhdistämisen kustannuksella.
Muistaessasi, että monissa ratkaisuissa käytetään relationaalisten ja ei-relationaalisten tietokantojen kombinaatioita.(ks. kohta: Mikä on moniulotteinen säilyvyys?).
Muista myös, että et ehkä tarvitse ei-relationaalisen tietokannan suorituskykyä ja sen sijaan riittää, että tallennat tiedostot HDFS:ään ja käytät Apache Hivea (Apache Hive on Hadoopin päälle rakennettu tietovarastoinfrastruktuuri, joka tarjoaa tietojen tiivistämistä, kyselyjä ja analyysejä SQL:n kaltaisen kielen, HiveQL:n, avulla).
Ja lopetetaan sekaannusta lisäävällä huomautuksella, että meillä on vielä yksi uusi kategorian muodostava luokka nimeltä NewSQL: NewSQL on nykyaikaisten RDBMS-järjestelmien luokka, jolla pyritään tarjoamaan sama skaalautuva suorituskyky kuin NoSQL-järjestelmillä OLTP-luku- ja -kirjoitustyömäärille säilyttäen samalla perinteisen relaatiotietokantajärjestelmän ACID-takeet. Niiden haittapuolena on, että ne eivät sovellu OLAP-tyyppisiin kyselyihin ja että ne eivät sovellu yli muutaman teratavun tietokantoihin. Esimerkkejä ovat VoltDB, NuoDB, MemSQL, SAP HANA, Splice Machine, Clustrix ja Altibase.
Kuva, josta näkyy, mihin kategorioihin monet tuotteet sopivat:
Erinomainen grafiikka, josta näkyy, miten kaikki teknologiat sopivat Azure-pilveen, on Understanding NoSQL on Microsoft Azure -kirjasta:
NoSQL-ratkaisun käyttämisen perusteena on, jos sinulla on OLTP-sovellus, jossa on tuhansia käyttäjiä ja erittäin suuri tietokanta, joka vaatii skaalautuvaa ratkaisua ja/tai käyttää JSON-dataa, erityisesti jos tässä JSON-datassa on erilaisia rakenteita. Saat myös korkean käytettävyyden edut, koska NoSQL-ratkaisut tallentavat useita kopioita tiedoista. Pidä vain mielessä, että suorituskyvyn vuoksi saatat uhrata tietojen johdonmukaisuuden sekä kyvyn yhdistää tietoja, käyttää SQL:ää ja tehdä nopeita massapäivityksiä.
Lisätietoa:
MySQL vs. MongoDB
MySQL vs. MongoDB. MongoDB: Looking At Relational and Non-Relational Databases
10 things you should know about NoSQL databases
Introduction to Databases
Difference between SQL and NoSQL : Comparision
SQL vs. NoSQL Database Differences Explained with few Example DB
NoSQL, NewSQL, or RDBMS: How To Choose
NewSQL – RDBMS on Steroids
NoSQL vs NewSQL Databases Choose the Right Tool for the Right Job
SQL vs NoSQL: you do want to have a relational storage by default
Oracle Defends Relational DBs Against NoSQL Competitors
Understanding NoSQL on Microsoft Azure
Meet the Avant-Garde of New Relational Databases
To SQL or NoSQL? Se on tietokantakysymys
CAP Theorem: Revisited
Mitä todella uutta NewSQL:ssä on?
MongoDB vs MySQL: Vertaileva tutkimus tietokannoista
SQL- ja NoSQL-tietokantojen ominaisuudet ja erot