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.