SQL vs NoSQL: Mitä tietokantaa sovelluksesi kannattaa käyttää?

SQL-tietokannat (kutsutaan myös relaatiotietokannoiksi) tallentavat datan tauluihin, joilla on määritelty rakenne: rivejä ja sarakkeita. Toisiinsa liittyvät taulut linkitetään keskenään. Kyselyt tehdään SQL-kielellä. Esimerkkejä ovat Postgres, MySQL ja SQLite. NoSQL-tietokannat tallentavat dataa muilla tavoilla, kuten dokumentteina, avain-arvopareina, leveinä sarakkeina tai graafeina, ja ne sallivat yleensä joustavamman rakenteen. Esimerkkejä ovat MongoDB, Redis, DynamoDB ja Firestore. Useimpiin liiketoimintasovelluksiin SQL on järkevä oletus, ja NoSQL loistaa tiettyihin tehtäviin.

Miksi tämä valinta on tärkeä tekoälyllä rakennettaessa

Tietokanta on yksi sovelluksen vaikeimmin muutettavista osista. Näkymät voi suunnitella uudelleen iltapäivässä, mutta vuosien asiakasdatan siirtäminen eri tyyppiseen tietokantaan on projekti.

Kun tekoälysovellusrakentaja lisää sovellukselle datan tallennuksen, se valitsee jonkin näistä. Erojen tunteminen auttaa sinua:

• Ymmärtämään, miltä datasi näyttää ja voiko se vastata kysymyksiin, joita kysyt myöhemmin („liikevaihto kuukausittain tuotteittain“).
• Arvioimaan alustavalintoja. Osa alustoista on rakennettu dokumenttitietokannan, osa relaatiotietokannan varaan. Katso Supabase vs Firebase, joka on yleinen esimerkki kummastakin.
• Välttämään lukkiutumista. SQL on yhteinen standardi, joten relaatiodataa on yleensä helpompi siirtää palveluntarjoajalta toiselle.

Arkinen vertauskuva

SQL-tietokanta on kuin huolellisesti suunniteltu joukko taulukkolaskentoja tiukoilla sarakkeilla: yksi välilehti asiakkaille, yksi tilauksille, ja jokainen tilausrivi viittaa asiakasrivin tunnukseen. Jokaisella välilehdellä on samat sarakkeet. Suunnittelua vaatii hieman, mutta kysymykset välilehtien yli ovat helppoja ja data pysyy siistinä.

NoSQL-dokumenttitietokanta on kuin arkisto täynnä kansioita. Jokaisen asiakkaan kansioon voi kuulua hänen tietonsa ja tilauksensa yhdessä, ja yhteen kansioon voi kuulua ylimääräisiä papereita, joita muilla ei ole. Yhden asiakkaan koko tarina löytyy nopeasti. Vastaus kysymykseen „mitä kaikki tilasivat viime kuussa?“ vaatii kuitenkin monen kansion avaamista.

Todelliset erot

„NoSQL“ ei ole yksi asia. Pääasialliset tyypit:

Työesimerkki: sama kauppadata kahdella tavalla

Otetaan pieni verkkokauppa, jolla on asiakas ja hänen tilauksensa.

SQL (relaatio): data on jaettu tauluihin ja linkitetty tunnuksilla.

-- customers: id=1, name='Lena Ortiz'
-- orders:    id=101, customer_id=1, total=42.00
--            id=103, customer_id=1, total=25.00

SELECT c.name, SUM(o.total)
FROM customers c JOIN orders o ON o.customer_id = c.id
GROUP BY c.name;

Jos Lena vaihtaa sähköpostinsa, muutos tehdään yhteen paikkaan. Kysymys „kokonaismyynti asiakasta kohden tässä kuussa“ on yksi kysely.

NoSQL (dokumentti): hänen tilauksensa voivat olla hänen dokumentissaan.

{
  "_id": "cust_1",
  "name": "Lena Ortiz",
  "email": "lena@example.com",
  "orders": [
    { "id": 101, "total": 42.00, "items": ["Green tea"] },
    { "id": 103, "total": 25.00, "items": ["Teapot"] }
  ]
}

