A PHP megalkotója a MySQL-t ajánlja a PgSQL helyett

MySQL, MariaDB

Rasmus Lerdorf, a PHP szkriptnyelv megalkotója nyitóbeszédet mondott a php|works konferencián, ahol egyebek mellett arról beszélt, hogy ha nagy teljesítményre van szükség, akkor a PostgreSQL helyett MySQL-t érdemes használni. A kijelentés a PgSQL közösséget nem nagyon hatotta meg.

( WoOh | 2006. 09. 15., p – 20:39 )

MySQL is a shit.

PgSQL legalabb hasznalhato es gyors.

--
Live Free or Die
UNIX

( AttiSan | 2006. 09. 15., p – 21:14 )

Szerintem inkább azt mondja, ha a mysql képes egyáltalán megoldani akkor kibaszott gyorsan teszi. A baj akkor van amikor nem. Vagy ha olyan feature-ek kerülnek előtérbe mint neadjisten a subselect vagy egy normális tranzakciókezelő amelyekben viszont a postgresql (egyelőre) a jobb.

Ezen túl már nem nagyon lehet biztosat mondani.. egy konkrét feladat ismerete nélkül.

--------------
Sok ember hord Superman-pizsamát. Superman Chuck Norris-pizsamát hord.

? subselect mysql-ben mar 4.1 ota van. tranzakciokezeles meg mar szerintem 3-asban is volt InnoDB table handlerrel. Most nem azert hogy a MySQL az isten a pgsql meg sux, csak tenyleg nem fogtam itt a kulonbseget, szoval kerlek ezt fejtsd ki bovebben ... Ez olyan mint amikor az LWN-en kihoztak hogy postfix vs Exim temaban a postfix sokkal tobb pontot kapott, de megis az Exim a jo, mert a postfix az tul limitalt (amit elmagyarazni nem tudtak hogy ertenek, foleg miutan kiderult hogy Exim nehany dologra nem is alkalmas eleve, iroja szerint szandekosan by design ...). Tehat vannak ilyen erdekes dolgok ...

Nem tudom igy van-e, de allitolag exim devel listan mondtak, hogy pl az exim akkor sem tud smtp pipelining-et, ha szeretned (azaz, hogy osszes smtp tranzakcioban parancsot lenyomod egyben, nem varva arra, hogy a valasz megjojjon egyesevel a parancsokra). Illetve ESMTP-vel lehet igen, de SMTP-vel pl? Ez tipikusan olyan persze amire normalis ember nem dependal, de nekem a limitacio azt jelenti hogy SEMMIBEN ne limitaljon megha agyhalott gondolataim is vannak hogy mit szeretnek, es ne akarja helyettem eldonteni Exim hogy ezt nem lehet. Mondom, szinte semmit nem tudok az Eximrol, csak szamomra az volt fura, hogy osztottak az eszt, hogy a postfix szar, meg limitalt tulsagosan, de nagy gogosen bevagtak erre a temara hogy Exim ilyet direkt nem tud, ez nem limitacio kerdese.

Szerintem meg nem, ***eszu baratom :) Vagy akkor mi van a subselect-tel? Akkor viszont erthetetlen mit irsz :) A "szerintem" itt nem kategoria, mivel az teny kerdese hogy igen vagy nem (tudja, vagy nem). Azt, hogy valami pl performanciaban adott korulmenyek kozott milyen az mar nehezebb kerdes, mivel definialni kene az 'adott korulmeny'-t. Viszont amit irtal az nem vilagos.

Nem értem miről írsz. Oké elmagyarázom. Az első hozzászólásban azt írtam le, hogy a mysql gyors adatbáziskezelő de vannak olyan területek amelyekben a postgres jobb. NEM írtam azt, hogy nincs nincs mysqlben subselect vagy tranzakciókezelő. Erről a vonalról le kéne szálni és meg kéne tanulni olvasni.
A sokkeszű nem volt szép tőlem.

Miert jobb egyelore szerinted a subselect-ben a pgsql? Ezt indkold meg, hogy itt mire gondolsz (erre a mondatodra celzok: "agy ha olyan feature-ek kerülnek előtérbe mint neadjisten a subselect vagy egy normális tranzakciókezelő amelyekben viszont a postgresql (egyelőre) a jobb."). Amugy LEHET hogy igazad van, nem allitottam azt, hogy nincs, csak azt, hogy nem ertem hogyan lehet X jobb "subselectben" mint Y ... Pont azert erdekelne a valaszod, mert kivancsi vagyok a pgsql-re is, csak arrol en SOKKAL kevesebbet tudok, tehat varom, hogy masok velemenyezzek a kerdest. Tehat nem flame szandekkal, komolyan erdekel! tehat hogy szerinted a pgsql miert es miben jobb a subselect es tranzakciokezeles temaban mint a MySQL.

Csak zárójelben tennék hozzá egy konkrét esetet: Egy PostgreSQL-es munkámban egy nagyon összetett és mégis sebességre kritikus select-et kellett optimalizálni. Csak azzal, hogy az összes subselect-et join-nal helyettesítettem, a lekérdezés sebessége több százszorosára javult. Persze ezt már korábban sokszor eljátszottam, mert számomra ismert info, hogy a subselect-ek kezelése PostgreSQL-ben igen ratyi, de ez nagyon kirívó eset volt. Subselect-ek használata PostgreSQL-nél szerintem nagyívben kerülendő. Szerencsére az esetek többségében átírhatók join-ra egy kis gondolkodás után.
MySql subselect megvalósítását nem próbáltam, de tudom, hogy sokáig kifejezetten azért nem tették be a subselect implementációját, mert nagyon nehéz hozzá rendes optimizer-t írni. A MySql fő arculati eleme régebben a sebesség volt és erre nagyon vigyáztak is. Most már azért változott a helyzet, ahogy látom.

Szerkesztés: Még annyi, hogy join alatt PostgreSQ-nél a "where ..." használatot értem, mert a sima join-ok lényegesen lassabban futnak, nem tudja őket rendesen optimalizálni.

