DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   MySQL - Fetch Velike kolicine podataka (http://www.devprotalk.com/showthread.php?t=9710)

dinke 19. 02. 2011. 11:21

MySQL - Fetch Velike kolicine podataka
 
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 19. 02. 2011. 11:51

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

Citat:

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 19. 02. 2011. 12:39

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 19. 02. 2011. 13:03

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 19. 02. 2011. 13:29

Je li ti fetch u asocijativni array ili oba?

jablan 19. 02. 2011. 15:39

Citat:

Originalno napisao ivanhoe (Napišite 95629)
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 20. 02. 2011. 02:12

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

dinke 20. 02. 2011. 02:19

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 20. 02. 2011. 02:42

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

mangia 20. 02. 2011. 14:55

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


Vreme je GMT +2. Trenutno vreme je 12:33.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.