Posted By: medved (A~z na v~eky Mikov~ce.) on 'CZdatabases'
Title:     Re: rychlost vyhledavani v DB
Date:      Tue Nov 12 22:32:50 2002


Takze pokud bych chtel vyresit tuto ulohu co nejrychleji tak,

1) vybodnu se na velke databazove servery - ty jsou delany pro prostredi kde 
je a) vice soucasnych uzivatelu kteri b) delaji v databazi ruzne operace 
(nejen vyber jednoho zaznamu)

2) podival bych se po nejake "in memory" databazi. V databazovych systemech je 
vzdy nejvetsi zdrzeni pri cteni z disku

3) pripadne bych vytvoril neco sam s tim, ze bych:

a) pouzival b-tree strom jako index nad prohledavanym sloupcem
b) pouzil neco jako clustered index v Sybase/MS SQL - listy indexu jsou 
zaroven stranky s daty
c) vhodne zvolil velikost pametove stranky - asi tak, aby byla stejne velika 
jako jeden zaznam - ale zase vzhledem k velikosti celych dat (a tim i indexu) 
a indexovaneho klice - pametova stranka indexu obsahuje hodnoty klice a odkaz 
na dalsi stranku indexu.
a d) zmyslel se nad moznou kompresi dat v pameti nebo vhodnou volbou kodovani 
dat. Existuji systemy s asymetrickymi kody ("e" ma min bitu nez "j"), ktere 
docela minimalizuji pametove naroky (napr. na text). Ale pak je to otazka 
vyvazovani pamet vs CPU... 

A ted proc doporucuji vyse uvedene:

Vsechny velke db servery prohravaji s malymi databazemi v situaci s jednim 
uzivatelem, ktery dela pouze jeden typ operaci. To protoze delajki jeste 
celou radu pro tento konkretni ucel nepotrebnych ukonu. Napriklad 
optimalizace dotazu - pokud je jen jednoho typu, je to zbytecne. Nebo rizeni 
viceuzivatelskeho pristupu - zamky, transakce opet zbytecne.

To jsou veci, ktere jsou potreba u "enterprise" reseni, kde je dobre pokud je 
uzivateluv dotaz optimalizovan i podle aktualne probihajicich dotazu ostanich 
uzivatelu. 

Bye

Medved

No matter where you go, everyone is connected.