Töökiiruse ja ressursikulu simulatsioon
Simuleerime tüüpilist äriloogika ülesannet: uute tellimuste kinnitamine ja soodustuste rakendamine. Võrdleme kolme erinevat arhitektuurilist teostust reaalajas.
Arhitektuuride reaalajas tulemuste võrdlus
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 |
Arhitektuursed mõisted ja analoogiad
- 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.
- 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.
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!
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).
# 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()
-- 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;
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:
| 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: