„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 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.