Kiekviena šiuolaikinė programėlė po savo „kapotu“ slepia nematomą, bet gyvybiškai svarbų variklį - duomenų bazių valdymo sistemą (DBVS). Nors kūrėjai ir analitikai kasdien rašo SQL užklausas, pati sistema jiems dažnai lieka mistinė „juodoji dėžė“. Tačiau siekiant aukščiausio našumo, būtina suprasti koncepciją, kurią inžinieriai vadina Life of a Query (užklausos gyvavimo ciklas).
1. Kodėl DBVS nėra tik OS papildinys ir kaip veikia užklausų gyvavimo ciklas
Daugelis klaidingai mano, kad DBVS yra tiesiog paprasta programa, veikianti operacinėje sistemoje (OS). Svarbiausias šio etapo momentas - Admission Control (priėmimo kontrolė). Prieš užklausai pradedant darbą, Process Manager turi nuspręsti, ar sistemoje yra pakankamai resursų. Jei DBVS tiesiog aklai vykdytų visas užklausas, įvyktų sistemos „dusimas“ (thrashing), kai procesorius visą laiką praleidžia keisdamas atminties puslapius, o ne dirbdamas naudingą darbą.
Kodėl DBVS nepasitiki OS gijomis? Standartinės OS gijos (kernel threads) turi didelį Context Switch (konteksto perjungimo) viršsvorį. Todėl efektyvios sistemos dažnai naudoja lengvasvores DBMS threads (LWT), kurios valdomos vartotojo erdvėje (user-space).
Taip pat svarbu suprasti, kad 1974 m. spalio 31 d. „IBM System R“ kūrėjai atrado klaidą, kuri dabar žinoma kaip „Helovino problema“. Mechanizmas: Jei sistema naudoja indeksų skenavimą (index scan) pagal algos stulpelį, atnaujintas įrašas (su padidinta alga) fiziškai pajuda B+Tree indekso lapų mazguose į dešinę, nes jo vertė padidėjo. Jei skenavimas tęsiasi ta pačia kryptimi, tas pats darbuotojas vėl surandamas vėlesniame etape, jo alga vėl padidinama, ir jis vėl „pajuda“ toliau. Sprendimas: Šiuolaikinės DBVS taiko Materialization (materializacijos) metodą. Prieš pradedant modifikavimą, sistema sukuria snapshot’ą - surenka visus keistinus įrašų identifikatorius (RID) į laikiną sąrašą.
2. NoSQL nėra tiesiog „modernesnė“ SQL versija
NoSQL nėra tiesiog „modernesnė“ SQL versija. Dauguma NoSQL sistemų pasirenka „galutinį nuoseklumą“ (eventual consistency), kur kaina už horizontalų mastelį yra stale reads (pasenusių duomenų skaitymas).
Taip pat skaitykite: netiesinės funkcinės priklausomybės pavyzdžiai
3. Temporalinė kontrolė ir našumo ribos moderniose sistemose
Šiuolaikinėse sistemose, kur I/O operacijos atliekamos greitais SSD/NVMe diskais, pagrindiniu stabdžiu tampa ne diskas, o CPU ir RAM duomenų kopijavimas. Čia kritiškai svarbi Temporal Control (laiko kontrolė). DBVS privalo kontroliuoti, kada duomenys pasiekia diską. Tai tiesiogiai susiję su Write Ahead Logging (WAL) protokolu: log’o įrašai privalo pasiekti diską anksčiau nei patys duomenys. Jei OS savavališkai perrikiuotų įrašus (o tai ji mėgsta daryti dėl optimizacijos), sistemos gedimo atveju duomenų bazė taptų korumpuota.
4. Transakcijų izoliacija: kompromisai tarp tikslumo ir našumo
Transakcijų izoliacija yra balansavimas tarp preciziškumo ir greičio. Phantom Problem (šmėklų problema) atsiranda tada, kai viena transakcija skaito įrašų diapazoną (pvz., visas sąskaitas > 1000 €), o kita transakcija tuo metu įterpia naują įrašą, atitinkantį tą kriterijų. Tobula izoliacija (Serializability) reikalauja, kad Lock Manager užrakintų ne tik esamus įrašus, bet ir „skyles“ tarp jų (indeksų diapazonus). Tai itin brangu resursų prasme, todėl dauguma sistemų pagal nutylėjimą leidžia tam tikrą netvarką, kad el. Duomenų bazė nėra tik pasyvi saugykla - tai sudėtingas orkestras, derinantis fizinę erdvę ir laiką.
5. Ateities iššūkiai: daugiabrandsčiai lizdai ir iššūkiai darnos koordinaacijoje
Vis dėlto ateitis kelia naujus iššūkius. Mes judame link „many-core“ architektūrų su tūkstančiais branduolių viename luste. Pagrindinis butelio kaklelis persikelia iš I/O į koordinaciją atminties kelyje. Ar mūsų dabartinė architektūra, sukurta dar aštuntajame dešimtmetyje, atlaikys pasaulį, kuriame procesoriaus branduolių koordinavimas kainuoja brangiau nei pats duomenų skaitymas?
6. SQL ir NoSQL: kas yra iš tikrųjų
SQL gali būti naudojama relacijinių duomenų bazių kūrimui ir įvairių operacijų su esamomis duomenų bazėmis atlikimui, įskaitant duomenų užklausas. Tai yra standartinis žinantinklio kūrėjų, duomenų analitikų ir tyrėjų repertuaras. SQL yra „struktūrinė užklausų kalba“ ir gali būti naudojama užklausoms į duomenų bazes, kuriose yra struktūrizuoti arba reliačiniai duomenys. Kalba yra pagrįsta „relacinių algebros“ principu, tai yra matematinė teorija duomenų struktūrizavimui ir užklausų rezultatų skaičiavimui. Daugelis SQL ypatybių kilusios iš šio matematinių pagrindų.
Svarbi ypatybė - SQL veikia kaip sąsaja sąveikauti su religinėmis duomenų bazių valdymo sistemomis (RDBMS). Reliacinę duomenų bazę galima įsivaizduoti kaip lentelę, kurioje kiekvienoje eilutėje yra iš anksto nustatytas atributų rinkinys, užpildytas reikšmėmis. Tačiau SQL turi ir trūkumų: didelis technologijų sudėtingumas, kelių komandų ir sąlygų gausa, kuri naujokams gali būti iššūkis. Taip pat schema keitimo sunkumai ir geografiškai sunku pasirinkti SQL duomenų bazės vietą.
Taip pat skaitykite: Koreliacijos ir funkcinės priklausomybės metodų palyginimas
Nuo pat pradžių SQL radosi skaitmeninės revoliucijos pradžioje ir iki šiol išlieka fenomenaliai aktualus. ORDBMS, pvz., PostgreSQL, naudoja SQL kaip užklausų kalbą, bet taip pat palaiko pagrindines objekto orientuoto programavimo koncepcijas. Objekto hierarchijas ir elgseną galima naudoti be ORM. SQL pagrįstos DBVS skiriamos struktūrizuotiems duomenims saugoti, tačiau ne vis tiek visi duomenys atitinka nustatytą schemą. Čia į pagalbą ateina NoSQL duomenų bazės, kurios dažnai taiko dokumentų pagrindą ir leidžia lankstesnį schemos keitimą bei didesnį plėtimumą.
- NoSQL privalumai: lankstumas, pritaikymas didelėms pagal duomenų struktūrų įvairovėms, dažnai paprastesnis mastelio didinimas, dažnai geresnis našumas ad hoc užklausoms.
- NoSQL trūkumai: dėl jų dažnai nėra tokio tvirto transakcijų palaikymo kaip tradicinėse RDBMS, gali būti didesnių sudėtingumų užtikrinant duomenų vientisumą, priklauso nuo taikymo scenarijaus.
Tačiau NoSQL sprendimai dažnai siūlo pranašumus: dokumentų pagrindu saugo duomenis, duomenys gali būti savaime užrašomi, o schemos keitimas vyksta lengviau. Tai ypač naudinga lanksčiam Duomenų modeliavimui ir didelėms aplinkoms su kintančiais duomenų reikalavimais.
Taip pat skaitykite: kaip veikia duomenų bazių normalizavimas
tags: #sql #funkcine #priklausomybe