Optimalis esetben egy SQL query arra valo ugye, hogy "elmagyarazd" a gepnek mit akarsz. Azt hogy o ezt hogyan viszi veghez, az a dolga. Egy idealis vilagban barmilyen szarul is irod le mit akarsz, az eredmeny mindig a legoptimalisabb lenne, feltetelezve hogy letezne olyan algoritmus amivel mindig optimalis megoldast talalsz (amugy szerintem ez matematikailag sem lehetseges, legalabbis mintha Gödel ilyet is mondodtt volna), de azert kozeliteni lehet :) Ez pl programnyelveknel is igy van: ha fordito optimalis lenne, tok mindegy lenne arrol beszelni hogy X vagy Z programnyelv es a hozza adott fordito, hiszen optimalis lenne az eloallitott kod, azaz ugyanaz lenne, feltetelezve ha csak egy optimalis megoldas van :) Na persze nem idealis vilagban elunk. Azert kozeliteni lehet hozza persze ...

Azt hiszem Gödel kicsit más témákkal foglalkozott (logika,halmazelmélet).
http://hup.hu/comment/reply/29571/249638

Egyébként nem az "optimális eredmény" megtalálása a jó kifejezés itt, hanem az sql kifejezés optimalizálása, átalakítása olyanra, amit a gép gyorsabban tud feldolgozni.

Pontosan az a jo kifejezes amit irtam, ahogy te is irod: "hanem az sql kifejezés optimalizálása, átalakítása olyanra, amit a gép gyorsabban tud feldolgozni", tehat ebben az esetben az abbol a szempontbol valo optimalis eredmeny megtalalasa a cel, amit a gep minnel gyorsabban fel tud dolgozni. Szerntem ugyanezt irtam :) Gödel meg ugy jon ide, hogy bebizonyitotta hogy nem lehet mindent bebizonyitani feltetlenul, illetve talan azt is (bar ebben nem vagyok biztos hogy o volt), hogy nem lehet mindent automatikusan algoritmizalva megoldani, itt a mi szempontunkbol erdekes optimalis megoldas keresesre hasznalhato algoritmus megtalalast ertettem.

( scourge | 2006. 09. 15., p – 21:14 )

A pgsql-general listan elegge jo a szal amiben lereagaljak :)

( bervi | 2006. 09. 15., p – 21:22 )

take it easy. mint slashdot-on

Honestly, just avoid this discussion by using flat files.

:)

( siposa v | 2006. 09. 15., p – 21:34 )

Szerintem a DBase-nél jobbat még az életben nem talált ki senki. Ez a hülyülés ezzel az idétlen SQL szkriptnyelvvel csak a sznob nyakkendős marketingesek miatt van.

Csak meg kell nézni pl. ezeket a jávás Hibernátor programokat: azért csinálták, hogy az SQL-t *ne kelljen* SQL-ben programozni! Hát akkor, kérdem én, nem sokkal logikusabb, ha már *eleve* nem használunk SQL-t!?

( bra | 2006. 09. 15., p – 21:36 )

A MySQL az, amelyik alól mindegyik tranzakcionális engine-t kivásárolta az Oracle, a PHP meg az, amelyet izraeli barátaink fejlesztenek?

Hát a Postgres valóban szimpatikusabb. :)

olyasmi:)
amugy ott slashdoton bele kell olvasni.
egy bizonyos konkret esetrol volt szo amikor egy bizonyos konkret applikacio eseteben egy bizonyos kornyezetben ha a php-t megfeleloen hasznaltad(ez volt a tema) akkor mysql-el ebben az egyedi esetben minimalis(am nagy terheles eseten, ugyebar szamit az is) elonyoket lehetett elerni pgsqlel szemben.
csak valamelyik marha nem figyelt oda, szo szerint kiragadott 2 mondatot az egeszbol es most megy a flame az egesz vilagon.

Mindegyiket? InnoDB-t imho, de ez semmi fennakadast nem okozott eddig se es allitolag nem is fog okozni illetve nem is okozhat. Plusz MySQL megvette a Solid-ot, ami miatt allitolag meg az Oracle is szivta a fogat ... Szoval en annyira ezt legalabbis nem tartom tragikusnak ...

( mizu v | 2006. 09. 15., p – 22:19 )

Nekem spec. a pgsql a szimpibb, meg ha egyszer eljutok oda, hogy pl/pgsql-ben toljam, akkor le is iszom magam talan, de:
- mysql-t feldobni fel perc, ott a kib. egyszeru zero-feature-os myisam tablicsku, es kesz. minek tranzakciokezeles egy blogengine-hez?
- nem kell vacuum, karbantartas, meg optimalizalas

na ezert valasztjak a nepek ezt, mert fel masodperc alatt van egy sql-t tudo cucc. persze nem ertem, hogy a sok vacak php-s vergodes miert nem inkabb az SQLITE-ot tamogatja, rogton beljebb lennenk egy eroforrassal (mint rencergazdak)
(meg azt se, hogy php ala miert nem gyartottak egy wrappert, mint az osszes tobbi normalis nyelv ala, aztan csak a db-engine-t kellene alatta cserelgetni. vagy rosszul tudom, van ilyen, csak minden luza nativ-ban pocogteti a mysql-t?)

grep/sed/awk forever.

"persze nem ertem, hogy a sok vacak php-s vergodes miert nem inkabb az SQLITE-ot tamogatja, rogton beljebb lennenk egy eroforrassal (mint rencergazdak)"
Azért mert minden írás művelet adatbázis szintű lockolást eredményez, ergo olyan helyen nem használható, ahol akár minimális esélye van az írási műveletek konkurrenciájának (pl fórum).

"meg azt se, hogy php ala miert nem gyartottak egy wrappert, mint az osszes tobbi normalis nyelv ala, aztan csak a db-engine-t kellene alatta cserelgetni. vagy rosszul tudom, van ilyen, csak minden luza nativ-ban pocogteti a mysql-t?"
Minden láma direktben pöcögteti a májeskúelt. Ott van pl az ADOdb.

"persze nem ertem, hogy a sok vacak php-s vergodes miert nem inkabb az SQLITE-ot tamogatja, rogton beljebb lennenk egy eroforrassal (mint rencergazdak)"
Azért mert minden írás művelet adatbázis szintű lockolást eredményez, ergo olyan helyen nem használható, ahol akár minimális esélye van az írási műveletek konkurrenciájának (pl fórum).

