Ari Hovin artikkeli on alkujaan julkaistu Tivi-lehden Lokakuu 2015 -numerossa.
Kun relaatiotietokannat 80-luvun lopulla alkoivat yleistyä, ilmestyi markkinoille tukuittain SQL-tietokantatuotteita. Sittemmin isot pelurit ostivat pieniä pois ja merkittäviksi jäivät vain Oracle, SQL Server, MySQL ja DB2.
Nyt on tietokantatuotteita jälleen tarjolla suuri määrä, ja tällä kertaa NoSQL-kannat ovat yleistymässä. MongoDB on jo neljänneksi suosituin tietokantatuote, edellä kolme relaatiokantaa. Miksi se on noussut tällaiseen asemaan?
MongoDB:n lähtökohtana v. 2007 oli relaatiokantoja ketterämpi skaalautuvuus tietomassojen kasvaessa sekä tiettyjen operaatioiden hyvä suorituskyky. Toinen tavoite oli mutkaton, helppo tietokannan käsittely. MongoDB:stä tulikin nuoren ohjelmoijasukupolven hittituote.
Relaatiokannoissa rivit talletetaan tauluihin, MongoDB:ssä vastaavasti dokumentit talletetaan kokoelmiin. Dokumentti voi olla hierarkkinen, jolloin monen taulun asiat voidaan tallettaa yhteen dokumenttiin. Rakennemuoto on sama JSON, joka on vakiintunut ohjelmoinnissa ja rajapinnoissa. Helpottaa ohjelmointia kun ei tarvitse muuntaa olio-ohjelmoinnin rakenteita relaatiomuotoon vaan voi tallettaa samalla rakenteella.
Helposti alkuun
Tietokannasta hakeminen on puolestaan monimutkaisempaa, MongoDB kun ei lähtökohtaisesti sisällä hauissa kätevää SQL-kieltä. Yhden hierarkkisen dokumentin haut ovat nopeita, mutta useita dokumentteja yhdistelevät haut voivat olla hankalia ja hitaita. Relaatiokantaihmisten rakastamia liitoksia ei ole, ne tehdään ohjelmoinnin puolella. Monista NoSQL-tuotteista poiketen SQL-rajapintoja on MongoDB-kantaan tarjolla niukasti. SQL on tärkeä kytkeytymisessä muuhun ympäristöön ja BI-tuotteisiin.
Yksi MongoDB:n suosion syistä on liikkeellelähdön helppous ja edullisuus. Sen voi ladata muutamassa minuutissa ilmaiseksi ja alkaa rakentamaan protoa. Jos hanke on vakava ja kaikki menee hyvin, ostavat isommat talot tukea toimittajalta. Ei siis pakollisia lisenssi- ja versionvaihtomaksuja. Näin tosin tilanne on monilla muillakin tuotteilla, kuten Hadoopilla ja PostgreSQL:lla.
MongoDB kuuluu dokumenttirakenteisten NoSQL-kantojen ryhmään. Toinen tärkeä ryhmä ovat kevyet ns. key-value kannat. Tyypillisesti nämä tietokannat ovat tinkineet joistakin relaatiokantojen tapahtumankäsittelyn eheys- tai turvallisuusominaisuuksista suorituskyvyn ja laajennettavuuden vuoksi. Tekstien, kuvien ja muun ei-strukturoidun tiedon tuki on parempi kuin relaatiokannoissa.
Mitä ominaisuuksia arvostat?
Tietokantatuotteiden kilpailu on nyt kovaa. Vakavia NoSQL-ehdokkaita ovat mm. Redis, MarkLogic, Cassandra ja CouchBase. Myös isot pelurit ovat kaikki mukana. Oraclella on key-value kanta NoSQL, Microsoftilla DocumentDB ja Amazonilla pilvipohjainen DynamoDB. Kannan valinnassa painaa nyt käyttötarkoitus. On mietittävä mistä ominaisuuksista voi luopua saavuttaakseen massojen käsittelykykyä, laajennettavuutta tai ei-strukturoidun tiedon parempaa tukea. Moni pärjää edelleen relaatiokannoilla.
On arvioitu, että NoSQL tuotteiden osuus olisi n. 20%. Relaatiokannat ovat aina kyennet hyvin vastaamaan markkinoiden haasteisiin. Niihin lisätään NoSQL-tyyppisiä ominaisuuksia kuten JSON-tukea. Esimerkiksi suomalainen kovassa nousussa oleva SQL-kanta MariaDB on hyvä skaalautuvuudessa. Tämä kehitys osittain syö markkinoita NoSQL-kannoilta. Samalla nuoret ja hieman raakilemaiset NoSQL –kannat kypsyvät lähemmäs relaatiokantoja mm. tapahtumankäsittelyn eheyden osalta. Vaikka relaatiokannat ovat edelleen toiminnallisuudeltaan monipuolisempia, tilanne elää ja uusiin teknologioihin on nyt syytä tutustua.
Faktalaatikko
NoSQL –kannat
- skaalautuvat helpommin ja pystyvät tallettamaan ei-strukturoitua dataa
- tinkivät tiedon eheydestä suorituskyvyn ja joustavuuden nimissä
- eivät ole relaatiomallin mukaisia, vaan esim. dokumentti- tai key-value -pohjaisia
- eivät edellytä rakenteen etukäteismäärittelyä, mikä helpottaa ohjelmointia ja muutoksia
Skeeman kanssa vai ilman
Relaatiokannoissa taulujen rakenteet eli skeema määritellään ennenkuin tietoja voidaan tallettaa. Taulut ensin perustetaan SQL:n CREATE TABLE –lauseilla, sitten viedään rivit INSERT- komennoilla. Jos myöhemmin tarvitaan uusia sarakkeita, on tehtävä muutos tietokannan tauluun ALTER TABLE –komennolla ja tieysti lisättävä tiedon vienti INSERT-lauseeseen.
NoSQL –kannat ovat yleensä ns. skeemattomia, eli rakennetta ei määritellä etukäteen. Esimerkiksi MongoDB:ssa talletetaan tiedot ja samalla kerrotaan rakenne. Uudet kentät saadaan mukaan ottamalla ne vain mukaan tallennuslauseeseen. Rakennemuutoksille alttiit kannat hyötyvät skeemattomuudesta tietojen talletusvaiheessa. Lukiessa rakenne on tietysti tunnettava.
Tämä joustavuus voi johtaa siihen, että tietokantaa ei suunnitella lainkaan. Parhaiden sovellusten takana on hyvin suunniteltu tietokanta ja tämän tietotaidon soisi jatkuvan. Relaatiokantojen tiedon laatua parantavat viite-eheysmääritykset puuttuvat myös.
