DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > PHP
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.
charles wang

PHP PHP aplikacije, Smarty, PEAR

Odgovori
 
Alati teme Način prikaza
Staro 19. 02. 2011.   #1
dinke
Super Moderator
Invented the damn thing
 
Avatar dinke
 
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
591 "Hvala" u 193 poruka
dinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamen
Default 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.
__________________
Caught in a Web|Blogodak
With great power comes great responsibility!
dinke je offline   Odgovorite uz citat
Staro 19. 02. 2011.   #2
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.263 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

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.
__________________
blog
jablan je offline   Odgovorite uz citat
3 članova zahvaljuje jablan za poruku:
Staro 19. 02. 2011.   #3
eraser
profesionalac
Qualified
 
Avatar eraser
 
Datum učlanjenja: 24.08.2009
Lokacija: Berlin
Poruke: 101
Hvala: 37
256 "Hvala" u 17 poruka
eraser is on a distinguished roaderaser is on a distinguished roaderaser is on a distinguished road
Default

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!
eraser je offline   Odgovorite uz citat
Staro 19. 02. 2011.   #4
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.941 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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...
__________________
Leadership is the art of getting people to want to do what you know must be done.

Poslednja izmena od ivanhoe : 19. 02. 2011. u 13:12.
ivanhoe je offline   Odgovorite uz citat
Staro 19. 02. 2011.   #5
webarto
expert
Grand Master
 
Avatar webarto
 
Datum učlanjenja: 11.04.2010
Poruke: 998
Hvala: 141
893 "Hvala" u 153 poruka
webarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished roadwebarto is on a distinguished road
Default

Je li ti fetch u asocijativni array ili oba?
webarto je offline   Odgovorite uz citat
Staro 19. 02. 2011.   #6
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.263 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

Citat:
Originalno napisao ivanhoe Pogledajte poruku
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.
__________________
blog
jablan je offline   Odgovorite uz citat
Staro 20. 02. 2011.   #7
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.941 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

moguce, nisam nikad proveravao, a objasnjenje u helpu je konfuzno napisano...
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 20. 02. 2011.   #8
dinke
Super Moderator
Invented the damn thing
 
Avatar dinke
 
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
591 "Hvala" u 193 poruka
dinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamen
Default

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)
__________________
Caught in a Web|Blogodak
With great power comes great responsibility!

Poslednja izmena od dinke : 20. 02. 2011. u 02:31.
dinke je offline   Odgovorite uz citat
"Hvala" dinke za poruku:
Staro 20. 02. 2011.   #9
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.941 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

a sto ne uradite neko shardovanje tih podataka, cenim da je ovakava baza prilicno neupotrebljiva za bilo kakve brze pretrage?
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
"Hvala" ivanhoe za poruku:
Staro 20. 02. 2011.   #10
mangia
Pukovnik u penziji
Grand Master
 
Datum učlanjenja: 11.10.2006
Lokacija: Banjaluka, BiH
Poruke: 941
Hvala: 209
552 "Hvala" u 137 poruka
mangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoro
Pošaljite poruku preko MSN za mangia Pošaljite poruku preko Skype™ za mangia
Default

Ili kad već imaš taj drugi server, podesi na njemu replikaciju pa ga zakivaj do mile volje...
__________________
mangiaphoto | BLOGERAJBLOG | ServerAdminBlog
mangia je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum


Vreme je GMT +2. Trenutno vreme je 04:43.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2017, 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.