Ezt kifejtened? Az, hogy lockolni kell iras soran es hogy az iras muveletek lehetnek egyidejuek, hogyan implikalja hogy a MySQL-t kell elonyben reszesiteni az Sqlite-tal szemben?

Nem kell feltétlenül előnyben részesíteni (én is szeretem az sqlite-ot), de amikor olyan alkalmazásról van szó, ahol nem alkalmas a feladatra, akkor egy _az adott feladatra legalkalmasabb_ másik adatbázis motort kell használni. Ilyen pl. egy közepesen forgalmas php fórum, ahol simán előfordulhat, hogy több php process olvas és több process próbál írni. Ilyenkor jó eséllyel fog elszállni egy-egy process azzal, hogy valakinek már exclusive lock-ja van az adatbázisra (writer starvation). Ahogy látom az sqlite3-ban már javítottak a konkurrencián, nekem az 2-es szériával van tapasztalatom, szóval könnyen lehet, hogy most már akár erre is alkalmas. Ideje lesz újra ránéznem.

Ahol belefutottam ebbe a problémába, ott egy daemon használta az sqlite adatbázist és ha abba egy másik process akart írni, akkor előtte le kellett lőni a daemon-t, majd annak befejeződtével újraindítani. Akkor még nem volt pythonhoz normális v3 binding...

haaat.

en pg-ből írtam a nnó a diplomám, mikor még 0, azaz nulla szintű magyar doksi volt hozzá. Azóta is az nálam a favorit.
lehet kell hozza vacuum. (de ott van hozzá az auto_vacuum)
miféle karbantartásról is beszélünk? (tudtommal az kell ugyan úgy mysql-hez is éppúgy mint az oracle-höz)
optimalizálás meg csak akkor ha nagy adatbázisod van.
apt-get -el is fél perc alatt fenn van a teljes pg server kliens (akar a 7.4,8.0,8.1 server is egyszerre)

wrapper perl ala van és php ala is.

Jaham. Es postgres tud raw particiot hasznalni? innodb tud olyat, hogy /dev/rawX -re teszed az egesz adatbazist, igy egyreszt kozvetlen diszk-hozzaferese van (sebesseg, ugye - fs-en at sokkal lassubb), masreszt ha borul az fs, az adatok meg mindig megmaradnak (teszteltem - postgres reiser alatt ugy borult, mint allat, raadasul a logfile-ok serulese miatt az _osszes_ psql adatbazis elveszett), es ami a legjobb: ha beolvas valamit diszkrol, akkor nem lesz meg ket helyen az adat (a kernel cache + postgres cache), mert a raw device-t nem cache-eli a kernel.

Na, ezert jobb az innodb.

(meg azt se, hogy php ala miert nem gyartottak egy wrappert, mint az osszes tobbi normalis nyelv ala, aztan csak a db-engine-t kellene alatta cserelgetni. vagy rosszul tudom, van ilyen, csak minden luza nativ-ban pocogteti a mysql-t?)

Tudtommal van/lesz vmi ilyen a PHP6-ban, valahol olvastam róla, de meg nem mondom hol, pedig próbáltam előkotorni. De a PEAR-ban is van ilyen réteg.

'meg azt se, hogy php ala miert nem gyartottak egy wrappert, mint az osszes tobbi normalis nyelv ala, aztan csak a db-engine-t kellene alatta cserelgetni. vagy rosszul tudom, van ilyen, csak minden luza nativ-ban pocogteti a mysql-t?)'
van wrapper, és elég sok 'luza' használja is, sajnos. Ha építesz egy alkalmazást, és az a célod, hogy minden adatbázis kezelő felett fusson, akkor az lassabb lesz, mintha egyre építetted volna (trivia).

Ha mindent ilyen wrapperen keresztül csinálsz, akkor használhatsz flat filet is...

(persze rendszergazdai szempontból megértem, ezeket a dolgokat, de programozó oldalról a legnagyobb bakinak tartom)

Nem triviális, hogy lassabb lesz, nézd meg pl a JDBC-t. Nem "wrapper" van, hanem interface-ek, azaz aki meghajtót készít szabványos elérhetőséget biztosít a funkcionalitásnak (ami azért nagyrészt egyforma minden SQL motor esetén...).

De ha wrapper: plusz egy-két függvény hívás nem a világ vége, nem hiszem, hogy azt vennéd észre az alkalmazásodon.
Ha probléma van, az architektúrális vagy implementációs.

Jah, JDBC-vel kapcsolatban igazad van, nincs benne semmi kod, csak egy interfeszt definial.

Viszont PHP alatt a letezo wrapper (PEAR) nem az igazi. Jelentosen lassabb, mint a nativ eleres. A PHP alapbol nem cache-el, minden egyes futtatas alatt minden include-olt filet beolvas, parse-ol, es futtat. Ha egy wrapper reteget hasznalsz, akkor ezeknek a fileoknak a szama jelentosen emelkedik. Arrol nem is beszlve, hogy a PEAR DB kodja elegge osszetett. Szal jelentosen rosszabb a teljesitmenye, mint a direkt elerese.

Hiaba na, a JAVA elonye itt mutatkozik meg igazan. Nehez a web-es teljesitmenyet uberelni. Van benne kraft :)
(Most majd biztos le leszek ugatva, hogy szar a JAVA, de ez sajna web-es dolgokra nem igaz :)

A PHP alapbol nem cache-el, minden egyes futtatas alatt minden include-olt filet beolvas, parse-ol, es futtat.

De csak alapból :). Már a php4 engine-t is kifejezetten úgy tervezték, hogy lehessen cache-elő fordítóval is bővíteni. Vannak is implementációk: zend, mmcache, eaccelerator.

Tudom. De azert ez meg nem a vilagvege...
Sajna a PHP nem igazan eri el mondjuk a JAVA web-es teljesitmenyet (termeszetesen jol megirt kodokra gondolok mind2 esetben) Es sajna a clusterezest a PHP nem tamogatja valami tul jol... Innentol kezdve meg bukta a nagy forgalmu site-ok szamara.

