Ukladam log ze squidu do PostgreSQL a za mesic ma tabulka 200 000 zaznamu (firma s 10 aktivnimi pocitaci)... Jeste nemam napsanou aplikaci na vyhodnoceni dat (kolik uzivatel stravil denne na internetu a na cem nejvic casu apod.), ale jsem zvedavy, jak to bude rychle - nemate nekdo podobne zkusenosti, jak resit takovehle udesne tabulky? (za rok to bude 1.5 milionu zaznamu - to nemuze preci SQL zvladnout v tom rozumne(!) vyhledavat - nebo se mylim?)
Jen to chce udelat indexy az pri zpracvani, treba rvat data do pomocne tabulky bez indexu a pak je jednou denne preklopit do te odkud se doluji data a ktera mit indexy bude.
No ten komentar nebyl treba, pri jedne tabulce bych na oracle nevsadil ani petnik ze to dokazes projit rychleji nez mysql. Jo, u slozitejsich spojeni by oracle jednoznacne vyhral ale s takovymi jednoduchymi malickostmi jako je tohle je mysql bezkonkurencni.
To je jen zazite ze si clovek rika ze milion je velke cislo - pritom to neni prakticky nic.
ale viem ti dat priklad tabulky, ktora bude v mysql nepouzitelne pomala (vzdy to bude full table scan aj keby si spravil akykolvek index) a v oracle bude bleskova - pri pouziti rovnakeho SELECTu
staci vhodne zvolit IOT a mysql, postgres, mssql a hocico co nema IOT sa moze strcit ;) - z praxe som videl to zrychlenie ked oracle 8.0.5 IOT nemal a potom v 9.2.0 kde je IOU full supported
Nevím, co je IOT, mohl byste mi to prosím přiblížit? Mohl byste mi také dát příklad tabulky, kde bude Oracle vždy rychlejší nehledě na indexy? Rád bych si rozšířil obzory.
Také jsem to nevěděl. Tak jsem si otevřel Google, zadal "IOT database", klikl na 2-3 odkazy a našel jsem. To už dnes nikdo není schopen pracovat samostatně?
Polozil bych si otazku, jestli opravdu vsechny ty zaznamy potrebuju nebo jestli je alespon potrebuju v jedne databazi/tabulce. Pozadovane sumacni udaje bych jednou za mesic z dat vytahnul, ulozil do separatni databaze a podrobna data odsunul pryc.
Sumacni udaje lze vytvaret i prubezne pomoci aplikacni logiky v databazi (ulozene procedury, triggery,...).
Aplikaci na zpracovani logu SQUIDU jsme vyvijeli. Pravda dela spoustu jinych veci nez jen off-line
prehledy (ex-post), ale ze zkusenosti lze jen doporucit pouziti neceho jineho nez PostgreSQL. Vzhledem k tomu, ze se uz z principu nejedna o transakcni zpracovani, tak zkuste treba MYSQL (bez transakci) je radove rychlejsi pro ucel, na ktery to potrebujete.
Jinak pro SQL jako jazyk to neni zadny problem.
Jen na okraj - jsem velkym priznivcem PostgreSQL a
MYSQL s nim nelze srovnavat, ale pro tento ucel se
MYSQL hodi opravdu lepe.
Nezalezi ani tak na "objemu dat" ale na optimalizaci ulozeni dat a na spravnem chovani k SQL engine. Muzu vas ubezpecit ze 1.5mil zaznamu je prd do stromovky. Zalezi tez na zeleze na kterem to honite (SMP system,RAM, Disky ?). Chce to vyuzit vlastnosti DB jako cluster index, bitmap indexy apod. Ne kazda SQL DB toto umi. Clovek dosahne nejlepsiho vykonu pokud nejde proti srsti SQL enginu. Nejlepe je si neco nacist o fungovani toho ci onoho engine a pak k nemu podle toho pristupovat. Napr. Oracle versus hinty a dobre napsany SQL statement muze udelat vysledek kde rozdil je v stovkach sekund. I na tabulkach kde je ulozeno cca 60 milionu zaznamu lze pres index dosahhnout radove nekolika ms pro pristup pres index. Jinak diky autorovi clanek je lehce napsan a pro lidi kteri nevedi o cem je rec je dosti ctivy.
ČLÁNKY DO MAILU