Dotaz: Docasna tabulka

[tony]

Zdravim, potrebuji udelat neco jako docasnou tabulku. Problem je takovy, mam obrovske mnozstvi jednoduchych dat v nejake tabulce, no a chci pro kazde id (ruzne se opakuje) vytvorit neco jako cache tabulku kde bude vysledek dotazu (...where id = 123 group by...), teda az pri prvnim pouziti onoho id. takze dotaz na hlavni tabulku ktery obvykle trva treba 2 sekundy, by pri dotazu na tuhle docasnou tabulku trval 00 nic (odkud brat data by bylo osetrene v samotne webove aplikaci).
No pri aktualizaci dat (ktera by probihala treba 1x denne) by se vsechny docasne tabulky smazaly.

Zkousel jsem neco jako CREATE VIEW, jenze to bylo snad jeste pomalejsi nez kdybych ten dotaz pokazde provadel znovu. Delal jsem snad nekde chybu?! Taky jsem zkousel create temporary table, jenze to mi v databazi evidentne jen-tak nezustane.

Nevite jak na to? Mam na svym serveru mysql5. Nejsem proti zmene na jiny databazovy server, ktery bude minimalne stejne rychly a bude umoznovat neco pro reseni problemu, ktery jsem popsal vyse.
 

p.s. Ted me napadlo, co takhle vytvorit klasickou tabulku, ale v memory enginu? Tzn. bylo by to ulozene v pameti, takze by ta rychlost vytvoreni, pouzivani (pouze select) a smazani mela bejt postacujici.

Odpovědi

[mozog]

nedal by sa pouzit Memory engine ?

[Tomáš K.]

CREATE VIEW můžeš zadat ALGORITHM, který říká, jak má s pohledem pracovat. Možnosti jsou dvě - MERGE nebo TEMPTABLE. Pokud nezadáš něco explicitně, mysql si vybere jeden z nich, nevím jak. MERGE si zřejmě vybralo v tvém případě - tento algoritmus si pamatuje akorát dotaz, který jsi zadal při CREATE VIEW a pokud pošlel nějaký dotaz na ten VIEW, tak ho syntakticky zmerguje s tím, co si pamatuje a zavolá. Tedy v podstatě syntaktický cukr. Druhý algoritmus - TEMPTABLE vytvoři dočasnou tabulku, kde si pamatuje data - to je to, co chceš. Jak se to chová při updatu bych musel hledat v dokumentaci, je možné, že tam jsou nějaká omezení... 

 

Zdroj: http://dev.mysql.com/doc/refman/5.0/en/view-algorithms.html  

[cronin]

Ak ma byt aktualiazcia udajov raz denne, a podla vsetkeho kontrolovana, isiel by som na to "hrubou silou", t.j. vytvaranim plnohodnotnej a vhodne oindexovanej tabulky. Ani by som sa velmi nestaral o to, ze bude umiestnena na disku: ak bude pouzivana casto, bude pravdepodobne natiahnuta v cache.

Mam na svym serveru mysql5. Nejsem proti zmene na jiny databazovy server, ...

V tom pripade odporucam zvazit PostgreSQL, pripadne jeho "enterprise" verziu EnterpriseDB.

[Filip Jirsák]

S PostgreSQL můžete pomocí triggerů nebo rules vyvolat změnu vaší kešovací tabulky, pokud dojde ke změně v hlavní tabulce. Pomocí rules pak můžete udělat takový pohled, který se nejprve podívá do kešovací tabulky, pokud tam data nenajde, udělá SELECT nad hlavní tabulkou a výsledek uloží do té kešovací tabulky. Aplikace o tom tedy vůbec nemusí vědět a bude se ptát stále toho pohledu.

[Johny99]

Zatim to tu nikde nepdalo, takze se zeptam - pouzivate indexy? Nevim kolik zaznamu je v tabulkce celkem ani kolik filtrujete (v procentech) ani jaky mate hardware - na vsem zalezi. Pokud ale jde o nejakou "obycejnou" webovou aplikaci a query neni nejak silene komplikovana, tak bude problem spis v indexaci databaze a optimalizaci dotazu. Driv nez bych resil nejake silenosti, tak bych se zameril na toto. Daji se s tim dokazat zazraky...

Johny99

[Tlama]

Ahoj! Co znamena "obrovske mnozstvi jednoduchych dat"? Pokud mas nekolik milionu zaznamu, tak to rozdel do partitions podle prave toho id. Kazde id, pak bude mit "svoji" tbl, coz ti pomuze zvysit vykon.