PS: A PHP nem fordit. Parse-ol. Nagy kulonbseg...

"Sajna a PHP nem igazan eri el mondjuk a JAVA web-es teljesitmenyet"
Azért szerintem ezt kérdezd meg előbb egy rendszergazdától, aki ilyeneket üzemeltet. Lehet, hogy más véleményen lesz...

"Es sajna a clusterezest a PHP nem tamogatja valami tul jol..."
Nem is biztos, hogy szükség van rá. Normális terheléselosztást megvalósító kód néhány sor, de sok esetben jobb, ha ez inkább rá van bízva a rendszergazdára.

Mondjuk lehet, hogy másfajta rendszergazdákat ismerünk...

Miert is kellene megkerdeznem egy rendszergazdat ? Felig-meddig az vagyok en is. Bar kicsit mas a szakteruletem :)
Architect vagyok. Az a dolgom, hogy olyan rendszereket tervezzek, amik birjak a terheles. Fejlesztettem mar nagy PHP-s es nagy JAVA-s rendszert is. PHP-vel indultam. :) JAVA-ra akkor tertem at, amikor mar lattam a PHP limitacioit. Sok ev tapasztalata mondatja velem azt, amit mondok...

BTW nagyjabol semmit nem tud csinalni egy rendszergazda, ha egy site sz@rul van megirva, es nem birja a terhelest. Az ilyen dolgok megoldasa mar a projektek legelejen szokott eldolni, fejben... :) (Lattam en mar olyat, hogy egyszeruen nem lehetett eleg vasat tenni egy rendszer ala. Es ez is csak akkor megoldas - marmint a vas halmozasa - ha tudod clusterezni a rendszered. Ha nem, akkor elobb-utobb bele fogsz utkozni abba a problemaba, hogy 1db HW-nek veges a teljesitokapacitasa) Vajon pl az iwiw miert JAVA technologiara epitkezik ?

Egyebkent mit ertesz mondjuk a PHP kapcsan a "Normalis terheleselosztast megvalosito kod" alatt ?
A problema a PHP-vel, hogy ugyan apache szinten tudsz cluster megoldasokat csinalni, de a PHP errol semmit sem tud. Innentol kezdve, ha a webalkalmazasnak szuksege van valamifele globalis allapotterre (erre pedig altalaban szukseg van) akkor az egyetlen megoldasod a db. Ez pedig bazinagy terhet rak a db szerveredre. Ennek hatekonyabb, ha ugyanezt memoriaban tarthatod (ezt pl tudja a java, php alatt csak mindenfele shared memory trukkozessel lehet ezt megoldani, de az is csak 1 szerveren belul mukodik). A masik nagy problema a PHP-vel az a session atvetel hianya. Ha egy usernek van egy aktiv session-je x cluster node-on, es az a node meghal, akkor egy masik node nem tudja atvenni automatikusan az allapotot. Vagyis az user ilyen esetben lat egy hibauzenetet, frissit, es lephet be ujra. Egyes advanced JAVA alkalmazas szervereknel (pl weblogic) megoldhato, hogy ebbol az user semmit ne vegyen eszre.

Jah, lehet hogy masfajta rendszergazdakat ismerunk... :)

"Miert is kellene megkerdeznem egy rendszergazdat ?"
Volt már olyan projectem, ahol az üzemeltetés vétózta meg a Javát, mert nagyon rossz tapasztalataik vannak a Javás megoldásokkal (kevés sikeres bevezetéssel zárult project). És ez egy nagyon nagy cég volt.
Másrészt elég hervasztó helyzet egy rendszergazdának, mikor a kismillió web-es alkalmazás mindegyikének külön verziójú JVM-re és más-más alkalmazásszerverre van szüksége, amik sokszor önmagukban hajlamosak egy egész gépet megenni.

"Sok ev tapasztalata mondatja velem azt, amit mondok..."
Velem is :)

"Egyebkent mit ertesz mondjuk a PHP kapcsan a "Normalis terheleselosztast megvalosito kod" alatt ?"
Nem egy nagy "Was ist das" pl. session generáláskor különböző szerverekre szétdobálni a klienseket. És ezt egy meglévő alkalmazáson is konnyű megváltoztatni.
Ha meg a rendszergazda egyáltalán nem akar belenyúlni, pl. PLB (pure load balancer) is jó néhányszor 10 ezer konkurrens socket-ig (fontos: ez itt nem konkurrens user). Ez néhányszor 10 Apache+PHP alkalmazásszerver gépet jelent.

"ha a webalkalmazasnak szuksege van valamifele globalis allapotterre (erre pedig altalaban szukseg van) akkor az egyetlen megoldasod a db"
Erre és általában adatbázis-tehermentesítésre MemCacheD-t szokás használni, pl. Slashodot alatt az megy. Kevés olyan oldal van, ami elbír egy Slashdot hírt.

"A masik nagy problema a PHP-vel az a session atvetel hianya. Ha egy usernek van egy aktiv session-je x cluster node-on, es az a node meghal, akkor egy masik node nem tudja atvenni automatikusan az allapotot."
Session kezelés legkevésbé hatékony módja, ahogy alapból a PHP kezeli. Simán file-okban tárolja a session-öket. Azért van alapból így, mert így a kezdők is gyorsan tudnak session-t is kezelő alkalmazásokat írni.
Komoly környezetben a session kezelőt adatbázisosra szokás cserélni (session.save_handler a configban).
Ha a session-öket beteszed egy MyIsam táblás MySql adatbázisba, lényegesen gyorsabb lesz (érdemes lemérni) és bármelyik gépről elérhető. Aztán MySQL-t könnyen cluster-ezheted, de nem valószínű, hogy szükség lesz rá :)

Hozzáteszem: nem vagyok PHP-rajongó, csak nem szeretem, ha valaki a Javá-val szemben lehúzza, pusztán olyan érvekkel, amik nem teljesen valósak.

"Volt már olyan projectem, ahol az üzemeltetés vétózta meg a Javát, mert nagyon rossz tapasztalataik vannak a Javás megoldásokkal"

