Paks vs. kõhn andmebaas

Arhitektuurilised lähenemised koodikihtide jaotamisele, andmebaasi avalik liides ning jõudluse simulatsioon

Sissejuhatus ja didaktiline eesmärk

Aknapõhistes andmebaasisüsteemides jaguneb kood tavaliselt kasutajaliidese koodiks, äriloogika koodiks ja andmete loogika koodiks. Põhiline arhitektuurne küsimus seisneb selles: kuhu paigutada äriloogika ning kuidas toimub andmetöötlus?

Käesolev õpiobjekt selgitab paksu andmebaasi (thick / smart database) ja kõhna andmebaasi (thin / dumb database) põhimõttelisi erinevusi, tutvustab elutoa analoogiat, Helsingi deklaratsiooni põhimõtteid ning demonstreerib interaktiivse simulatsiooni abil, miks ridade hulgakaupa töötlemine andmebaasi avaliku liidese kaudu tagab kordades suurema töökiiruse ja väiksema serverikoormuse.

Töökiiruse ja ressursikulu simulatsioon

Simuleerime tüüpilist äriloogika ülesannet: uute tellimuste kinnitamine ja soodustuste rakendamine. Võrdleme kolme erinevat arhitektuurilist teostust reaalajas.

Iga tellimus sisaldab keskmiselt 3 tellimuserida ja kliendi staatuse kontrolli.
Ühe võrgupöörde edasi-tagasi aeg rakenduse ja andmebaasi vahel.
Vali simuleeritav arhitektuur ja jälgi andmevoogu.
Ootel
Andmevoo ja päringute reaalajas visualiseerija
Valmis simulatsiooni käivitamiseks
Võrgupäringute arv
0
Võrgupööret
Võrguliiklus
0,0 kB
Saadetud/loetud
Serverite CPU aeg
0,0 s
AB + Rakendus
Kogu kuluvaeg
0,00 s
Latentsus + Arvutus

Arhitektuuride reaalajas tulemuste võrdlus

1. Kõhn andmebaas (Ridade ühekaupa töötlemine) 0,0 s
2. Paks andmebaas (Tsükliline ridade töötlemine baasis) 0,0 s
3. Paks andmebaas (Hulkade kaupa töötlemine, Set-based) 0,0 s
Järeldus: Hulkade kaupa töötlev paks andmebaas kaotab võrguringid ja korduva SQL-analüüsi, saavutades tüüpiliselt 30–100-kordse kiirusevõidu võrreldes tsüklis ridade ühekaupa pärimisega.

Loengu eksperimendi andmed (Oracle)

Üks ja sama ülesanne, kolm lahendust (CPU-sekundites, loengu slaid 24):

Mõõdik Kõhn (ühekaupa) Paks (ühekaupa) Paks (hulgakaupa)
Andmebaasi CPU 437 s 204 s 7 s
Rakenduse CPU 217 s 0 s 0 s
Kokku CPU 654 s 204 s 7 s
Koguaeg (min) 11,0 min - 3,5 min
Allikas: Toon Koppelaars (Helsingi deklaratsioon, 2016).

Arhitektuursed mõisted ja analoogiad

Paks andmebaas ThickDB / SmartDB / Arukas andmebaas
  • Tuumidee: Andmebaasisüsteemi võimalusi kasutatakse maksimaalselt. Äriloogika ja andmetöötlus toimub andmebaasiserveris.
  • Avalik liides: Andmeid loetakse läbi vaadete ja muudetakse läbi salvestatud funktsioonide (andmebaasioperatsioonide lepingute alusel).
  • Töötlusviis: Loomulik on kasutada ridade hulkadel põhinevat (set-based) töötlust.
  • Terviklikkus: Tagatud andmebaasi deklaratiivsete kitsenduste ja trigerite abil tsentraalselt.
  • Helsingi deklaratsioon: Toetab põhimõtet viia andmetele võimalikult lähedale kogu andmetega manipuleerimine.
