k47.cz    — každý den dokud se vám to nezačne líbit
foto Praha výběr povídky kultura | twitter FB


««« »»»

Data positive

15. 6. 2009 — k47

Data přátelé, data. Na ničem jiném nezáleží. Programování je nuda, ale práce s daty se královská disciplína. A já si rád hraji s daty. Už dlouho jsem mířil tímto směrem, pracoval a hrál si s databázemi (tedy databází - MySQL) a přemýšlel jsem jak něco udělat, jak to udělat, aby to fungovalo rychle, jak data získat a co z nich zjistit. Šílenství dosáhlo vrcholu, když jsem napsal několik skriptů, které stáhly celý obsah stránek Sdružení amatérských spisovatelů (20000 literárních děl, 3000 autorů) a dva dny jsem nedělal nic jiného než ta data zkoumal ze všech možných úhlů, dělal statistiky a zjišťoval změny chování uživatelů (jak hodnotí, jak komentují, co čtou, o co nemají zájem atd).

Pak jsem se rozhodl jít do analýzy slov, zjistit jakou kdo má slovní zásobu, typické charakteristiky pro dané žánry atd. atd. Prostě další pokus něco zjisti i když si nejsem moc jistý, co vlastně hledat a jestli to k něčemu bude. Šel jsem do toho, ale jak jsem posléze zjistil, tohle bádání se stalo hlavně zatěžkávací zkouškou výkonnosti databáze a schopnosti optimalizovat až na dřeň.

SASPI je server spisovatelů a básníků, takže je vám jasné, že použili hodně slov. Zatraceně hodně. Dalo by se říct, že víc než by bylo nutné. První přístup k řešení problému byl jednoduchý: načíst jedno dílo, v php skriptu ho rozdělit na jednotlivá slova a ty pak uložit do databáze.

Nápad to byl velice jednoduchý, ale zároveň velice pomalý, protože jsem databázi doslova zasypával tisícovkami dotazů. Použil jsem tedy prepared statements, které byly o něco rychlejší (sice neumí využívat query cahce, ale to v případě insertů nevadí), ale pořád to trvalo věčnost. Všechny texty dohromady mají 85 mega, což může znamenat 10 milionů slov tedy 10 milionů insertů za které vám vaše databáze poděkuje.

Pak mě napadlo změnit strategii sběru dat, aby šly použít hromadné inserty s tím, že do databáze naperu všechna slova horem dolem a pak je nějak protřídím, až budou v databázi. To bylo o něco ryhlejší, protože DBMS nezasypávám tolika malými dotazy, ale několika monstrózními.

Pořád to bylo pomalé.

Hlavní problém tkvěl ve faktu, že jsem nejdřív načetl daný text, poslal ho klientskému skriptu, který ho nějak zpracoval (rozsekal na slova), pak z něj vytvořil SQL příkazy, které posílal zpátky databázi nebo použil binární protokol prepared statements.

Nedalo se svítit, celá logika musela opustit php skript a vlézt do databáze. Napsal jsem uloženou proceduru, která pomocí kurzorů načítala data a pak je zpracovávala (pomocí dalších procedur) a ukládala. Všechno na straně databáze.

A to už je nadějné a rozumně rychlé.

Odhad trvání úlohy s uloženou procedurou: méně než 1 hodina. Pravda, nevypadá to nijak vesele, ale předchozí verze řešení trvaly hodně přes dvě hodiny.

A pointa? Optimalizace je někdy potřeba jako sůl. Je potřeba vědět jak na to. Někdy je potřeba změnit celou strategii sběru a zpracování dat, aby to fungovalo svižně. Já to všechno umím. V databázích se hrabu rád. Začal jsem sledovat záznam kurzu Statistical Aspects of Data Mining, které přednáší chlápek ze Stanfordské univerzity. A tak dále a tak dále.

vstoupit do diskuze    sdílet na facebooku, twitteru, google+

štítky: #novinky «« »» #databáze #dev #data #MySQL #datamining #optimalizace

CC by-nc-sa

příbuzné články:
Tiráda pokračuje
Technologické okýnko
MySQL: rychlý výběr náhodného záznamu 📷
Hromadný update v jednom SQL dotazu
časová anomálie
Věci počítačové, chov tučnáků, Quake 3 po deseti letech a gaučové databáze 📷

sem odkazují:
Jednoduché problémy mívají většinou složité řešení

píše k47 & hosté, ascii@k47.cz