Lattam mar ilyet en is, bar szerencsere nem olyan projektben amiben en is reszt vettem volna. A problema gyokere altalaban a JAVA kod fejlesztok hozzanemerteseben keresendo... Szvsz... Bar lattam mar olyat is, hogy a projekt azert hiusult meg, mert bevallaltak hogy az IBM-nek a legujabb legfrissebb legropogosabb WebSphere-es kornyezetevel fognak fejleszteni, amit a vilagon akkor meg senki nem hasznalt eles projektben (kb beta allapotu volt a cucc) aholis egy sima deploy muvelet eltartott kb 3/4 oraig. Igy pl megintcsak nehez fejleszteni... 1 ev huzavona es anyazas utan feladtak a projektet, azota sem keszult el...

"mikor a kismillió web-es alkalmazás mindegyikének külön verziójú JVM-re és más-más alkalmazásszerverre van szüksége"

Nah, ilyet meg nem sikerult latnom. Jobb helyeken ugy megy a fejlesztes, hogy altalaban van valamifele preferalt alkalmazasszerver kornyezet, amihez a fejlesztonek alkalmazkodni kell. Verziovaltas eseten pedig komoly migracios projektek indulnak. T-Mobile-nal pl 2db DL380-os vas (ez sima 2 xeon CPU-s beleposzintu szerver) futtat egy WebLogic clustert, amiben ~10-12 alkalmazas futogat egymas mellett. Eppen most van folyamatban egy migracios projekt a 8.1-es WebLogic-rol 9.2-re.
De lattam mar olyan rendszert is, ahol egy Sun Fire szerver (~8 CPU, sok-sok ram etc) futtatot kb 8 WebLogic node-ot, ez volt meg megclusterezve, es egyetlen alkalmazast szolgalt ki, viszont az baromi gyorsan mukodott. (Ez konkretan nemet T-Mobile-nal volt, egy sebesseg-kritikus alkalmazast fejlesztettunk nekik) A projekt azota is sikertortenet :)

Abban igazad van, hogy kerulendo dolog kulonbozo verzioju JVM-eket keverni egy szerveren belul, de konkretan en ilyen megoldast meg nem lattam. Nem is szeretnek hogy oszinte legyek.

"Session kezelés legkevésbé hatékony módja, ahogy alapból a PHP kezeli"

Tudom :) En sem hasznaltam mar egy ido utan.

"Aztán MySQL-t könnyen cluster-ezheted, de nem valószínű, hogy szükség lesz rá :)"

A Murphy nevu okos ember azt mondta egyszer, hogy ami elromolhat, az el is romlik. Na, ezert preferalom en a kello redundanciat, es a clusterezest. Es egyebkent tenyleg. Elromlanak a szerverek. :) De gondolom ez neked sem ujdonsag :)

"Hozzáteszem: nem vagyok PHP-rajongó, csak nem szeretem, ha valaki a Javá-val szemben lehúzza, pusztán olyan érvekkel, amik nem teljesen valósak."

En sokaig az voltam. Most is szeretem a PHP-t, de mar inkabb JAVA parti vagyok (Meg a regi szep idokben gyuloltem a JAVA-t, de aztan be kellett latnom, hogy nagyon jol kitalalt rendszer az...)

Az en erveim a PHP vs. Java kerdeskorben:
- PHP nem tamogatja a clusteringet. Ez teny. Lehet trukkozni 3rd party dolgokkal, de akkor sincs ra felkeszitve. J2EE containerek igen.
- Nincs globalis memoriaban tarol allapotter PHP-ban. Meg ha 1 szerveren belul meg is oldhato shared memory-val, ez nem igaz a cluster egeszere nezve. Nincs lehetoseg a memoriaban cache-elt adatok replikalasara a node-ok kozott. Minden globalis allapotot a DB-ben kell tarolni. Persze johetnek megint a 3rd party cuccok, mint a MemCacheD, de ez azert nem nyujtja ugyanazt a teljesitmeny szintet mint a tisztan memoriaban tartott objektumok. (Mert a MemCacheD-nek is azonositani kell a megfelelo query-ket, beszelgetni kell idonkent a db-vel etc) Nem allitom, hogy sokkal lassabb megoldas, de akkor is lassabb valamennyivel.
- PHP csak a DB tranzakciokat ismeri, azokat sem automatikusan kezeli, illetve ezeket nem lehet osszekotni alkalmazas allapotokkal. Vagyis egy valtozom erteke nem fog rollback-elodni egy sikertelen tranzakcio vegen. EJB allapotok viszont rollback-elodnek.

Van meg nehany ilyen finomsag, nem is ez a lenyeg, de ezek szerintem ERVEK, es valosak. Mindket rendszer mogott szep nagy community csucsul, vagyis tobb mint valoszinu, hogy mindketto meguti a hasznalhatosag szintjet. Viszont szerintem nem veletlen hogy a nagy cegek inkabb a java-t preferaljak komoly alkalmazasok eseten a PHP-val szemben. (arrol nem is beszelve, hogy univerzalisabb a JAVA, persze elismerem, hogy a szerver oldali illetve webes resze a leghasznalhatobb) Peldaul en egy komoly tranzakciokat igenylo, penzt kezelo rendszer eseteben tobb mint valoszinu, hogy nem egy PHP+MySQL parosra tennem fel a jo hirnevemet. (online szerencsejatekok, billing rendszerek etc)

PHP tapasztalatrol annyit, hogy annak idejen tobbekkozott en kovettem el a www.thrillion.hu jatekot. Na, ott aztan sok limitje kijott a PHP-nak meg a MySQL-nek is. (akkoriban meg 4.x-es PHP, es 3.x-es mysql volt a meno) Tudom, hogy azota fejlodtek ezek a rendszerek, de en is... :)

Ez ugye attol fugg, hogy kit kerdezel meg.
Pistike nem foglalkozik java-val suli utan, mert nem ert hozza, viszont PHP-ben csinal neked portal motort ocsson.
Multi meg nem foglalkozik kis projektel, mert ahhoz hogy legyen nyeresege egy projekten ki kell fizetnie a rezsiet, vagyis van egy minimal osszeg, ami alatt meg sem mozdul.