Kõhn andmebaas ThinDB / Dumb database / Juhm andmebaas
  • Tuumidee: Andmebaas on pelgalt passiivne bitihoidla (tabelid). Kogu äriloogika on viidud rakendusserverisse (Java, Python, C# jne).
  • Andmejuurdepääs: Kasutatakse sageli ORM-vahendeid, mis genereerivad SQL-lauseid otse baastabelite kohal.
  • Töötlusviis: Sage kalduvus ridade ühekaupa töötlemisele tsüklites (N+1 päringute probleem).
  • Terviklikkus: Hajutatud rakenduskoodi vahel; oht rikkuda andmeid, kui baasi kasutab mitu eri rakendust.
  • Eesmärk: Soov hoida rakendus andmebaasisüsteemist sõltumatuna.
1. Elutoa analoogia (Toon Koppelaars)

Paks andmebaas: Äriloogikat realiseerivad rutiinid on koos andmetega ja SQL-mootoriga samas elutoas. Töö toimub kohapeal ilma uksest väljumata.

Kõhn andmebaas: Äriloogikat realiseeriv rakendus peab iga rea saamiseks tulema välisuksest sisse, pühkima jalad puhtaks, minema läbi esiku elutuppa, võtma ühe rea, minema toast välja, viima prügi välja ja esikus vaiba sirgeks tõmbama. Seda korratakse tuhandeid kordi!

2. Rõivaste ja inimese analoogia

Andmebaas on nagu inimene rõivaste sees: Püsiv tuum, kus asuvad ettevõtte väärtuslikumad andmed ja põhitõed.

Rakendused on nagu inimese rõivad: Rõivaid vahetatakse tihti, sest need kuluvad ja mood (tehnoloogiad, raamistikud) muutub. Inimese eluea jooksul vahetub palju rõivaid, kuid inimene jääb samaks.

Koodi ja arhitektuuri detailne võrdlus

Vaatleme konkreetset näidet: Tellimuste kinnitamine, kus tellimuse olek muudetakse väärtuseks 3 (kinnitatud), kui tellimus on hetkel olekus 2 (ootel), tellimusel on rida kogusega üle 1000 ja tellija kliendiseisund on 4 (aktiivne).

Kõhn andmebaas (Rakenduse kood tsüklis) N+1 päringud, ridade ükshaaval töötlus
# Rakendusserveri kood (nt Python / ORM)
def kinnita_tellimused_kohn():
    # 1. Päring: Loetakse kõik ootel tellimused
    tellimused = db.query(Tellimus).filter_by(seisund=2).all()
    
    for t in tellimused:
        # N päringut: Iga tellimuse ridade kontroll
        read = db.query(TellimuseRida).filter_by(
            tellimus_id=t.id, kogus__gt=1000
        ).all()
        
        if len(read) > 0:
            # Veel N päringut: Kliendi staatuse kontroll
            klient = db.query(Klient).get(t.tellija_id)
            if klient.seisund == 4:
                # N UPDATE päringut: Ridade kaupa salvestamine
                t.seisund = 3
                db.session.add(t)
                db.session.commit()
Probleemid: $1 + 2N$ eraldi võrgupöördumist, tohutu latentsuse kogunemine, rakendusserver hoiab andmeid mälus, andmebaasisüsteem teeb iga rea puhul eraldi tehingu ja SQL parsingu.
Paks andmebaas (Avalik liides / SQL funktsioon) 1 funktsioonikõne, hulkade töötlus
-- Andmebaasis loodud turvaline funktsioon (avalik liides)
CREATE OR REPLACE FUNCTION f_kinnita_tellimused()
RETURNS integer
LANGUAGE sql
SECURITY DEFINER
BEGIN ATOMIC
    WITH muudetud AS (
        UPDATE Tellimus AS T 
        SET tellimuse_seisundi_liik_kood = 3 
        WHERE tellimuse_seisundi_liik_kood = 2 
          AND EXISTS (
              SELECT 1 FROM Tellimuse_rida AS Tr 
              WHERE T.tellimuse_kood = Tr.tellimuse_kood 
                AND Tr.kogus > 1000
          ) 
          AND EXISTS (
              SELECT 1 FROM Klient AS K 
              WHERE T.tellija = K.klient_kood 
                AND K.kliendi_seisundi_liik_kood = 4
          )
        RETURNING T.tellimuse_kood
    )
    SELECT count(*)::integer FROM muudetud;
END;
Eelised: Rakendus teeb vaid ühe kõne: SELECT f_kinnita_tellimused();. Kogu loogika ja optimeerimine toimub andmebaasimootoris otse ketta ja vahemälu juures.

Plussid, miinused ja arhitektuuri valik

Interaktiivne arhitektuuri valiku abiline

Vasta küsimustele oma süsteemi vajaduste kohta ja saa kohene soovitus:

Soovitus arvutatakse automaatselt valikute põhjal.
Paksu ja kõhna andmebaasi omaduste võrdlustabel
Kriteerium ▲▼ Paks andmebaas ▲▼ Kõhn andmebaas ▲▼
Töökiirus ja skaleeritavus Väga kõrge. Minimaalne võrguliiklus, hulkade kaupa optimeeritud SQL. Madalam. Palju võrguliiklust, oht N+1 tsüklipäringutele.
Andmeterviklikkuse tagamine Tsentraalne. Reeglid on andmete juures, ükski klient ei saa reeglitest mööda. Hajutatud. Reeglid rakenduses; otse baasi poole pöördudes reeglid ei kehti.
Rakenduse/kasutajaliidese vahetamine Lihtne. Liides on püsiv, rakenduskiht on nagu "rõivad", mida saab vahetada. Keeruline. Terve äriloogika tuleb uues rakenduskeeles ümber kirjutada.
Andmebaasisüsteemi (DBMS) vahetamine Raskem. Funktsioonid ja vaated on seotud konkreetse DBMS-i dialektiga. Lihtsam. ORM abstraheerib SQL-i eri baaside vahel.
Universaaltarkvara eri baaside toega Ei sobi hästi. Nõuab eraldi rutiine iga toetatud DBMS-i jaoks. Hästi sobiv. Lihtne luua universaalset karbitarkvara.
Arendusvahendid ja graafiline tugi Keskmine (DBMSi spetsiifilised IDE-d ja haldusvahendid). Väga rikkalik (lai valik keelte raamistikke, teeke ja ORM-e).

Enesekontrolli test

Kontrolli oma teadmisi paksu ja kõhna andmebaasi teemal:

Vastatud: 0 / 4