SQL vs NoSQL: melyik adatbázist használja az appod?

Az SQL-adatbázisok (más néven relációs adatbázisok) meghatározott szerkezetű táblákban – sorokban és oszlopokban – tárolják az adatokat, és a kapcsolódó táblákat összekötik. Lekérdezésükhöz az SQL nyelvet használod. Példák: Postgres, MySQL és SQLite. A NoSQL-adatbázisok más módokon tárolják az adatokat – dokumentumokban, kulcs-érték párokban, széles oszlopokban vagy gráfokban –, és általában rugalmasabb szerkezetet engednek. Példák: MongoDB, Redis, DynamoDB és Firestore. A legtöbb üzleti appnál az SQL-adatbázis az ésszerű alapértelmezés; a NoSQL konkrét feladatoknál jeleskedik.

Miért fontos ez a döntés MI-vel építkezve

Az adatbázis az appnak az egyik legnehezebben megváltoztatható része. A képernyőket egy délután alatt át lehet tervezni; évek ügyfél-adatainak másik típusú adatbázisba költöztetése viszont projekt.

Ha egy MI-appépítő neked ad adattárolást, ezek közül választ. Ha ismered a különbséget, segít abban, hogy:

• megértsd, hogy néz ki az adatod, és hogy képes-e megválaszolni a később felmerülő kérdéseidet („bevétel havonta, termékenként”);
• értékelni tudd a platformválasztásokat. Egyes platformok dokumentumadatbázisra épülnek, mások relációsra. Példáért lásd: Supabase vs Firebase, ahol mindkét típus szerepel;
• elkerüld a szolgáltatóhoz kötődést. Az SQL közös szabvány, ezért a relációs adatok általában könnyebben átköltözhetők szolgáltatók között.

Hétköznapi hasonlat

Az SQL-adatbázis olyan, mint egy gondosan megtervezett táblázatkészlet szigorú oszlopokkal: egy lap az ügyfeleknek, egy a rendeléseknek, és minden rendelés-sor az ügyfél-sorra mutat az azonosítójával. Egy lap minden sorának ugyanazok az oszlopai. Kis tervezést igényel, de a lapok közötti kérdések könnyen feltehetők, és az adatok rendezettek maradnak.

A NoSQL dokumentumadatbázis olyan, mint egy mappákkal teli iratszekrény. Minden ügyfél mappájában benne lehet az adatai és a rendelései is, és egy mappában lehetnek olyan papírok, amelyek másokéban nincsenek. Egy ügyfél teljes történetét gyorsan elővehetjük. Arra a kérdésre, hogy „mit rendelt mindenki tavaly?”, viszont sok mappát kell kinyitni.

A valódi különbségek

A „NoSQL” nem egy dolog. A főbb típusok:

Példa: ugyanaz a bolti adat, két módon

Vegyünk egy kis webshopot egy vásárlóval és a rendeléseivel.

SQL (relációs): az adatok táblákra oszlanak, és azonosítókkal kapcsolódnak.

-- 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;

Ha Lena megváltoztatja az e-mail-címét, az egy helyen módosul. A „vásárlónkénti összes eladás ebben a hónapban” kérdés egy lekérdezés.

NoSQL (dokumentum): a rendelései a saját dokumentumában élhetnek.

{
  "_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"] }
  ]
}

Lena profiloldalának betöltése a rendeléseivel egyetlen olvasás. Viszont az összes vásárlót érintő kérdések – a hónap legkelendőbb terméke – több munkát igényelnek, és ha ugyanazok a termékadatok sok rendelésbe másolódnak, azok szinkronban tartása az app feladata lesz.

Egyik sem rossz. A kérdés az, hogy az appod melyik mintát használja legtöbbet.

Hogyan válassz

A relációs SQL-adatbázis általában a jó alapértelmezés, ha:

• az adataidban sok kapcsolat van: felhasználók, csapatok, foglalások, számlák, termékek;
• riportokra, szűrőkre és összegekre lesz szükséged a rekordok között;
• számít a pontosság: pénz, készletszintek, jogosultságok.

A NoSQL-adatbázis akkor érdemes, ha:

• gyors gyorsítótárra vagy munkamenet-tárolóra van szükséged – a Redis erre gyakran használt, gyakran egy SQL-adatbázis mellett;
• a rekordjaid száma nagy, egyszerűek és függetlenek, például eseménynaplók vagy szenzoradatok;
• egy olyan platformot használsz, amely köré épült, például a Firebase Firestore-ját, és a valós idejű funkciói a fő vonzerő.

Sok app mindkettőt használja: az SQL az elsődleges forrás, a NoSQL pedig gyorsítótárazásra vagy egy konkrét funkcióra.

Kulcsfogalmak

Gyakori tévhitek

• „A NoSQL-ben nincs séma.” Az adatodnak mindig van alakja. NoSQL-nél az adatbázis nem biztos, hogy érvényesíti, tehát a kódodnak kell.
• „Az SQL nem skálázódik.” A relációs adatbázisok nagyon nagy szolgáltatásokat futtatnak. A legtöbb app soha nem közelíti meg a határaikat.
• „A NoSQL mindig gyorsabb.” Csak arra a mintára, amelyre tervezték. Egy keresztmetszeti riport lassabb lehet.
• „Örökre egyet kell választanod.” Sok app mindkettőt kombinálja. A Postgres és más SQL-adatbázisok JSON-t is tárolnak, így néhány rugalmas mezőhöz nincs szükség NoSQL-re.
• „A NoSQL azt jelenti, hogy nem használhatsz SQL-t.” A nevet általában úgy olvassák, hogy „nem csak SQL”, és egyes NoSQL-termékek SQL-szerű lekérdezési nyelvet kínálnak.

Mit kérdezz az MI-építődtől

• „Milyen adatbázist használ ez az app, és miért illik az adataimhoz?”
• „Rajzold fel a táblákat vagy gyűjteményeket és azok kapcsolatait.”
• „Mely riportokat akarom majd hat hónap múlva? Könnyen meg tudja válaszolni ezt az adatbázis?”
• „Ha néhány mező valóban rugalmas, JSON-ként tárold a Postgresben a külön adatbázis helyett.”
• „Csak akkor adjunk gyorsítótárat, ha mért sebességproblémánk van.”

Adatbázisok a Mythexben

A Mythex minden olyan projektnek, amelynek szüksége van rá, saját dedikált Postgres-adatbázist ad – egy relációs SQL-adatbázist –, amelyet akkor adunk hozzá, amikor az app igényli, akár csevegésben kérve, akár a /database paranccsal (Adatbázis). Ez a legtöbb üzleti appnak megfelel: felhasználók, foglalások, rendelések és riportok. Ha valamilyen külső szolgáltatásra van szükséged, például egy hosztolt dokumentumadatbázisra, az ügynök olyan kódot írhat, amely a projekt titkos kulcsaiddal csatlakozik hozzá. A nyelv magáról, az SQL-ről a mi az SQL oldalon olvashatsz többet.

Kérdések