Ennek ellenere el tudok kepzelni olyan szituaciot, ahol nem az alkalmazott technika donti el az arat. Viszont ahhoz mar egy komoly projektrol kell beszelgetnunk. Nyilvan nem erdemes duplajat kolteni egy portal enginre csak azert hogy JAVA-ban legyen megirva. Viszont nyilvan nem veszelyeztetnem a cegem poziciojat, ha mondjuk valami banki rendszert fejlesztenek, es neki sem allnek mondjuk PHP+MySQL komboval... Azert kicsit mas vilag a ketto.
De szerintem ezt te is tudod, es a kerdes csak koltoi volt... :)

De ha mar itt tartunk, csak hallomasbol tudom, de Gyorben a Szintezis nem eppen az occsosagrol hires... :)

"De szerintem ezt te is tudod, es a kerdes csak koltoi volt... :)"

Nem, engem komolyan érdekelt. Mert volt egy olyan érzésem, hogy a Java programoztatást nem mindenki engedheti meg magának.

"De ha mar itt tartunk, csak hallomasbol tudom, de Gyorben a Szintezis nem eppen az occsosagrol hires... :)"

Nem tudom, mert se nem vagyok Java programozó a cégnél, se programozó, se nem felelek az árképzésért :) Azt tudom, hogy én óránként kb. 16 000 + ÁFA-ért dolgozom. Hétvégén, ünnepen a duplájáért. Döntse el mindenki, hogy ez drága-e. Imho - ismerve a fővárosi óradíjakat - nem az :)

--
trey @ gépház

Ok, akkor megprobalom komolyan megvalaszolni...

Egyreszt igazad van. Valoban lehet, hogy valaki nem engedheti meg maganak a JAVA programozast. Egy JAVA (vagy meg inkabb J2EE) fejleszto/architect teljesen mashogy gondolkodik, mint egy PHP fejleszto. Ez teny. JAVA-t nem arra talaltak ki, hogy 3 perc alatt osszedobjanak vele egy minimal site-ot. Ebben a kategoriaban a PHP elonye merhetetlen. Ha csak valami egyszeru dolog kell, amit nem fognak sokan hasznalni, akkor PHP. Vagy valami hasonlo cel-script nyelv.

Viszont ha mar egy kozepes bonyolultsagu projektrol beszelunk (mondjuk mint amilyen pl egy portal motor - drupal (ne bantsatok, vannak azert ennel komolyabb rendszerek. tudom, hogy a drupal nem egy egyszeru cuccos, pontosan ezert sorolom a kozepes szintre) - akkor mar kicsit mas a helyzet. Itt mar szerintem kiegyenlitett a ket megoldas ara. A hosszu tavu elonyok pedig egyertelmuen a JAVA oldalara billentik a merleget (szvsz kissebb TCO-t lehet elerni JAVA-val) A rendszer karbantartasa egyszerubb, szabvanyos. Nincs szukseged pontosan arra az egy darab teki csavora, aki osszereszelte a rendszered, hogy tovabbra is mukodon. J2EE vilagban nagyon sok minden szabvanyositva van, konnyebb egy alkalmazast atvenni (mind fejlesztesileg, mind karbantartasilag) Valaki emlegette itt az iwiw-et hogy az is azert szar, mert JAVA-s. Szereny meglatasom szerint, ha nem java-s lenne, akkor mar reg megdoglott volna a terheles alatt. Mikor megvette az axelero bepakoltak ala meg egy marek szervert, a kodon nem nagyon kellett valtoztatni es ment mint a "kisangyal". (tudom, hogy azert annyira jol nem, de ment) Tehat egy ilyen bonyolultsagu rendszernel a TCO szerintem osszevetheto, vagy a JAVA oldalara billen.

Aztan vannak a nagyon boszme rendszerek. Szamlazas, CRM, szerencsejatek, bank etc. A kozos ezekben az, hogy penzt vagy ugyfeleket kezelnek. Itt nem fordulhat elo olyan, hogy eltunik 3 forint nyom nelkul, vagy hogy egy usert ne talaljanak meg a db-ben. Ebben a vilagban a PHP (ahogy majdnem az osszes OpenSource cuccos) labdaba sem rughat. Itt mar megint nem konkurencia a ketto egymasnak. Nem fogod megmagyarazni egyetlen bankigazgatonak sem, hogy azert tunt el 2misi a bankbol, mert segfault-olt a PHP process... Illetve megprobalhatod, de akkor ebben a szakmaban sok jovod nincs :)

Tehat osszegezve a JAVA programozast kis projekteknel valoban van, aki nem engedheti meg maganak. Viszont egy kritikus bonyolultsagot elerve mar kifizetodo lesz a hasznalata. Egy bizonyos szint felett pedig mar kotelezo (vagy valami hasonlo very-advanced technologia hasznalata, pl CORBA alkalmazas szerverek etc. Mondjuk ezek altalaban sokkal nehezebben karbantarthatoak, mint a JAVA) Nekem ez a tapasztalatom.

Es most itt nem beszeltem semmifele hozzaertesrol, meg jo/rossz kodokrol, csak az elmeletrol. Tehat ezen osszehasonlitas szempontjabol irrelevans, hogy egy jo PHP-kod mennyivel kepes leverni egy rossz JAVA kodot.

Szia

Csak wiwrol par szot, nem kovettem nyomon a tortenesekt csak ami eljutott hozzam...
Szoval mielott az axelero megvette volna elotte is o pakolta ala a vasakat szep sorba, es miutan megvette kijelentette, hogy azzal nem megy semmire ha meg 20 szervert alatol mert nem lesz jobb, es ez nagyban koszonheto a nem megfelelo kodnak, tehat az sem mindig megoldas, hogy tolunk ala meg 20 szervert es jo lesz. Ezzel nem azt akarom mondani, hogy bezzeg ha php-ben lenne akkor hasitana, csak arra reagaltam, hogy java sem csodaszer. Mindketonek meg van a maga helye.

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Úgy tudom az iwiw php-ban indult...
Majd áttértek java-ra a terhelés miatt.
Az más kérdés, hogy java-ban nem jól írták meg a kódot :-)

Nekem volt néhány vegyes projectem. És úgy láttam a java NAGYSÁGRENDEKKEL jobb teljesítményt nyújt mindkét esetben jól megírt kódnál :-)

