Alussa oli tiedostoja. Myöhemmin siellä oli navigointitietokantoja, jotka perustuivat jäsenneltyihin tiedostoihin. Sitten oli IMS ja CODASYL, ja noin 40 vuotta sitten meillä oli joitain ensimmäisiä relaatiotietokantoja. Suurimman osan 1980- ja 1990-luvuista "tietokanta" tarkoitti tiukasti "relaatiotietokantaa". SQL hallitsi.
Sitten olio-ohjelmointikielien kasvavan suosion myötä jotkut ajattelivat, että olio-orientoitujen kielten ja relaatiotietokantojen "impedanssin epäsuhta" oli kartoittaa objekteja tietokannassa. Siten päädyimme "olio-tietokantoihin". Kohdetietokantojen hauska asia oli, että monissa tapauksissa ne olivat periaatteessa normaali tietokanta, johon oli sisäänrakennettu objektikartoitin. Niiden suosio heikkeni ja seuraava todellinen massamarkkinoiden yritys oli “NoSQL” 2010-luvulla.
Hyökkäys SQL: ään
NoSQL hyökkäsi sekä relaatiotietokantoihin että SQL: ään samalla tavalla. Suurin ongelma tällä kertaa oli, että Internet oli tuhonnut 40 vuotta vanhan relaatiotietokantojen hallintajärjestelmän (RDBMS) arkkitehtuurin taustalla olevan lähtökohdan. Nämä tietokannat on suunniteltu säästämään arvokasta levytilaa ja skaalautumaan pystysuunnassa. Käyttäjiä oli nyt aivan liian monta ja liikaa yhden rasvapalvelimen käsittelemiseksi. NoSQL-tietokannoissa sanottiin, että jos sinulla olisi tietokanta, jossa ei ole liittymisiä, ei vakiokyselykieliä (koska SQL: n käyttöönotto vie aikaa) ja ilman tietojen eheyttä, voit skaalata vaakasuunnassa ja käsitellä tätä taltiota. Tämä ratkaisi vertikaalisen mittakaavan kysymyksen, mutta toi uusia ongelmia.
Kehitetty rinnakkain näiden online-tapahtumien käsittelyjärjestelmien (OLTP) kanssa oli toinen pääasiassa relaatiotietokanta, jota kutsutaan online-analyyttiseksi käsittelyjärjestelmäksi (OLAP). Nämä tietokannat tukivat relaatiorakennetta, mutta suorittivat kyselyitä tietäen, että ne palauttaisivat valtavia määriä tietoa. Yrityksiä 1980- ja 1990-luvuilla ohjasi edelleen suurelta osin eräkäsittely. Lisäksi OLAP-järjestelmät kehittivät kehittäjille ja analyytikoille mahdollisuuden kuvitella ja tallentaa tietoja n-ulotteisina kuutioina. Jos kuvittelet kaksiulotteisen taulukon ja hakemukset, jotka perustuvat kahteen indeksiin niin, että olet periaatteessa yhtä tehokas kuin vakioaika, mutta otat sen sitten ja lisäät toisen tai toisen ulottuvuuden, jotta voit tehdä olennaisesti kolmen tai useamman tekijän hakuja (sanoa tarjonta, kysyntä ja kilpailijoiden määrä) - voit analysoida ja ennustaa asioita tehokkaammin. Näiden rakentaminen on kuitenkin työlästä ja hyvin eräkeskeistä.
Noin samaan aikaan kuin laajennettava NoSQL, syntyi graafitietokantoja. Monet asiat eivät ole sinänsä "suhteellisia", eivätkä ne perustu joukko-teoriaan ja suhteelliseen algebraan, vaan vanhemman ja lapsen tai ystävä-ystävä-suhteisiin. Klassinen esimerkki on tuotelinja tuotemerkistä malliin komponentteihin. Jos haluat tietää, mikä emolevy on kannettavassa tietokoneessani, huomaat, että valmistajat hankkivat monimutkaisia tuotteita ja tuotemerkki tai mallinumero eivät välttämättä riitä. Jos haluat tietää, mitä kaikkia emolevyjä käytetään tuotelinjassa, klassisessa (ei-CTE- tai Common Table Expression) SQL-ohjelmassa sinun täytyy kävellä taulukoita ja antaa kyselyitä useissa vaiheissa. Aluksi suurin osa kaaviotietokannoista ei sironnut lainkaan. Todellisuudessa monen tyyppinen kaavioanalyysi voidaan tehdä tallentamatta tosiasiallisesti tietoja kaaviona.
NoSQL-lupaukset pidetty ja lupaukset rikki
NoSQL-tietokannat skaalautuivat paljon, paljon paremmin kuin Oracle Database, DB2 tai SQL Server, jotka kaikki perustuvat 40 vuotta vanhaan suunnitteluun. Jokaisella NoSQL-tietokantatyypillä oli kuitenkin uusia rajoituksia:
- Avainarvosäilöt: Yksinkertaista hakua ei ole kuin db.get (avain). Suurta osaa maailman tiedoista ja käyttötapauksista ei kuitenkaan voida jäsentää tällä tavalla. Lisäksi puhumme todella välimuististrategiasta. Ensisijaiset avaimet ovat nopeita missä tahansa tietokannassa; tärkeätä on vain se, mikä on muistissa. Parhaassa tapauksessa nämä mittakaavat muistuttavat hash-karttaa. Jos sinun on kuitenkin tehtävä 30 tietokantamatkaa tietojen palauttamiseksi uudelleen tai tehtävä minkäänlainen monimutkainen kysely - tämä ei tule toimimaan. Nämä toteutetaan nyt useammin välimuistina muiden tietokantojen edessä. (Esimerkki: Redis.)
- Asiakirjatietokannat: Nämä saavuttivat suosionsa, koska käyttävät JSONia ja objektit on helppo sarjoittaa JSON: iin. Näiden tietokantojen ensimmäisillä versioilla ei ollut liittymiä, ja koko "entiteettisi" yhdellä jättimäisellä asiakirjalla oli omat haittansa. Ilman transaktiotakeita sinulla oli myös tietojen eheysongelmia. Nykyään jotkut asiakirjatietokannat tukevat vähemmän vankkaa tapahtumamuotoa, mutta se ei ole sama takuu, johon useimmat ihmiset ovat tottuneet. Jopa yksinkertaisissa kyselyissä nämä ovat usein hitaita latenssin suhteen - vaikka ne skaalautuisivatkin paremmin koko alueella. (Esimerkkejä: MongoDB, Amazon DocumentDB.)
- Sarakemyymälät: Nämä ovat yhtä nopeita kuin avainarvomyynnit hakuja varten ja ne voivat tallentaa monimutkaisempia tietorakenteita. Kolmen pöydän (RDBMS-kielellä) tai kolmen kokoelman (MongoDB-kielellä) yhdistämisen näyttävän tekeminen on kuitenkin parhaimmillaan tuskallista. Nämä ovat todella hyviä aikasarjatietoihin (anna minulle kaikki, mitä tapahtui klo 13.00–14.00).
Ja on olemassa muita, esoteerisempia NoSQL-tietokantoja. Kaikilla näillä tietokannoilla on kuitenkin ollut yhteistä tuen puute yhteisille tietokannan idioomeille ja taipumus keskittyä "erityistarkoitukseen". Jotkut suositut NoSQL-tietokannat (esim.MongoDB) kirjoittivat upeita tietokantapäätteitä ja ekosysteemityökaluja, jotka tekivät kehittäjien käyttöönoton todella helpoksi, mutta suunnittelivat vakavia rajoituksia tallennusmoottorissaan - puhumattakaan joustavuuden ja skaalautuvuuden rajoituksista.
Tietokantastandardit ovat edelleen tärkeitä
Yksi asioista, jotka tekivät relaatiotietokannoista hallitsevia, oli se, että niillä oli yhteinen työkalujen ekosysteemi. Ensinnäkin, siellä oli SQL. Vaikka murteet voivat olla erilaisia - kehittäjänä tai analyytikkona, jos siirryt SQL Server 6.5: stä Oracle 7: ään, joudut ehkä joutumaan korjaamaan kyselysi ja käyttämään "(+)" -merkkiä ulkoisiin liitoksiin - mutta yksinkertaiset asiat toimivat ja kovat asiat olivat kohtuullisen helppoja kääntää.
Toiseksi sinulla oli muun muassa ODBC ja myöhemmin JDBC. Lähes mikä tahansa työkalu, joka voisi muodostaa yhteyden yhteen RDBMS: ään (ellei se ole tehty nimenomaan kyseisen RDBMS: n hallitsemiseksi), voisi muodostaa yhteyden mihin tahansa muuhun RDBMS: ään. On paljon ihmisiä, jotka muodostavat yhteyden RDBMS-järjestelmään päivittäin ja imevät tiedot Exceliin analysoidakseen sen. En tarkoita Tableaua tai mitään satoja muita työkaluja; Puhun "äitilaivasta", Excelistä.
NoSQL poisti standardit. MongoDB ei käytä SQL: ää ensisijaisena kielenä. Kun MongoDB: n lähin kilpailija Couchbase etsii kyselykieliä Java-pohjaisen mapreduce-kehyksen korvaamiseksi, he loivat oman SQL-murteensa.
Standardit ovat tärkeitä tukeakseen työkalujen ekosysteemiä vai siksi, että monet tietokantoja kyselevistä ihmisistä eivät ole kehittäjiä - ja he tietävät SQL: n.
GraphQL ja valtionhallinnon nousu
Tiedät kenellä on kaksi peukaloa ja joka vain haluaa sovelluksensa tilan päästä tietokantaan, eikä välitä miten? Tämä kaveri. Ja osoittautuu koko kehittäjien sukupolvi. GraphQL - jolla ei ole mitään tekemistä graafitietokantojen kanssa - tallentaa objektikuvaajan alla olevaan tietopalveluun. Se vapauttaa kehittäjän huolehtimasta tästä ongelmasta.
Aikaisempi yritys tähän olivat objektisuhdekartoitustyökalut tai ORM: t, kuten horrostila. He ottivat objektin ja muuttivat sen pohjimmiltaan SQL: ksi, joka perustui objekti-taulukko-kartoitusasetuksiin. Monia tämän ensimmäisistä sukupolvista oli vaikea määrittää. Lisäksi olimme oppimiskäyrällä.
Suurin osa GraphQL-toteutuksista toimii objektisuhdekartoitustyökalujen, kuten Sequelize tai TypeORM, kanssa. Hyvin jäsennelty GraphQL-toteutus ja sovellusliittymä kirjoittavat ja palauttavat asiaankuuluvat tiedot sen sijaan, että olisit vuotanut valtionhallinnasta huolimatta koodissasi, kun muutos tapahtuu objektikaaviossasi. Kuka välittää sovellustasolla, miten tiedot tallennetaan?
Yksi olio- ja NoSQL-tietokantojen perusta oli se, että sovelluskehittäjän oli oltava tietoinen monimutkaisuudesta, kuinka tietoja tallennetaan tietokantaan. Kehittäjien oli luonnollisesti vaikea hallita uudempia tekniikoita, mutta se ei ole enää vaikeaa. Koska GraphQL poistaa tämän huolen kokonaan.
Syötä NewSQL tai hajautettu SQL
Googlella oli tietokantaongelma, ja hän kirjoitti paperin ja myöhemmin "Spanner" -nimisen toteutuksen, jossa kuvattiin, miten globaalisti jaettu relaatiotietokanta toimisi. Spanner herätti uuden innovaatioa relaatiotietokantatekniikassa. Sinulla voi todella olla relaatiotietokanta ja saada se skaalautumaan paitsi sirpaleilla myös tarvittaessa ympäri maailmaa. Ja puhumme nykyaikaisessa mittakaavassa, ei usein pettymys ja jatkuvasti monimutkainen RAC / Streams / GoldenGate -tapa.
Joten oletus "esineiden varastoimisesta" relaatiojärjestelmään oli väärä. Entä jos relaatiotietokantojen suurin ongelma olisi takapää eikä etupää? Tämä on ajatus ns. "NewSQL": stä tai paremmin "hajautetusta SQL" -tietokannasta. Ajatuksena on yhdistää NoSQL-tallennusopinnot ja Google's Spanner-idea kypsäyn, avoimeen lähdekoodiin, RDBMS-käyttöliittymään, kuten PostgreSQL tai MySQL / MariaDB.
Mitä tuo tarkoittaa? Se tarkoittaa, että sinulla on kakku ja syödä sitä. Se tarkoittaa, että sinulla voi olla useita solmuja ja skaalata vaakasuoraan - myös pilvien saatavuuden vyöhykkeillä. Se tarkoittaa, että sinulla voi olla useita datakeskuksia tai pilvimaantieteellisiä alueita - yhdellä tietokannalla. Se tarkoittaa, että sinulla voi olla todellinen luotettavuus, tietokantaryhmä, joka ei koskaan putoa käyttäjien kannalta.
Sillä välin koko SQL-ekosysteemi toimii edelleen! Voit tehdä tämän rakentamatta koko IT-infrastruktuuria. Vaikka et välttämättä pelaisikaan "kopioimaan ja korvaamaan" perinteistä RDBMS-järjestelmääsi, useimmat yritykset eivät yritä käyttää enemmän Oraclea. Ja mikä parasta, voit silti käyttää SQL: ää ja kaikkia työkalujasi sekä pilvessä että ympäri maailmaa.
