SQL vs NoSQL: kuru datubāzi lietotnei izvēlēties?

SQL datubāzes (saukta arī par relāciju datubāzēm) glabā datus tabulās ar noteiktu struktūru — rindās un kolonnās — un savieno saistītas tabulas. Vaicājumus veido ar SQL valodu. Piemēri ir Postgres, MySQL un SQLite. NoSQL datubāzes glabā datus citādi — dokumentos, atslēgu-vērtību pāros, plašās kolonnās vai grafos — un parasti ļauj elastīgāku struktūru. Piemēri ir MongoDB, Redis, DynamoDB un Firestore. Vairumam biznesa lietotņu SQL datubāze ir saprātīga noklusējuma izvēle; NoSQL izceļas konkrētos uzdevumos.

Kāpēc šī izvēle ir svarīga, veidojot ar AI

Datubāze ir viena no grūtāk maināmajām lietotnes daļām. Ekrānus var pārveidot vienas pēcpusdienas laikā; pārcelt gadiem uzkrātus klientu datus uz citu datubāzes veidu ir projekts.

Kad AI lietotņu veidotājs pievieno datu glabāšanu, tas izvēlas kādu no šiem variantiem. Zinot atšķirību, tu vari:

• Saprast, kā izskatās tavi dati un vai tie spēs atbildēt uz jautājumiem, ko uzdosi vēlāk ("ieņēmumi pa mēnešiem pa produktiem").
• Novērtēt platformu izvēles. Dažas platformas balstās uz dokumentu datubāzi, citas uz relāciju. Piemēram, skat. Supabase vs Firebase.
• Izvairīties no piesaistes vienam pakalpojumam. SQL ir kopīgs standarts, tāpēc relāciju dati parasti ir vieglāk pārvietojami starp pakalpojumu sniedzējiem.

Ikdienas salīdzinājums

SQL datubāze ir kā rūpīgi izveidotu tabulu komplekts ar stingrām kolonnām: viena lapa klientiem, otra pasūtījumiem, un katra pasūtījuma rinda norāda uz klienta rindu pēc ID. Katrai lapas rindai ir vienādas kolonnas. Tam vajag nedaudz plānošanas, bet jautājumi starp lapām ir viegli un dati paliek sakārtoti.

NoSQL dokumentu datubāze ir kā mapju skapis. Katra klienta mape var saturēt viņa datus un pasūtījumus kopā, un vienā mapē var būt papildu papīri, kādu citās nav. Viena klienta visa vēsture ir ātri pieejama. Atbildēt uz jautājumu "ko visi pasūtīja pagājušajā mēnesī?" nozīmē atvērt daudzas mapes.

Reālās atšķirības

"NoSQL" nav viena lieta. Galvenie veidi:

Praktisks piemērs: tie paši veikala dati, divos veidos

Paņemsim mazu tiešsaistes veikalu ar vienu klienti un viņas pasūtījumiem.

SQL (relāciju): dati ir sadalīti tabulās un savienoti ar ID.

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

Ja Lena nomaina e-pastu, tas mainās vienā vietā. Jautājums "kopējā pārdošana katram klientam šomēnes" ir viens vaicājums.

NoSQL (dokumenti): viņas pasūtījumi var atrasties tieši viņas dokumentā.

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

Lenas profila lapas ielāde ar visiem pasūtījumiem ir viens lasījums. Bet jautājumi, kas šķērso visus klientus — šomēnes vislabāk pārdotais produkts — prasa vairāk darba, un, ja tās pašas produkta detaļas ir nokopētas daudzos pasūtījumos, to sinhronizēšana kļūst par lietotnes uzdevumu.

Neviens no variantiem nav nepareizs. Jautājums ir, kuru modeli tava lietotne izmanto visbiežāk.

Kā izvēlēties

Relāciju SQL datubāze parasti ir pareizais noklusējums, ja:

• Tavi dati ir ar daudzām saistībām: lietotāji, komandas, rezervācijas, rēķini, produkti.
• Tev vajag pārskatus, filtrus un kopsummas pa ierakstiem.
• Pareizība ir svarīga: nauda, krājumi, tiesības.

NoSQL datubāze ir vērts apsvērt, ja:

• Tev vajag ātru kešatmiņu vai sesiju krātuvi — šeit bieži lieto Redis, parasti kopā ar SQL datubāzi.
• Tavu ierakstu ir ļoti daudz, tie ir vienkārši un neatkarīgi, piemēram, notikumu žurnāli vai sensoru rādījumi.
• Tu strādā uz platformas, kas balstīta uz NoSQL, piemēram, Firebase Firestore, un tās reāllaika funkcijas ir galvenais iemesls.

Daudzas lietotnes izmanto abas: SQL kā galveno datu avotu, bet NoSQL krātuvi kešatmiņai vai konkrētai funkcijai.

Galvenie termini

Biežākie maldi

• "NoSQL nozīmē, ka nav shēmas." Tavi dati vienmēr kaut kādu formu ir. Ar NoSQL datubāze to var neuzspiest, tāpēc to jānodrošina kodam.
• "SQL nemērogojas." Relāciju datubāzes darbina ļoti lielus pakalpojumus. Vairums lietotņu nekad nesasniedz to robežas.
• "NoSQL vienmēr ir ātrāks." Tikai tiem modeļiem, kuriem tas ir paredzēts. Šķērsgriezuma pārskats var būt lēnāks.
• "Jāizvēlas viens uz visiem laikiem." Daudzas lietotnes apvieno abus. Turklāt SQL datubāzes, piemēram, Postgres, glabā arī JSON, tāpēc daži elastīgi lauki nepieprasa NoSQL.
• "NoSQL nozīmē, ka nevar izmantot SQL." Nosaukumu parasti lasa kā "ne tikai SQL", un dažiem NoSQL produktiem ir SQL līdzīgas vaicājumu valodas.

Ko jautāt savam AI veidotājam

• "Kāda datubāze šai lietotnei tiek izmantota un kāpēc tā der maniem datiem?"
• "Uzzīmē tabulas vai kolekcijas un to savstarpējās saistības."
• "Kādus pārskatus es gribēšu pēc sešiem mēnešiem? Vai šī datubāze tos viegli sniegs?"
• "Ja daži lauki patiešām ir elastīgi, glabā tos kā JSON Postgres, nevis pievieno otru datubāzi."
• "Pievieno kešatmiņu tikai tad, ja mums ir izmērīta ātruma problēma."

Datubāzes Mythex

Mythex katram projektam, kam tāda vajadzīga, piešķir atsevišķu Postgres datubāzi — relāciju SQL datubāzi — kad lietotnei tā ir nepieciešama. To var pieprasīt čatā vai ar komandu /database (Database). Tas der vairumam biznesa lietotņu: lietotājiem, rezervācijām, pasūtījumiem un pārskatiem. Ja vajag konkrētu ārēju pakalpojumu, piemēram, pārvaldītu dokumentu datubāzi, aģents var uzrakstīt kodu, kas ar to savienojas, izmantojot atslēgas, ko glabā kā projekta noslēpumus. Lai uzzinātu vairāk par pašu valodu, lasi kas ir SQL.

Jautājumi