( mrev | 2006. 09. 16., szo – 01:15 )

A pgsql az egy adatbáziskezelő szoftver, 10+ éve fejlesztgetik, BSD licensze van, tiszta ügy. A saját útjukat járják.

A mysql az egy csomó adatbáziskezelő összezagyválva. Valaha fejlesztették a myisam motort, az piszok gyors volt, viszont nem volt benne tranzakciókezelés. Ha lett volna benne, akkor rögtön nem lett volna olyan piszok gyors. Később mindenféle motorokat vásároltak, és nyomták a marketinget, hogy milyen jó, hogy a mysqlnek olyan sok motorja van. A teszteredmények mellé általában nem írják oda, hogy melyik motort mérték. A mysqlt GPL-es projektek GPL licensszel használhatják, üzleti alkalmazásokra viszont nem ingyenes. Bocs, hogy mindig ezzel jövök.

Igen, az 5-ös tud. Lassan mindent. Bár érdekes: full-text-search van benne, de csak myisam táblára. Ami ugye nem tud tranzakciót, foreign key-t. Innodb tud tranzakciókat (meg foreign key-t, stb), de nincs FT... Mindenesetre érdekes.

Kérdés: melyik a jobb, egy alig tesztelt technológia, vagy ami már évek óta kiforrott. :D

Termeszetesen tud, minden ilyesmit. Sot ennel tobbet is ... A dolog erdekessege az, hogy sok ember, aki regen osszefutott MySQL-el, es most szidja, az meg lehet a 3-as verziot latta utoljara ... az meg azert tenyleg eleg keveset tud az 5-oshoz kepest pl. Mondjuk pgsql-t messze nem ismerem ennyire, eppen ezert nem is fikaztam sehol, en csupan arra akartam ramutatni, hogy a MySQL-t sem az alapjan kell megitelni, hogy milyen volt X ev mulva (bar a "tudjon inkabb keveset de gyorsan" anno volt MySQL filozofia nekem regebben bejott, igaz akkor nekem nem is volt meg szuksegem tobbre ...). Viszont a MySQl forditasa tenyleg tud meglepeteseket okozni, kuzdettem vele parszor Solaris-on ...

( gyu v | 2006. 09. 16., szo – 03:38 )

hmm...
Az ilyen flamewart keltő emberrel ilyenkor tipikusan azt kellett vola tenni, hogy odamenni, és esetleg megkérdezni tőle: ha vki. teljesítményt akar, akkor az úgyis perlben programozik, php felejtős, kit érdekel a véleménye :-D

ad1: perl, és nem pearl...
ad2: összemérhető, csak a php csúnyán alul marad...

és hogy rossz huposként érveket is hozzak:
* php-ben minden egyes kontextváltás lassít, de keményen. (html vs. phpkód közti váltásra gondolok.) ha jól tudom, ahogy pl. include()-olsz, vagy bármi, akkor ezek mind mind, még ha egyszeri, de akkor is kontextváltással kezdődnek...
* web-es alkalmazásoknál mindenki ugye a mod_php sebességét méri, mert... de perl-ből kapásból a cgi verziókkal hasonlítják, és nem pl. fastcgi-vel, vagy mod_perl-el, esetleg mod_perl2-vel... miért? mert csúnyán alulmaradna! miért? mert a mod_perl-nél, meg a többi megoldásnál, az alkalmazásod egyszer töltődik be a memóriába, és utána fut! a php-nél, ok. hogy becachelődik a memóriába a cucc, node nem kell azt mindig újra-paresolni?
* tud php olyat, hogy a forrásból csinálsz bytekódot (ok, vmi. fizetős zend meg egyéb enginekkel talán), és a bytekódot kimented, és az induláskor eleve csak a preparsed bytekódot (parse-tree-t) töltöd be, és izomból futtatod az alkalmazásodat?

Szóóóóval, nekem nagyon-de nagyon határozottan úgy tünik, hogy a php, hogyha egy komplett webes alkalmazásról van szó, akkor inkább vicc, meg kiddie-játékszer, amit könnyen-gyorsan megtanulnak az ifjú titánok, de komoly helyeken nem igazán használható...
De nyitott vagyok érvekre, és meghallgatom, hogy miért is oly fasza a php!

Spec. nekem pl. ezen link alapján: http://use.perl.org/faq.shtml#TheTech1
úgy tünik, hogy pl. a slashdot kódja is perl-ben van írva... Véletlen lenne?

Bár, success-story-k közt találtam ilyet is: http://www.oreillynet.com/pub/a/oreilly/perl/news/ixl_0800.html
UniCredo olasz bank & Perl... Bár tény, hogy ők nem Pg-t, hanem Oracle-t tettek alá, de khmm... szal... php-t láttál már banki alkalmazás alatt?

és hogy rossz huposként érveket is hozzak

lol

fizetős zend meg egyéb enginekkel talán

eaccelerator, ami opensource, az kb. ezt csinálja (ha nem, lehet kövezni, megfújtam a sípot).
--
Mortal Kombat's gimmikk was to replake all instankes of the letter 'C' with the letter 'K' (bekause of that feature, it was one of the first applikations to bekome part of KDE).

eaccelerator -> ez még mindig csak egy legkisebb problémára nyújt megoldást, miszerint nem kell újraparesolni. Bár, tény, hogyha a mod_php-vel össze is tud dolgozni, akkor már valamire használható is lehet... De még mindig nem látom azt a robosztusságot, mint amit a mod_perl tudna adni és sokkal többet dob a dolgon mint a kompilációs idő kihagyása.

"és hogy rossz huposként érveket is hozzak:"

Maganvelemeny volt. Mellette volt az szvsz. Nekem mint architect-nek ha egy uj rendszert kell megtervezni a PHP es a Perl egykutya. Mindketto scriptnyelv. Egy komolyabb alkalmazas fejlesztesere (legyen akar web-es, akar valamilyen back-end kiszolgalo) nem feltetlenul ez a legalkalmasabb technologia. Semmi robosztussag nincs egyikben sem.

