MySQL - Fetch Velike kolicine podataka

[dinke]

Po drugi put u vrlo kratkom vremenu imam slican problem pa sam resio da ovde pitam sa savet umesto da kopam po google-u.

Dakle, imam povecu tabelu sa .com domenima (stotinak miliona) i script koji treba da obradi sve. Dakle nesto poput ovoga:

PHP kôd:

$query = "select domain from com_zone";
$result = $db->query($query);
while($data = $result->fetch())
{
    //do processing one by one
} 


Problem je sto kad ovako nesto pokrenem load na serveru skoci jako brzo na tipa 300, pocne da swapuje i na kraju krahira. Probao sam da podatke svlacim sa nekim limitom i offsetom (npr: select domain from com_zone limit $offset, 10000) ali cim ofset skoci na malo veci broj stvar postaje spora do bola.

Koliko ja znam nakon selekta MySQL bi trebao da kreira bafer sa podacima koje PHP svlaci preko konekcije, pa kontam da je ovde mozda problem neki (network) buffer size? Ima neko ideju?

Inace pronasao sam u obe situacije workaround i problem cu resiti na drugi nacin posto ne mogu cekati ali me jako interesuje zasto server krahira i uopsteno podesavanja u ovom slucaju.

[jablan]

http://www.php.net/manual/en/functio...ered-query.php

mysql_unbuffered_query() sends the SQL query query to MySQL without automatically fetching and buffering the result rows as mysql_query() does. This saves a considerable amount of memory with SQL queries that produce large result sets, and you can start working on the result set immediately after the first row has been retrieved as you don't have to wait until the complete SQL query has been performed.

[eraser]

Dinke,
i ja ovih dana muku mucim sa slicnim problemom obrade ogromne kolicine podataka na MySQL.
Jel bi mogao da malo objasnis spomenute workarounde ili neka iskustva kakoresavas ovu situaciju.
Hvala!

[ivanhoe]

Mislim da to nije do bafera, nego da je do nacina na koji baza radi sa sekvencijalnim podacima. Kad imas offset N, baza mora da nadje prvo onih prethondih N rekorda, da bi ih preskocila. Sto je vece N to je ta operacija skuplja.

Mislim da je resenje, posto su u InnoDB podaci fizicki sortirani isto kao primarni kljuc, da probas umesto offseta da koristis WHERE ID > xx i LIMIT N (gde je naravno xx vrednost poslednjeg ID-ja koji si dohvatio u proslom krugu). Proveri da ima dovoljno memorije da ceo taj primarni index moze da stane u memoriju, i onda bi to trebalo da mnogo brze radi...

ili to, ili ovo sto kaze Jablan, jedino sto onda blokiras bazu za vreme trajanje te operacija, ako sam ja dobro skapirao kako to radi...

[webarto]

Je li ti fetch u asocijativni array ili oba?

[jablan]

Originalno napisao ivanhoe

ili to, ili ovo sto kaze Jablan, jedino sto onda blokiras bazu za vreme trajanje te operacija, ako sam ja dobro skapirao kako to radi...

Koliko razumem, blokira se konekcija, a ne baza.

[ivanhoe]

moguce, nisam nikad proveravao, a objasnjenje u helpu je konfuzno napisano...

[dinke]

Evo upravo startovao script, za razliku od onog danas koji bi digao load na 300 30-tak sekundi posle startovanja ovaj radi okay. Mana je sto ne mozes praviti nijedan drugi query dok se ceo fetch ne zavrsi, a to izgleda vazi i za ostale db konekcije iz istog scripta. No u mom slucaju easy to fix, ja cu podatke upisati u fajl i uvesti sa "load data local ..." opcijom u odgovarajucu tabelu.


@ivanhoe
Obzirom na velicinu tabele nisam kreirao nikakve primarne kljuceve vec samo sadrzi domene (90 miliona), tako da to resenje otpada. Nije frka za blokiranje konekcije.

@eraser
Workaroundovi su relativna stvar, mozda nece funkcionisati kod tebe.

Dakle, u prvom slucaju trebao sam da najjednostavnije iskopiram jednu tabelu sa jednog servera na drugi (takodje povecu). Fetch cele tabele i /insert into je brzo ubijao server, kao i u slucaju danas. Resenje je bilo da upisem iz mysql klijenta sve podatke u fajl a onda importujem sa "load data local" u tabelu. Napominjem da nisam koristio mysqldump upravo zbog velicine podataka, ranije je on uzrokovao ogromne probleme jer je trebalo postaviti pravu vrednost za parametar (ne mogu da se setim sada tacnog imena) koji regulise broj recorda po redu (default je prevelik za vece tabele tako da import efikasno ubije server zbog broja query-a u jednoj liniji).

Ukrako workaround 1:

mysql -uuser -ppass baza -e "select data from tabela" > fajl.txt
bzip2 fajl.txt
scp fajl.txt.bz2 drugi.server:/path/to/file
unpack
mysql -udrugiuser -pdrugipss baza
load data local infile 'fajl.txt' into table foo(data);

Workaround 2 se odnosi na danasnju situaciju (nisam ga doduse primenio). Dodao sam jedno enum (checked no/yes) polje tako da se mogu uzimati podaci u chunkovima od po 1000 npr, setovati na checked i tako u krug dok se ne obrade svi.
Mana tog workarounda je sam alter ... trajao je bogami cirka 2 sata (plus jos toliko kada ga budem uklanja)

[ivanhoe]

a sto ne uradite neko shardovanje tih podataka, cenim da je ovakava baza prilicno neupotrebljiva za bilo kakve brze pretrage?

[mangia]

Ili kad već imaš taj drugi server, podesi na njemu replikaciju pa ga zakivaj do mile volje...