Posted By: medved (A~z na v~eky Mikov~ce.) on 'CZdatabases'
Title:     Re: Kapacita PostreSQL (Datove sklady)
Date:      Wed Aug 25 16:58:27 2004

> > Nebo pokud se jedna o urcity typ dat/jejich pouziti - treba datove sklady
> > lze 
> > resit velmi elegantne za desetinu nakladu s desetkrat rychlejsi odezvou ve
> > specialnich DW databazich (oproti OLTP stroji). Ale to uz neni o
> > PostgreSQL... 
> 
> Neni, ale muzem to rozvyst. Nikdy sem s nicim takovym nedelal, muzes
> postnout 
> nejaky odkazy na info o DW? Podle jmena mam pocit ze to nebude vyhovovat,
> ale znalosti se vzdycky hodi.

OK

Konkretne o tom DW. Mozna, ze Te to inspiruje i pro ten GIS.

Takze v pripade DW se jedna o dotazy nad daty, ktere jsou v drtive vetsine 
read-only. Zapisy se provadeji vetsinou z jednoho mista (ETL nastroje).

Pak tyto dotazy smeruji na jeden ci nekolik atributu entity a jsou pres 
vetsinu (ne-li vsechny) zaznamy.

V DW se ptas na velikost objednavky u vsech objednavek (serazeno podle 
produktu, casu...).

Kdezto u OLTP zpracovani se ptas na vsechny atributy jednoho zaznamu - ID 
objednavky, jeji cena, datum vydani, poskytnute slevy, jmeno obchodnika...

Proto jsou u OLTP databazi atributy entity ulozeny na disku hned vedle sebe 
(neboli sloupce tabulky jsou ulozeny v jednom radku). To je lepsi na OLTP 
operace jako je zmena dat apod. 

Pro OLAP (=DW) zpracovani je to ale nevhodne. Pro precteni milionu cen 
objednavek musime precist z disku do RAMeti milion jmen obchodnika a dalsi 
kidy, co nas nezajimaji.

Ten figl, o ktery mam na mysli je jine ulozeni dat - po sloupcich. U sebe mas 
vsechny ceny objednavek. Jinde mas poskytnute slevy (pro vsechny objednavky).

Takze pokud ma cena 2 byte a cely radek tabulky objednavek celkem 2 KB, ctes z 
disku tisickrat mene dat.

Navic si muzes s daty jeste dale pohrat. Sleva, normalne velikost 1 byte, se 
vyskytuje pouze v datech pouze v 6 ruznych hodnotach. Zaznamenas ji tedy jako 
5 ruznych bitovych sloupcu vyjadrujicich zda ma objednavka danou slevu. Takze 
dotaz na pocet objednavek se slevou 5% je cteni jednoho milionu bitu.

Nejake slozitejsi where klauzule se pak rozpadaji na binarni scitani a 
nasobeni techto bitovych sloupcu - obe velmi rychle operace.

A aby toho nebylo malo takto ulozena data jsou pomerne homogeni - lze je dobre 
kompresovat ("5% sleva" sloupec bude s velkym mnozstvim nul) a na disk potom 
ukladame (a hlavne z nej cteme) jeste mene dat = dalsi urychleni.

Ale nezkousej v takove databazi delat nejake updaty ;-)

Jiny priklad - databaze casovych rad. Pouzij techniku znamou z digitalniho 
videa: Obcas uloz absolutni hodnotu a mezi tim jenom odchylky od predchozi 
hodnoty. Vyvaz oba parametry podle pristupu a vykonu CPU a mas efektivne 
ulozene informace. Ale musis nejak chytre modifikovat algoritmy pro vypocet 
prumeru ci variace... 

>           Jerry III

Bye

Medved

No matter where you go, everyone is connected.