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 17. 03. 2006.   #1
Pedja
Predrag Supurović
Grand Master
 
Datum učlanjenja: 24.01.2006
Lokacija: Užice
Poruke: 791
Hvala: 3
194 "Hvala" u 12 poruka
Pedja is on a distinguished roadPedja is on a distinguished roadPedja is on a distinguished road
Default PHP brzi od MySQL-a u izvlacenju lookup vrednosti?!?!?

Nesto diskutovah sa prijateljem i on mi na delu pokaza da je PHP brzi do MySQL-a u izvlacenju lookup vrednosti iz sifarnika.

Radi se o sledecem. Imamo dve tabele:

master (
master_id int(10) unsigned NOT NULL auto_increment,
category_id int(10) unsigned ,
PRIMARY KEY (master_id)

i

categories (
category_id int(10) unsigned NOT NULL DEFAULT '0' ,
description varchar(30) ,
PRIMARY KEY (category_id)


Tabela master ima veliki broj slogova, a potrebno je prikazati sve slogove tako da se umesto category_id prikazuje categories.description.

Ja sam zagovarao da to treba uraditi preko SQL JOIN a on da je bolje prvo pokupiti vrednosti iz categories u array, ond auraditi select iz master i priliom prikazivanaj svakog sloga, rucno iz array vaditi description i prikazivati ga.

Covek je napravio test i pokazao da stvarno PHP to radi znacajno brze nego SQL JOIN.

U prilogu je arhiva sa testom, tako da mozete i sami da probate.

Ja sve mislim da tu ima neka kvaka, mada mi nije jasno koja. Obratio sam paznju, i cak je zauzece memorije otprilike podjednako kada se radi na oba nacina, samo sto PHP to uradi brze.

U testu imate skript koji generise testne podatke, u jednom prolazu puni bazu sa 40000 slogova. Ako zelite vise slogova samo vise puta pokrenite taj skript.

Na vecem broju slogova PHP ispadne i do 25% brzi.

Moze li neko ovo da objasni?
Priloženi fajlovi
Tip fajla: zip jointest.zip (2,0 KB, 196 pregleda)
Pedja je offline   Odgovorite uz citat
Staro 17. 03. 2006.   #2
Srpko
član
Na probnom radu
 
Avatar Srpko
 
Datum učlanjenja: 22.11.2005
Poruke: 40
Hvala: 0
0 "Hvala" u 0 poruka
Srpko is on a distinguished road
Default

Citat:
Originalno napisao Pedja
i cak je zauzece memorije otprilike podjednako kada se radi na oba nacina, samo sto PHP to uradi brze.

description u tabeli categories je varchar i otprilike zauzima 6 bajta po rekordu u ovom slucaju u totalu 6 kb, kada uradis join onda dobijas 40000 * 6 sto je 240 kb
Mislim da se ovde stvara razlika u brzini.
U ovom slucaju bi svakako izabrao php resenje ali mnogim drugim slucajevima left join je ipak elegantnije i brze resenje.
Srpko je offline   Odgovorite uz citat
Staro 17. 03. 2006.   #3
zextra
Boris
Grand Master
 
Avatar zextra
 
Datum učlanjenja: 01.12.2005
Lokacija: Novi Sad
Poruke: 775
Hvala: 5
159 "Hvala" u 2 poruka
zextra is on a distinguished roadzextra is on a distinguished road
Default

Sve i da je za nijansu sporije, opet je znacajno elegantnije, posebno kada je u pitanju vise od jednog joina.
__________________
"It’s important to have goals when you pet. Otherwise you’re just rubbing another mammal for no reason." - Scott Adams
zextra je offline   Odgovorite uz citat
Staro 17. 03. 2006.   #4
dinke
Super Moderator
Invented the damn thing
 
Avatar dinke
 
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
691 "Hvala" u 194 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

Pa, kvaka je u tome da treba kreirati index za polje category_id u tabeli master. Nesto tipa:

Kôd:
alter table master add index category_id(category_id)
U protivnom, prilikom svakog spajanja mysql mora da prodje kroz celu tabelu sto je visestruko puta sporiji proces.
__________________
Caught in a Web|Blogodak
With great power comes great responsibility!
dinke je offline   Odgovorite uz citat
Staro 18. 03. 2006.   #5
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.311 "Hvala" u 583 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

mozda bi bilo dovoljno promeniti redosled tabela u joinu, jer ako se na svaki master dodaje description, onda nije potreban dodatni index, valjda ? Ako radi suprotno, onda je problem, mora ovo sto Dinke rece.. U svakom slucaju treba videti sa Explain zasto se to desava..

Problem sa tehnikom gde se to radi sa php-om je (pored ruznoce) ako imas puno rekorda, sto ti svi stoje u memoriji servera u asoc. nizu koji zauzima mnogo vise memorije nego sto ima elemenata (jer je to u stvari hash tabela). Plus ako se nesto kopira i slicno, pa zavrsis sa 3-4 verizje istih 400000+ podataka, mozes lako da lupis u memory limit... plus ako imas vise pristupa istovremeno toj skripti onda server gubi dragocenu memoriju...
__________________
Leadership is the art of getting people to want to do what you know must be done.

Poslednja izmena od ivanhoe : 18. 03. 2006. u 00:46.
ivanhoe je offline   Odgovorite uz citat
Staro 18. 03. 2006.   #6
zextra
Boris
Grand Master
 
Avatar zextra
 
Datum učlanjenja: 01.12.2005
Lokacija: Novi Sad
Poruke: 775
Hvala: 5
159 "Hvala" u 2 poruka
zextra is on a distinguished roadzextra is on a distinguished road
Default

Dodatni indeks na tabeli master nije potreban jer mysql automatski pravi relaciju one-to-many izmedju tabela categories i master, jer je polje category_id u tabeli categories primarni kljuc. Dakle problem ne lezi u tome...

Kôd:
mysql> explain select * from categories,master where categories.category_id=master.category_id;
+----+-------------+------------+--------+---------------+---------+---------+-------------------------+-------+-------+
| id | select_type | table      | type   | possible_keys | key     | key_len | ref                     | rows  | Extra |
+----+-------------+------------+--------+---------------+---------+---------+-------------------------+-------+-------+
|  1 | SIMPLE      | master     | ALL    | NULL          | NULL    | NULL    | NULL                    | 40000 |       |
|  1 | SIMPLE      | categories | eq_ref | PRIMARY       | PRIMARY | 4       | test.master.category_id |     1 |       |
+----+-------------+------------+--------+---------------+---------+---------+-------------------------+-------+-------+
2 rows in set (0.00 sec)
Dodatni indeksi ne mogu da poprave performanse upita, jer se i tako i tako citaju svi zapisi iz tabele master.

Mrzelo me da kreiram jos koju tabelu i da vidim sta se onda desava...
__________________
"It’s important to have goals when you pet. Otherwise you’re just rubbing another mammal for no reason." - Scott Adams

Poslednja izmena od zextra : 18. 03. 2006. u 01:44.
zextra je offline   Odgovorite uz citat
Staro 18. 03. 2006.   #7
dinke
Super Moderator
Invented the damn thing
 
Avatar dinke
 
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
691 "Hvala" u 194 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

nisi u pravu jer:

Kôd:
mysql> explain SELECT m.*, c.description FROM master m
    -> LEFT JOIN categories c ON m.category_id = c.category_id;
+----+-------------+-------+--------+---------------+---------+---------+-----------------------+-------+-------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref                | rows  | Extra |
+----+-------------+-------+--------+---------------+---------+---------+-----------------------+-------+-------+
|  1 | SIMPLE      | m     | ALL    | NULL          | NULL    |    NULL | NULL                  | 40427 |       |
|  1 | SIMPLE      | c     | eq_ref | PRIMARY       | PRIMARY |       4 | measure.m.category_id |     1 |       |
+----+-------------+-------+--------+---------------+---------+---------+-----------------------+-------+-------+
2 rows in set (0.00 sec)

mysql> alter table master add index category_id(category_id);
Query OK, 40000 rows affected (1.06 sec)
Records: 40000  Duplicates: 0  Warnings: 0

mysql> explain SELECT m.*, c.description FROM master m
    ->  LEFT JOIN categories c ON m.category_id = c.category_id;
+----+-------------+-------+--------+---------------+-------------+---------+-----------------------+-------+-------------+
| id | select_type | table | type   | possible_keys | key         | key_len | ref                   | rows  | Extra       |
+----+-------------+-------+--------+---------------+-------------+---------+-----------------------+-------+-------------+
|  1 | SIMPLE      | m     | index  | NULL          | category_id |       5 | NULL                  | 40715 | Using index |
|  1 | SIMPLE      | c     | eq_ref | PRIMARY       | PRIMARY     |       4 | measure.m.category_id |     1 |             |
+----+-------------+-------+--------+---------------+-------------+---------+-----------------------+-------+-------------+
2 rows in set (0.00 sec)
Dakle, nakon dodavanja index on se koristi (type kolona u explain outputu).
__________________
Caught in a Web|Blogodak
With great power comes great responsibility!
dinke je offline   Odgovorite uz citat
Staro 18. 03. 2006.   #8
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.311 "Hvala" u 583 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

moj mysql (4.1.9-max na windowsima) prikaze drugacije:
Kôd:
mysql> alter table master add index category_id(category_id);
Query OK, 177693 rows affected (1.80 sec)
Records: 177693  Duplicates: 0  Warnings: 0

mysql> explain SELECT m.*, c.description FROM master m, categories c WHERE m.category_id = c.category_id;
+----+-------------+-------+--------+---------------+---------+---------+-----------------------+--------+----
---+
| id | select_type | table | type   | possible_keys | key     | key_len | ref                   | rows   | Ext
ra |
+----+-------------+-------+--------+---------------+---------+---------+-----------------------+--------+----
---+
|  1 | SIMPLE      | m     | ALL    | category_id   | NULL    |    NULL | NULL                  | 177693 |
   |
|  1 | SIMPLE      | c     | eq_ref | PRIMARY       | PRIMARY |       4 | measure.m.category_id |      1 |
   |
+----+-------------+-------+--------+---------------+---------+---------+-----------------------+--------+----
---+
2 rows in set (0.00 sec)

mysql> explain SELECT m.*, c.description FROM master m LEFT JOIN categories c ON m.category_id = c.category_id
;
+----+-------------+-------+--------+---------------+---------+---------+-----------------------+--------+----
---+
| id | select_type | table | type   | possible_keys | key     | key_len | ref                   | rows   | Ext
ra |
+----+-------------+-------+--------+---------------+---------+---------+-----------------------+--------+----
---+
|  1 | SIMPLE      | m     | ALL    | NULL          | NULL    |    NULL | NULL                  | 177693 |
   |
|  1 | SIMPLE      | c     | eq_ref | PRIMARY       | PRIMARY |       4 | measure.m.category_id |      1 |
   |
+----+-------------+-------+--------+---------------+---------+---------+-----------------------+--------+----
---+
2 rows in set (0.00 sec)
Odnosno gledace sva polja tabele master, i za inner i za left join, bas kao i kad nema indexa.. sto se pokaze i kad se pusti ovaj Pedjin test, jer se dobije skoro isti rezultati...bar sa myisam tabelama, kasno je pa me mrzi da probam innoDB kako se ponasa...
__________________
Leadership is the art of getting people to want to do what you know must be done.

Poslednja izmena od ivanhoe : 18. 03. 2006. u 04:09.
ivanhoe je offline   Odgovorite uz citat
Staro 18. 03. 2006.   #9
degojs
I'm a PC too.
Wrote a book
 
Avatar degojs
 
Datum učlanjenja: 05.06.2005
Lokacija: Kanada
Poruke: 1.354
Hvala: 82
130 "Hvala" u 89 poruka
degojs će postati "faca" uskorodegojs će postati "faca" uskoro
Default

I kod mene sa ili bez indexa daje rezultate kao kod ivanhoe sto i jeste za ocekivati jer kako zextra rece - ionako se gledaju svi zapisi iz master tabele.

Inace samo dodavanje indexa kako dinke rece kod mene nista nije ubrzalo upit.

Ali, ako se stavi index pa zatim uradi INNER JOIN, rezultati su bolji za oko 30%.

Interesantno, zar ne
__________________
Commercial-Free !!!

Poslednja izmena od degojs : 18. 03. 2006. u 07:30.
degojs je offline   Odgovorite uz citat
Staro 18. 03. 2006.   #10
Pedja
Predrag Supurović
Grand Master
 
Datum učlanjenja: 24.01.2006
Lokacija: Užice
Poruke: 791
Hvala: 3
194 "Hvala" u 12 poruka
Pedja is on a distinguished roadPedja is on a distinguished roadPedja is on a distinguished road
Default

Koliko znam, samim tim sto postavis primarni kljuc tabele on predstavlja i indeks, tako da nema potrebe da se postavlja poseban index po istom polju.

No probao sam da stavim dodatne indekse i description polje sam promenio u CHAR umesto vARCHAR. Nema razlike. I dalje je PHP brzi.

Stoji da je SQL JOIN elegantniji samo me svrbi to sto je sporije, cisto iz principijelnih razloga. Do juce sam smeo da se zakunem da nista ne moze biti brze osim u specijalnim slucajevima.

Cini mi se da je ovde kvaka u asocijativnom nizu PHP-a posto to izgleda radi vraski brzo, bez obzira na poredjenje sa MySQL-om. Ne znam kako to radi interno, ali mi se nikako ne uklapa da je brze nego sto to radi MySQL.

Zanimljivo je da razlika u brzini opada kako raste broj slogova u master tabeli, odnosno ostaje priblizno ista u apsolutnoj vrednosti (kod mene je to oko jedne sekunde).

Bilo bi zanimljivo videti ovaj test pusten na nekom drugom serveru.

Inace, u realnnoj upotrebi ovakav upit je po pravilu ogranicen na izdvajanje svega desetak do pedeset slogova. Test vuce celu master tabelu zbog merenja. Tada razlika u iskoriscenju resursa postaje zanemarljiva ali je covek u stvari napravio odicno resenje, jer SQL upiti se generisu dinamicki i razdvajanjem lookup-a od osnovne tabele, covek je znatno pojednostavio stvar, resio se goleme bede oko uklapanja svih joinova, omogucio znatno vecu upotrebljivost lookup-a (post sada nije ogranicen JOIN-ovima moze da dozvoli da maksimalno parametrizuje upit koji daje lookup tabelu, ukljucujuci i mogucnost da se custom napise ceo SELECT), i jos, kao slag na tortu, dobio vecu brzinu.

Poslednja izmena od Pedja : 18. 03. 2006. u 07:54.
Pedja 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

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Upis brojcanih vrednosti sa zarezom i tackom u MySQL martinluter SQL baze podataka - Sponzor: Baze-Podataka.net 3 19. 05. 2009. 22:21
Brzi prsti crews_adder Opušteno 3 24. 02. 2006. 17:33
quick lookup ivanhoe Web site, dizajn i multimedia 3 16. 01. 2006. 22:55


Vreme je GMT +2. Trenutno vreme je 01:39.


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