Henkilön profiilisivun lataaminen kaikkine tilauksineen on yksi luku. Kysymykset, jotka ulottuvat kaikkiin asiakkaisiin, kuten kuukauden myydyin tuote, vaativat enemmän työtä. Jos saman tuotteen tiedot kopioidaan moneen tilaukseen, niiden pitämisestä ajan tasalla vastaa sovellus.

Kumpikaan ei ole väärin. Kysymys kuuluu, mitä mallia sovelluksesi käyttää useimmin.

Miten valita

Relaatiotietokanta SQL on yleensä oikea oletus, jos:

• datallasi on paljon suhteita: käyttäjät, tiimit, varaukset, laskut, tuotteet.
• tarvitset raportteja, suodatuksia ja summia tietueiden yli.
• oikeellisuus on tärkeää: raha, varastosaldot, käyttöoikeudet.

NoSQL-tietokanta kannattaa harkita, jos:

• tarvitset nopean välimuistin tai istuntovaraston. Redis on tässä yleinen, usein SQL-tietokannan rinnalla.
• tietueitasi on valtava määrä, ne ovat yksinkertaisia ja riippumattomia, kuten tapahtumalokit tai anturilukemat.
• käytät alustaa, joka perustuu siihen, kuten Firebasen Firestoreen, ja sen reaaliaikaiset ominaisuudet ovat pääsyy.

Monet sovellukset käyttävät molempia: SQL on pääasiallinen totuuden lähde, ja NoSQL-varasto hoitaa välimuistin tai jonkin tietyn ominaisuuden.

Keskeiset termit

Yleisiä väärinkäsityksiä

• „NoSQL tarkoittaa ettei skeemaa ole.“ Datallasi on aina muoto. NoSQL-tietokanta ei välttämättä valvo sitä, joten sovelluskoodisi joutuu tekemään sen.
• „SQL ei skaalaudu.“ Relaatiotietokannat pyörittävät hyvin suuria palveluja. Useimmat sovellukset eivät lähesty rajojaan koskaan.
• „NoSQL on aina nopeampi.“ Vain niihin käyttötapoihin, joita varten se on suunniteltu. Poikkileikkaava raportti voi olla hitaampi.
• „Valinta on tehtävä lopullisesti.“ Monet sovellukset yhdistävät molemmat. Lisäksi SQL-tietokannat kuten Postgres tallentavat JSONia, joten muutama joustava kenttä ei vaadi NoSQL:ää.
• „NoSQL tarkoittaa, ettei SQL:ää voi käyttää.“ Nimi luetaan yleensä muodossa „not only SQL“, ja osa NoSQL-tuotteista tarjoaa SQL-tyyppisiä kyselykieliä.

Mitä kysyä tekoälyrakentajalta

• „Mitä tietokantaa tämä sovellus käyttää ja miksi se sopii datalleni?“
• „Piirrä taulut tai kokoelmat ja se, miten ne liittyvät toisiinsa.“
• „Mitä raportteja haluan kuuden kuukauden päästä? Pystyykö tämä tietokanta vastaamaan niihin helposti?“
• „Jos muutama kenttä on todella joustava, tallenna ne JSONina Postgresiin sen sijaan, että lisäisit toisen tietokannan.“
• „Lisää välimuisti vain, jos meillä on mitattu nopeusongelma.“

Tietokannat Mythexissä

Mythex antaa jokaiselle projektille, joka sitä tarvitsee, oman Postgres-tietokannan, eli relaatiollisen SQL-tietokannan. Se lisätään silloin kun sovellus sitä tarvitsee, joko pyytämällä chatissa tai komennolla /database (Database). Tämä sopii useimpiin liiketoimintasovelluksiin: käyttäjät, varaukset, tilaukset ja raportit. Jos tarvitset tiettyä ulkoista palvelua, kuten hallittua dokumenttitietokantaa, agentti voi kirjoittaa koodin, joka yhdistyy siihen projektisi salaisuuksiin tallennettujen avainten kautta. Lisätietoja kielestä itsestään on mitä SQL on.

Kysymykset