olivlawolivlaw

Din cărți

Lecția 3 · Un motor bun la tranzacții e slab la analiză, și invers — nu e un defect, e fizică.

Michael Stonebraker, Uğur Çetintemel · “One Size Fits All”: An Idea Whose Time Has Come and Gone · 2005 · “One Size Fits All”: An Idea Whose Time Has Come and Gone, ICDE 2005 — rezumat2 minute de citit
Ultimii 25 de ani de dezvoltare comercială a SGBD-urilor pot fi rezumați într-o singură formulă: «o mărime pentru toți». Formula se referă la faptul că arhitectura tradițională de SGBD (proiectată și optimizată inițial pentru prelucrarea datelor de afaceri) a fost folosită pentru a susține multe aplicații centrate pe date, cu caracteristici și cerințe foarte diferite.Michael Stonebraker, Uğur Çetintemel · “One Size Fits All”: An Idea Whose Time Has Come and Gone · 2005 · “One Size Fits All”: An Idea Whose Time Has Come and Gone, ICDE 2005 — rezumat

OLTP atinge rânduri întregi de puține ori; OLAP atinge câteva coloane de miliarde de ori.

OLTP (procesare de tranzacții): mii de operații mici pe secundă, fiecare atinge câteva rânduri întregi — o comandă, un client — și trebuie să fie corectă chiar dacă alte mii se întâmplă simultan. De aici stocarea pe rânduri, indecșii B-tree și izolarea tranzacțiilor. OLAP (procesare analitică): câteva interogări mari, fiecare atinge două-trei coloane din sute de milioane de rânduri și le adună. De aici stocarea pe coloane, compresia și scanarea în loturi. Stonebraker a spus-o în 2005: era unui singur motor pentru toate s-a încheiat, iar de atunci au apărut motoare columnare, de streaming, de serii de timp, de documente. Sistemele HTAP încearcă ambele într-unul; prețul e complexitatea și, de obicei, o copie columnară ținută la zi în fundal. Regula practică: nu rula rapoarte pe baza de producție. O scanare analitică pe un motor de tranzacții blochează sau încetinește scrierile și folosește greșit indecșii. Replica de citire e primul ajutor; depozitul e tratamentul.

De ce nu poți optimiza pentru ambele deodată? Pentru că cerințele se bat la nivel de fizică. Un motor de tranzacții citește rânduri întregi, ca un chelner care aduce farfuria completă: comandă, client, adresă, tot. Exact ce vrei când procesezi o plată. Un raport analitic vrea doar coloana cu totalurile, din milioane de rânduri. Aducea farfurii complete ar fi ca să cumperi un întreg raft de supermarket ca să iei o pâine. Pe coloane, citești doar ce te interesează și comprimi eficient, pentru că valorile asemanătoare stau lipite. Pe rânduri, compresia asta e aproape imposibilă. Alegerea nu e despre gust, ci despre cum circulă datele prin memorie și disc. Dar dacă totuși ai nevoie de ambele în același sistem? Aici apare compromisul HTAP.

De ce conteazăCea mai frecventă cauză a unui sistem de producție lent nu e volumul de tranzacții, ci raportul de dimineață care scanează tot tabelul de comenzi.

OLTP: multescrieri miciHTAP: ambele, cuun prețOLAP: puținecitiri mari
Un motor se așază undeva pe axa asta; rar la ambele capete deodată.
Deschide pe YouTube

Vezi tot fluxul