Csak hogy ne legyen felreertes, semmi bajom nincs a PHP-val es a Perl-el, szimplan csak arrol van szo, hogy egy technologiat arra hasznaljunk amire valo. Ti itt mindenfele sebesseg osszehasonlitasrol beszeltek olyan site-ok eseten ahol a dinamikus kod merete minimalis. (pl a slashdot mogott sincs semmi extra bonyolultsagu uzleti logika) Elismerem, hogy ilyen teruleteken teljesen alkalmas lehet egy PHP vagy Perl implementacio. Viszont en nem ebben a vliagban mozgok, azert gondolkozok maskepp. Nalam egy komoly alkalmazas ott kezdodik, hogy uzletileg kritikus adatokat kell kezelni (penz, szamla infok etc) Itt sokszor a webes rendszer csak egy elotet egy komolyabb alkalmazas szerverhez. PHP/Perl-ben pedig nem egyszeru dolog alkalmazas szervert fejleszteni, mert nem nagyon vannak szabvanyos interfesz csatornai (mint amilyen JAVA eseten pl az RMI) Persze lehet WebService-el trukkozni, de az nem minden esetben az igaz, a WS-nek is vannak komoly limitacioi, amiket csak mostaban probalnak kikuszobolni (elsosorban a tranzakciokra, es a security-re gondolok)

Az erveid rendben vannak, de ha megnezed a tobbi hozzaszolasomat ebben a thread-ben, akkor lathatod, hogy elsosorban PHP vs. Java ugyben szologattam hozza. A Perl-t csak valaki felhozta. Ja, es a JAVA tudja mindazt, amit a perl mellett ervkent felhozol, es meg sokkal tobbet is. Nem azt akarom bizonygatni, hogy milyen fasza a PHP, hanem azt, hogy milyen fasza a Java :)

A PHP komoly helyeken valo felhasznalasarol pedig szerintem talalhatnal egy csomo sikersztorit. Hasznaljak azt jo sok helyen. Vagy nezd meg ezt: www.thrillion.hu Ez is PHP, es egy meglehetosen komoly webes alkalmazas, es eleg sokan hasznaljak. Es mukodik mar evek ota...

Egyebkent a legnagyobb bajom mind a PHP-vel mind a Perl-el az a kod stilusa. A nyelv tul szabad, sok mindent megenged szintaktikailag, aminek kovetkezteben egy hosszutavu kod-karbantartas remalom tud lenni. (Foleg ha az eredeti verziot nem te fejlesztetted) Nem beszelve a dinamikus tipizalas hatranyarol, vagyis, hogy nem latod a legtrivialisabb hibakat futasi idoben. (Van meg sok minden, ha erdekel leirom, hogy miert tartom a JAVA-t illetve a kore epulo technikakat jobbnak tetszoleges scriptnyelvvel szemben (PHP/Perl/Python)

Az olasz bank sikertortenetbol:
"The data migration for that system was primarily written in Perl"

Data migration. Vagyis nem a tranzakciokezelo rendszeruket implementaltak Perl-ben, hanem a migraciot a regi es az uj rendszer kozott. Igy mar kicsit mas a leanyzo fekvese szvsz... Tenyleg tokjo migracios kodokat lehet irni Perl-ben. Nincsenek osszetett tranzakciok, lehet szepen, biztosan adatokat mozgatni jobbrol balra, van ido a futtatasara.

> Egyebkent a legnagyobb bajom mind a PHP-vel mind a Perl-el az a kod stilusa.
Nekem tobbek kozott ez a bajom a perl-el, nagyon nehez olvasni, nyomonkovetni mikor mit akar a szerzo.
PHP egy fokkal jobb, de itt is lehetoseg van ganyolasra.
Python az egyik legjobb megoldast valasztotta arra, hogy olvashato maradjon a kod.

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

( hokuszpk | 2006. 09. 16., szo – 09:55 )

Hát nemtom. lehet begyepesedett agyú vagyok,de én még akkor kezdtem a postgresben hinni, -- úgy a 6.5.x környékén -- amikor a mysql még nemtudott subselectet, nemvolt benne tranzakciókezelés, és egyszerre csak egy insert mehetett. Vazze a btrieve többet nyújtott akkoriban. Lehet azóta fejlődött, csak épp anno ugyanúgy elvágta magát, mint az ablakos cucc; ha eccer van egy működö, akkor kényszerítő körülmény híján a hócipőm se fog az anno nemműködővel foglalkozni. Majd ha a php-ban megszűnik a pgsql support akkor talán előveszem a my-t.

A Java nem megoldás mindenre. Elképzeltem, ahogy az egyszeri ember saját blogjának üzemeltetéséhez mondjuk IBM WebSphere alkalmazás-szervert telepít. Aztán eszembe jutott, hogy milyen sok helyen kínálnak jelenleg ingyen java-s tárhelyet. És felnevettem.

--
trey @ gépház

( yoursoft | 2006. 09. 17., v – 14:52 )

Az 5.0.2x körül nézegettem utoljára a mysql-t, én nem nevezném túl nagy tudású tárolt eljárásnak amit tud. Azon kívűl, hogy a 2x2-őt belerakod, mást nem is tudsz nagyon megcsinálni benne :-)
A postgresql ebben tényleg jobb.
Valamint volt egy projectem ott sql union-ok voltak, full-text search match(), myisam táblák, indexek teljesen cachelve, de miután belőttem a postgresql-t az 2x kevesebbet evett loadból mint a mysql. Bár a lekérdezések kb. ugyanannyi idő alatt futottak le.
Ráadásul tényleg konfortosabb volt a postgresql. A szabványok szerint működött. Míg a mysql-nél állandóan a helpet bújtam, hogy hogyan fogalmazzak neki meg egy lekérdezést, hogy meg is értse.

Ra se rants, a PHP mindent megold neked, szop nyal gombot varr, mindezt nativ:

"For the items that MySQL doesn't handle as well as PostgreSQL, Lerdorf noted that some features can be emulated in PHP itself, and you still end up with a net performance boost."

Azert remelem hogy ezek a kijelentesek nem fognak hatranyt jelenteni a postgresnek beepulni a PHP-be a tovabbiakban, lehetne kezdeni perlezni, regexp hegyek egy tok egyszeru feladathoz, yeah.