Új webfejlesztés. Hogyan csinálnád?

Internet: PHP, CGI, stb.

Sziasztok,

Egy (várhatóan) nagyvolumenű webes alkalmazást szeretnék készíteni nulláról, hiszen ősrendszer nincs. Szeretném kikérni nálam okosabbak véleményét: hogyan állnátok neki?

A paraméterek:
- web, mind desktopra mind mobilra (WAP 2.0), többnyelvűség kell,
- olyan rendszer szükséges, amelyet könnyen lehet apró újdonságokkal bővíteni, tehát valamiféle modulorientáltság kell ( minden modulnak M,V és C (MVC) komponense is van),
- Google Maps rajzolgatós feature-kkel,
- szükség lesz ajaxos lekérdezésekre is,
- egyedi oldalra lenne szükség, tehát a Drupal és egyéb CMS rendszerek kilőve,
- várhatóan nagyon nagy adatbázisra lesz szükség, így az elosztottság megfontolandó, de inkább sok, egyszerű és gyors lekérdezés várható.

Sokat olvasgattam ilyen témában, minden választott útnak megvan az előnye és hátránya, ezért arra lennék kíváncsi, Ti konkrétan hogyan csinálnátok (nincs sok tapasztalatom, főleg Javas területen). Válaszok, amire számítok:

1. Adatbázis: Melyik (Oracle/Postgres/Mysql/DB2,...), és hogyan lesz belőle distributed db, milyen technológiát érdemes használni, hogy könnyen kezelhető transzparens legyen? (Cassandra, Thrift ?)

2. Kontrollernek milyen alapot és framework-t választanál? (PHP + symphony/Yii/Zoop/Zend/stb vs. Java + JSF/struts/? vs. ... ). Pl. facebook is Hip-Hop-ra ment, nem-e érdemes egyből vmi. hasonló technológiát használni?

3. A View-t miként érdemes létrehozni? (HTML + CSS, XML+XSLT+CSS, XHTML+CSS, ?) Ugye itt a mobiloldal az érdekes.

4. Testbed: Hogyan oldanád meg ügyesen a rendszer tesztelését? Értem itt pl. a modulok unittest-jét.

5. Google Maps: Valami olyanra lenne szükségem mintha az autocad 2D-s poligonrajzolóját ötvöznénk a Gmaps-el. (lásd. http://www.wikimapia.org ) Továbbá érdemes-e a google-t választani v. más térképet használnál? (Yahoo/Bing/NAVTEQ/Digital Globe, stb)

6. Hardver: Milyen vasra tennéd? Külön vásárolt szerver, VPS, Rackspace, ... ?

Remélem másoknak is hasznos lesz. Köszi.

  • 6396 megtekintés

( andrej_ v | 2010. 08. 19., cs – 22:38 )

Én csak néhány ponthoz tudok tippet adni:

1) PostgreSQL. Egyszerűen bontsd több táblára a dolgokat (abc és hasonlók alapján) és ami olyan adat (pl. egy fórumban a hozzászólások szám) azt ne on-demand számold ki, hanem a megfelelő triggerrel update-eld. Ez nyilván akkor megy jól, ha a sima SELECT-ek aránya jelentősen nagyobb a módosításoknál. A normálformákat szintén nem biztos, hogy be kell tartani, mert "olcsóbb" néhány százalékkal több adatot tárolni, amivel néhány join, többtáblás lekérdezés és view megspórolható.

3) Bármi + CSS, itt nyilván a fogadó oldal támogatása a lényeges.

6) Indításnak mindenképp VPS, mert már elsőre is elég egyedi környezet rajzolódik ki előttem. A VPS-ről később elég könnyű dedikált vasra átmigrálni, ha indokolt lesz.

Ezek szerint előreláthatólag nálad is az adatbázis elérés lesz a 'bottleneck' (mint szinte mindenhol). Szerintem megfontolandó már most elkezdeni a fejlesztést egy MongoDb szintű adatbázisra. A Cassandra projektel még sok zizz van, bár mire kész lesz a nulláról projekted talán ez is kiforrottabb lesz. A MongoDb kiadási ciklusai nagyon gyorsak és eddig kellemes tapasztalataim vannak vele éles környezetben.

Hát, hogy mennyire értenek az SQL-hez úgy alapvetően azt inkább hagyjuk szerintem. Amíg röpködnek a sokszázezer soros táblákra a "select * from akarmi where izeke1 like '%%' order by izeke2 desc limit $x" jellegű queryk - természetesen bármilyen indexet nélkülöz a tábla - addig nem az rdbms a szűk keresztmetszet. :)

Amennyi MySQL őrülettel meg eddig találkoztam, mind egyszerű felhasználói és rendszergazdai oldalról, hát nem biztos hogy rá akarnám bízni az életem.

Haha.. Saját tapasztalatom meg az, hogy odaadsz egy tipikus apt-get install debillany/bubuntu/egyeb-tipikus-divatdisztro rendszergazdának valami nem annyira mainstream cuccot, akkor csak szenved vele, merthogy jajúristen ez nem mysql/apache/akármi. Még akkor is, ha megmondod, hogy a dokumentációban melyik része kell neki.

Szóval azért ilyen szempontból az is lehet szűk keresztmetszet, hogy kinek kell üzemeltetni azt a rendszert.

----------------
Lvl86 Troll

( BehringerZoltan | 2010. 08. 19., cs – 23:57 )

Hat nehez megszolalni, mert az ember nem biztos benne, h hogy okosabb Nalad :-)
Szvsz azokra a kerdesekre amikre valaszt varhatsz innen jelen pillanatban, csak a feladat ennel nagysagrendekkel cizellaltabb ismereteben lehetne megadni. pl. Azt irod nagy adatbazis lesz. Ez mit jelent? Az adatbazis szerkezete lesz nagyon bonyolult es/vagy rengeteg adatot kell kezelni? A nagy adatbazisbol amugy nem kovetkezik az elosztottsag kenyszere, ellenben kovetkezik a rendelkezesre allasbol es a varhato terhelesbol. (ha bonyolult adatbazisrol van szo, akkor nagyobb jelentesoge van a tervezesnek, mint annak, h most Mysql v. posgresql v. akarmi. Valoszinuleg mindegyik megfelel a celnak. Tovabbi szempontok is lehetnek meg pl. h a fejleszto melyikkel van kozeli baratsagban.) Raadasul az adatbazis elosztasanak tipusa meghatarozza az alkalmazast is.

Szoval nekem az az erzesem - ne haragudj meg - h ugy akarod megoldani a feladatot, hogy meg maga a feladat sem kristalyosodott ki igazan benned. Ha ez megtortenne, akkor belatnad, hogy nem lehet egy nagy rendszert megtervezni egybol, nem tudsz facebook -ot, de meg egy CMS -t sem tervezni a nullarol, es egy internetes forum - mint kommunikacios felulet -sem alkalmas arra, hogy nehany kozhelyszeru altalanossagon tul, erdemben segitsen Neked ebben a munkaban. Persze lehet, h ennek ellenere is kapsz majd olyan otleteket, amik a hasznodra valnak.

Biztos h sokan okosabbak vagytok nálam.

Az adatbázis bonyolult is lesz ( erre céloztam azzal, hogy a moduloknak van model része is, azaz kvázi minden modul külön adatbázis-résszel is rendelkezne ), továbbá rengeteg adat is várható. A várható terhelést nem tudom megbecsülni, hiszen ilyen téren tapasztalatom nincs, mindössze a tanulmányaim sugallják azt, hogy érdemes lehet elosztott db-ben gondolkodni.

A feladat megoldásának tervezési fázisában vagyok, ezért természetesen nem kristálytiszta minden, de szerintem a projektek 90%-nál ez a helyzet.;) Nem akarok facebook-t, isten ments, én csak arra lennék kíváncsi, milyen technológiák, ötletek jutnak eszetekbe, ha ilyen méretű projektbe kezdenétek.

A várható terhelést nem tudom megbecsülni, hiszen ilyen téren tapasztalatom nincs, mindössze a tanulmányaim sugallják azt, hogy érdemes lehet elosztott db-ben gondolkodni.

Magadnak csinalod, vagy masnak? Van-e tobbtizmillio forint a reklamra..? Azert, mert sok felhasznalora szamitasz, nem biztos, hogy lesz is...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Bocs, hogy bele-offolok, de úgy érzem a kérdéseidből, hogy te sokkal jobban otthon vagy a témában, mint én.

Kérdésem, milyen jellegű adatbázist érdemes használni, ha:

  • Az adatszerkezet szinte triviális (pár táblában le lehetne írni, minimális oszlopszám, nagyon egyszerű relációk);
  • A lekérdezések egyszerűek, 1-2 WHERE feltétel, nagyságrendilek jóval kevesebb lekérdezés, mint INSERT;
  • Rengeteg INSERT, napi szinten százezres, milliós nagyságrendű új rekord;

A válaszokat előre is köszönöm,
M.

en is belepofatlankodnek:
- kell-e halozati tamogatas, vagy mindig csak 1 geprol fogok-e uzemeltetni (ez kizarhatja a sqlite es hasonlo megoldasokat)
- lekerdezesek milyen tipusuak (hasznalsz-e subselectet, joint, range tipusu lekerdezeseket, vagy esetleg csak elsodleges kulcs alapjan lookup-olsz)
- kellenek-e tranzakciok
- a napi millios rekordszamot egybe kell-e kezelned(kell-e count-ot, avg-t egyebet futtatnod ra realtime)
- mekkora rendelkezesreallast kell garantalnia a rendszernek

elso korben megneznem a tokudb-t:
http://tokutek.com/
kivulrol nezve szabvany mysql, emiatt viszonlag sok minden tamogatja, viszont ~konstans insert ideje van a fraktal fa indexek miatt, nem ugy mint a normal innodb-nel, aminel nehany szaz millio, egy-ket milliard rekordnal mar eleg be tud lassulni az indexek beszurasa.

es a kereses is gyorsabb

de rengeteg mulik azon, hogy mire akarod hasznalni tenylegesen.
bizonyos meret folott, es ha eleg az elsodleges kulcs alapu lookup esetleg mapreduce tipusu keresessel, akkor valami HBase/Cassandra tipusu megoldas sokkal jobb valasztas lehet.
http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/

Tyrael

kell-e halozati tamogatas, vagy mindig csak 1 geprol fogok-e uzemeltetni (ez kizarhatja a sqlite es hasonlo megoldasokat)
Kezdetben mindenképp az a cél, hogy 1 gépről üzemeltessünk. Valószínűleg sokáig nem is lesz szükség plusz feldolgozási erőre. Leginkább a folyamatosan növekvő adatmennyiség miatt aggódom, a másodpercenként pár insert gondolom nem egy hatalmas követelmény.

lekerdezesek milyen tipusuak (hasznalsz-e subselectet, joint, range tipusu lekerdezeseket, vagy esetleg csak elsodleges kulcs alapjan lookup-olsz)

  • Range típusú lekérdezések előfordulhatnak (dátum, és számok)
  • Join maximum 2 tábla között
  • Subselect, egyelőre nem gondolom, hogy lenne

kellenek-e tranzakciok
Na ezzel megfogtál, mindig úgy tanultam, hogy tranzakciókra minden körülmény között szükség van. De elgondolkodva a megoldandó problémán (mérési adatok gyűjtése), kissé elbizonytalanodtam.

a napi millios rekordszamot egybe kell-e kezelned(kell-e count-ot, avg-t egyebet futtatnod ra realtime)
Egyben nem kell kezelni, bizonyos (~1000 rekordnyi) részhalmazára avg, count előfordulhat.

mekkora rendelkezesreallast kell garantalnia a rendszernek
Kezdetben ez egy belső project lenne, tehát nem kell irreálisan nagy követelményeket támasztani ilyen téren. Ha néha van kiesés az nem tragédia, későbbiekben persze nem árt, ha van lehetőség fejlesztésre.

( radix | 2010. 08. 20., p – 00:31 )

Kulcs-szavak:
-mysql
-Zend framework
-Ext-js (böngésző alkalmazás)
-sencha (mobil device)

( Tyra3l | 2010. 08. 20., p – 08:24 )

ha tenyleg ekkora project, akkor keresnek valakit, aki latott mar ilyesmit, es alkalmaznam.
a budzse meg az SLA eleg rendesen bele tud szolni abba, hogy milyen architechturat, vagy koponenseket hasznalhatsz.

Tyrael

+1 Egy hozzáértő alkalmazásával a kezdeti többletköltség később többszörösen megtérül, lásd itt. Nem azt mondom, hogy ti is eljuttok erre a szintre, csak tipikus esete a "kezdjük el majd lesz belőle valami, aztán meg akkorára nő a projekt, hogy csak kapkodunk"-nak.

java'nother blog

( T_chris | 2010. 08. 20., p – 08:38 )

A mobilos kérdést körbe kellene járni, mert a mai készülékek többségében már nem wml, hanem html böngésző van.
Egy tizenezer forintos vas is már Netfrontot, meg Flash Lite 2.x-et tartalmaz. a vadabb vasaknak meg a komolyabb oldalak sem akadály.
Illetve érdemes figyelembe venni az opera mini-t is hiszen jelentős részét uralja a mobilos böngésző piacnak...
- - - - - - - - - - - - - - - - - - - - - - - - -
Fejlődőképes hiperláma, és okleveles érdekfeszítő

( kmARC v | 2010. 08. 20., p – 09:35 )

Hát rendkívül összetett, és sok kérdésed van, igazándiból a kérdéseid már-már a megvalósíthatóság, illetve "rendszermodell" kategóriába esnek; már abból ötven-száz oldalas összefoglalót lehetne készíteni, ha ezeket a kérdéseket mind alapos utánajárással megválaszolnád magadnak :) Dehát ötleteket gyűjteni okos dolog, szóval hajrá!


> 3. A View-t miként érdemes létrehozni? (HTML + CSS, XML+XSLT+CSS, XHTML+CSS, ?) Ugye itt a mobiloldal az érdekes.

Én ezt ragadnám ki, ma már a trend a HTML5 + JavaScript + CSS3 felé megy, valószínűleg amire a projekted kiforr, már alapelvárás lesz, szóval mindenképp ebben kellene gondolkodni.
Buktatók:
- Javascript - ezzel van a legkevesebb gond. Ha sok a browserben megvalósítandó GUI logic, akkor valami JS GUI toolkit (EXTJS, akár GWT), de ha kevés, akkor is érdemes valami JS framework (pl.: jQuery) Elindulásnak nézz körül a JavaScript framework-öket összehasonlító Wikipedia bejegyzésen.
- HTML5 - ezzel már egy kicsit több probléma lesz, mivel a régebbi böngészők nem fogják ismerni a HTML tag-eket, de semmi probléma, hiszen ezeket mind-mind elő lehet állítani (JS) kódból ún. HTML5 enablerekkel, és így a régebbi böngészők is tudják majd kezelni.
- CSS3 - ezzel pedig a legtöbb gond, mivel össze-vissza implementálják a böngészők a különböző verziójú ajánlásokat, más-más default értékekkel (külső-belső margók, betűméretek), és akár saját attribútumokkal (-moz, -webkit, és társaik). Először is fogsz egy CSS resetert, majd ha tényleg nagyon sok CSS-re van szükséged, akkor erre is valami CSS frameworköt.

- De ami még ígéretesebb, és megfontolandó, hogy eleve minél kevesebbet szívj: Ez pedig a HTML5 boilerplate

Remélem segítettem a View-val kapcsolatba, vigyázz, mert ha elkezded ezeket a linkeket végignézni, garantáltan egy-két órát elvesztesz az életedből a technológiák, megoldások, frameworkök, stb. felfedezésével. :)

Szerkesztve:
Ja, és ez csak egy jó tanács, saját weblapon (nyílván ami nem blog, stb.) mindig, csak és kizárólag helyesen fogalmazz és írj! (pl.: "nem-e" elfelejtése :) )

( shiki | 2010. 08. 20., p – 09:39 )

Szakmai kérdést miért HUPra írod? :-/

Lehet van benne valami, tényleg elég óvódás kérdéseket írnak mostanában a fórumba, de ez még nem zárja ki azt, hogy ne lennének ott is hozzá értő emberek. Meg ha ilyen kérdés mint verkrié nem kerül oda, akkor magasabb arányban lesznek láma kérdések, ami mégjobban lenyomja az oldal színvonalát. Szerintem.

( scottscott v | 2010. 08. 20., p – 10:04 )

jquery-t mindenképpen ajánlom több dolog miatt is:

- google maps (remek plugin van hozzá, amellyel sok pontot lehet kirajzolni viszonylag gyorsan)
- megjeleno jquery mobil miatt, ha fontos a mobil felület akkor sztem kötelező lesz a jövőben ez

A post egyébként érdekel és jó felvetés, valószínűleg hamarosan visszatérek én is elolvasni a "végeredményt" - ha lesz ilyen.

btw, ha komoly és nagy oldal lesz, akkor a vas-nál a cloud rendszert sem vetném el.
____________________
http://asva.info | Vicces képek | LinkTömörítő | Android hírek, tippek

( syntern | 2010. 08. 20., p – 10:11 )

1. Olvass ebay scalability tanulságokat indulásnak, erre nincs egyszerű válasz...
2. Ha Java, akkor Wicket + JQuery kombináció eléggé erős. Nem kell túlcizellálni a dolgot mindenesetre...
3. Külön UI böngészőre és külön mobilra.
4. Ha Java, akkor jó sok unit teszt, JUnit, Sonar / Hudson, ha Wicket akkor annak van UI tesztelője is
5. -
6. Kezdetben: Amazon EC2, később ahogy növekszik, vagy további EC2, vagy saját adatpark építése.

Amúgy levél ment...

( Aadaam v | 2010. 08. 20., p – 12:13 )

Az van, hogy az emberek jelentos resze komolyan azt hiszi, hogy indulas utan masnap 2 millio user lesz. Nem.

Egy haver most hisztizett ki egy 32 GB memoriaval rendelkezo VM-et, hogy ne legyen skalazodasi problemaja, a hosting nezett, aztan szerzett valahonnan olyan VMWare licencet amivel ezt lehet.

A PHP-ban az a jo, hogy nehez elcseszni a skalazodasat. Egyetlen helyen lehet, az a DB reteg, ott meg picit esznel kell lenni, es jo absztrakcioval keszen vagy.

Ha ennyire felsz, indulj symfonyval. Ne Zenddel, a Zendben kezzel kell kezelni a cache-t (be kell hivni a Zend Cache-t, implementaciot kell neki adni, stb), a symfony ezt neked latatlanban le fogja tudni kezelni. Maga az alaprendszered picit lassu lesz, finomhangolni kell, de azert alapvetoen mukodni fog. Ja es a DB retege biztositja azt, hogy esznel maradj.

Nagyon sok esetben nem kell maganak a DB-nek distributed-nak lennie, eleg ha a cache reteg az. A MySQL MyISAM nem nagyon fog lassitani, szoval celnak jo lesz, bar neha meg fogsz lepodni, mennyire primitiv tud lenni.

Startbol, hogy megnyugodj, berelj ki ket VM-et, amik a PHP alkalmazasszervereid lesznek, meg egy load balancer-t. A ketto es az egy kozott az a kulonbseg, hogy barmilyen marhasag amit csinalnal, es nem lenne skalazhato, jobban ki fog derulni. A kettonek viszont legyen kozos a fajlrendszere, legalabbis ami a webes dokumentumokat illeti, hogy kevesebb szivas legyen vele

(Amennyiben sajat vasat akarsz, akkor valami sokmagos, sokmemorias kutyu + egy vmware licenc. Ha burzsujkodsz, vehetsz SAN-t, vagy NAS, vagy nemtom hogy hivjak - sz'al halozatra kotheto diszk - de ismet szeretnem jelezni, hogy a weboldalak 95%-a nem jut tul azokon a korlatokon, amikhez egy gep is boven elegendo, sz'al ha nem muszaj, ne feccolj bele penzt sztem.)

Ha ezzel megvagy, rakj fel mondjuk egy memcached-t. Igazabol barmi megteszi - reddis, mongodb, mittom - a memcached egy standard megoldasnak minosul. Ezt allitsd be a symfonynak cache retegkent.

Persze lehetne azt mondani - az okosok majd itt porognek egyet - hogy rogton kezdj mongodb-vel vagy couchdb-vel es hasznalj map-reduce adatbazist. Ez szep es jo, a keretrendszer-tamogatas hozza azonban veges, azt mondod, nem igazan vagy guru ezekben a technologiakban, es megegyszer, annak az eselye, hogy neked ez tenyleg kell majd kesobb,kozel se 100%.

Szoval ha flickr kiskalazza magat pusztan memcached+mysql-lel, neked is jo lesz.

A HipHop hogy tisztazzuk, egy PHP VM, ezzel egyelore ne foglalkozz, rakj fel egy APC-t, vagy Zend Accelerator-t, Optimizert, Ecache-t, valamelyiket. A Symfony majd listazza, hogy miket tamogat ugyis devel uzemmodban. Ha nagy baj lesz, egy ejszaka alatt atallhatsz hiphop VM-re, de addigra mar multimilliardos leszel ugyis.

A View HTML + CSS. Az XHTML egy rossz vicc sokak szerint a webszakmaban. Lojj webkitre (mobil safari, mobile chrome, S60 Browser), ezzel a tenylegesen hasznalt mobilbongeszok 94%-at lefeded. Ha barmi baj van, majd megbeszeled a symfonyval az sfView atirasaval, hogy hogy lesz ebbol wapoldal. De egyelore loj ezekre, kevesebb problema.

Testbed: kulon tesztadatbazis, fixtura ki-be toltes, ja, es ne UI szinten akarj tesztelni. Az neked nem jo. Irj unitteszteket modellszinten, es vastag modelljeid legyenek (a business logikat ne pakold bele a controllerbe). Vannak browseremulatoros tesztek (akar a symfony functional tesztjei, akar sajat seleniumos jatekok), a tapasztalat az, hogy a specifikacio gyorsabban valtozik, mint amilyen gyorsan a teszterek gepelni tudnak. Az a teszt, ami csak hatraltat a munkadban, elobb-utobb kikapcsolasra kerul, es az azt a hamis illuziot kelti, hogy vannak tesztjeid, holott nincsenek.

Google Maps-szal nincs gond, keresel egy szep js mernokot, es meogldja.

Rackspace: szeretem a rackspace-t, aranyos, fiatal, lenduletes sracok, de dontsd el, hogy hol lesznek az ugyfeleid. Ha az ugyfeleid budapesten lesznek, akkor a BIX-en hostoltass. Ha amcsiban, lehet rackspace. Tudom, majd vilaguralomra szeretnetek torni, de ugy az elso 10000 felhasznalo hol lesz, ez a nagy kerdes. Ezen kivul, ha tenyleg szet lesz szorva az a 10 000 ember, most kezdj el gondolkozni egy CDN licenc megvasarlasan, mert a fenysebesseg veges. Bar valoszinuleg raersz.

Nagyjabol ennyi. Eleg sok ugyfellel vegigjatszottam mar ezt a vilaguralmi jatekot, neha picit unom, ezert ne haragudj, roviden a symfony nagyjabol jo lesz neked safe netnek. Aztan amikor tenyleg problema lesz ebbol, ugyis fel kell berelni valakit, aki rendet tud teremteni, de akkor meg mar lesz penzed.

A Rotschildeknek is kellett par ev.

Hát szépen összefoglaltad a dolgokat, de személy szerint nem mindennel értek vele egyet.

"A PHP-ban az a jo, hogy nehez elcseszni a skalazodasat." kokrétan nincs benne skálázódás, azt leszámítva, hogy akárhol futtathatod, ha eléri az erőforrásokat, ezt nem nevezném skálázhatóságnak. Nincs benne session replikáció, meg még egy rakás dolog.

"A MySQL MyISAM nem nagyon fog lassitani, szoval celnak jo lesz" hát lassítani nem fog az tény, de olyan buta mint a faék, komoly célra nem érdemes vele szívni, ugyanis elég macerás, és sok hibalehetőséget von maga után kódból kezelni minden tábla-kapcsolatot, meg a csomó dolgot, amit db-szinten lehet implmentálni, csak épp a MyISAM nem tudja.

"Szoval ha flickr kiskalazza magat pusztan memcached+mysql-lel, neked is jo lesz." nyilván, csak akik ott dolgoznak, és most nem a kérdező szintjét szeretném lehúzni vagy firtatni, azok nem tesznek fel ilyen kérdéseket.

"Az XHTML egy rossz vicc sokak szerint a webszakmaban." sokak szerint meg a html 4 :D, és az ie-n kívűl tudtommal a böngészők nagyrésze jobbam kezeli a valid xml-t, de ez flametéma.

java'nother blog

Nezd: a PHP-ban nincs allapotter, a teljes allapotter per request alapu.

Baromi mertekben fel tudjuk igy skalazni a - meg nem nevezendo ugyfel - rendszereit emiatt!

A kod 10 eves, nem mindenhol nyerne szepsegversenyt, de nem lehet elcseszni egyszeruen. Arra kell figyelni, hogy a delikvens ne hivjon kozvetlenul bele a MYSQL-be, meg a konkret feluletek belemennek egy squid-szeru kepzodmenybe, de onnantol kezdve akarhany node-on futtathato az egesz.

A session replikacioval sem ertek egyet veled - van! Csak irni kell egy session handler-t (set_session_handler fuggveny), ami valami stabilabb elolenyre - pl. memcached - tamaszkodik, es keszen vagy! (Nyilvan nem ennyire ecceru, de nem a PHP-n bukik)

A vilag legnagyobb weboldalai alatt nem java fut, hanem PHP. Pontosan ezert, mert tetszoleges merteku idiotasagot regularis kifejezesekkel ki lehet irtani belole kb. Javaban mindezzel foglalkozni kell, a felvetelik rendszeres temaja tobb cegnel a threading, es az ezzel kapcsolatos problemak.

A MyISAM buta mint a faek, az teny. Na de a mongodb-t se az eszeert szeretjuk. Altalaban elmondhato, hogy minel nagyobb skalazodast varunk egy rendszertol, annak kisebb komplexitasuak lehetnek az egyes komponensek. Tamaszkodhat az innodb-re, csak pillanatok alatt megfogja a skalazodasnal.

Aki ilyen kerdeseket tesz fel, altalaban azt hiszi, hogy hirtelen valtja meg a vilagot. En csak szeretnem, ha kapna egy megnyugtato alapot - a Symfony eleg jo ehhez - es majd ha konkret baja lesz a skalazodassal, raer kerdeseket feltenni.

Az XHTML-rol tenyleg megoszlanak a velemenyek, manapsag azt mondjuk, hogy mivel a 3 fo bongeszo-engine 3 kulonbozo dolgot ert valid XHTML alatt, ezert inkabb talan hagyjuk a fenebe. Nem talalom most a cikket, de futott par kort 2 eve.

"A vilag legnagyobb weboldalai alatt nem java fut, hanem PHP. Pontosan ezert, mert tetszoleges merteku idiotasagot regularis kifejezesekkel ki lehet irtani belole kb. Javaban mindezzel foglalkozni kell, a felvetelik rendszeres temaja tobb cegnel a threading, es az ezzel kapcsolatos problemak."

Ez így elég merész kijelentés, kb. azt jelenti, hogy "Mivel a Java több dolgot tud, ezért rosszabb." Buta fejlesztők irányából igazad van, a mesteremberek kezében meg sokkal kifinomultabb szerszám :) A Google Adwords egyébként mióta nem tartozik a legnagyobb weboldalak közé? Értem hogy nem weboldal, de a világ leginkább használt hirdetés-megjelenítő engine-je, ha ignoráns vagy a többire, legalább ezt említsd meg a PHP-tengerben :)

"Altalaban elmondhato, hogy minel nagyobb skalazodast varunk egy rendszertol, annak kisebb komplexitasuak lehetnek az egyes komponensek."

Ez így szerintem pontatlan. A skálázódás az nem az egyes eszközök butaságán vagy okosságán múlik, hanem az egymástól való függőségük mértékén. Ha alacsony a függőség szintje, akkor tudsz skálázódni, ha magas, akkor nagyon hamar limitáló tényezőbe futsz.

Nezd, ha valaki megkerdezi, hogy hogyan kell nagy skalazodasu weboldalt csinalni, annak jobb ha nem adjuk oda a java-t, mert nyit benne egy threadet aztan az appszerver hirtelen nem tudja, mit csinaljon (biztos tudja, de mindketten tudjuk, hogy inkab ne)

GMail is java-python keverek, sot, GTalk is java, persze, csak ezeket Xandrew szintu emberek fejlesztik, akiknek mondjuk ott a CS doktori - es meg persze sorolhatnank mas ismerosoket Lukacstol kezdve. Persze, ha ilyen embereid vannak, vigyed nyugodtan a javat. Meg akar veled is syntern. De nyugtass meg, hogy nem a hupon kerdezned meg, hogy kell csinalni :)

Egy mature, picit moricka-modon megirt, de soktizezer-szazezer soros java appot viszont kiskalaztatni... ott vannak kockazati tenyezok. Tudom, szigoruan tipusos nyelven mindent meg lehet oldani automatikusan, de inkabb butitsuk az eszkozkeszletet. Celnak jo a PHP, en ertem, hogy nem lehet benne oprendszert irni, meg mobiltelefon-platformot, de a srac weboldalt akar.

(Startupot hulye programozokkal mar lattam kiskalazni PHP-ben, en is skalaztam ki egy-kettot, meg lehet csinalni. Meg lattam hipertehetseges java architekteket masfel evig szivni hasonlo problemakorrel.)

Rosszul irtam, igazad van, a kommunikacio komplexitasa csokken. A PHP amit kevesebbet fog csinalni, az az, hogy kevesbe fog fuggni a geptol, amin fut, mivel o kizarolag a requestektol, meg 1-2 beallitott komponenstol (session handler, db, esetleg cache szerver) fugg. De ez itt most elony, hogy Moricka nem irhatja be a kod kozepere, hogy new java.lang.Thread.

(Ha meg csak azt irhatna be, nyugodt lennek, de sajnos talalni fog a neten valami libet, amit nem is forrasban rak fel, hanem ebben a felforrasos vicces java byte-code-ban, es az majd implemental magaban valami runnable-t, amit vadassz ki...)

Google app engine-ben szépen megoldották, hogy ha új Thread-et próbálna valami botor nyitni,akkor kap az arcocskájába egy szép nagy exception-t :D

BTW én is a symfony-t javasolnám, de ha jól értem, az érved a java ellen az, hogy hirtelen elkezdenek mindenféle überenterprise megoldásokban gondolkodni az emberek, még akkor is, amikor erre nincs semmi szükség, illetve hogy egységsugarú phppistiknek az túl bonyolult?

Nem, tenyleg az a baj, hogy onnantol, hogy picit tobbet tud a platformod, mint kene, onnantol konnyebben el tudod cs.ni. Egy idoben XML fajlokat probaltak adni a usernek, mondvan, azt nem tudja elcs.ni, hat, a dolog nem jott be.

Az uberenterprise megoldasokkal alapvetoen nem lenne gond, de egyreszt amire kikecmereg belole, ha eddig nem ertett hozzajuk, az ido, masreszt meg nem igazan a feladatra koncentral nemelyik. Aki 10 eve javazik, annak a symfony nagyobb szivas, viszont legalabb nem azon gondolkozik, hogy icefaces vagy wicket, ami a problema szempontjabol irrelevans.

(Mondjuk a JSF-rol kulonvelemenyem van, roviden egy letezo problema nemmegoldasa szerintem, de ezt mar parszor kifejtettuk egymasnak a java gurukkal egy masik topicban, ne flame-eljuk ezt ossze :)

Meg igaz az is, hogy elindulni a php-vel egyszerubb. Bar en mar fontolgatom a javajozsi kifejezes bevezeteset, a vilag nyilvan nem csak ezekbol az emberekbol all, csak en azt tudom, hogy PHP webalkalmazast kimosni ebbol az allapotbol mennyi ido, meg azt latom, hogy mennyi kimosni a javasakat. Persze lehet azert, mert nagysagrendekkel tobbet ertek a dinamikus nyelvekhez

Alapvetoen az elso koros skalazodas celja pusztan annyi, hogy ne kovess el vegzetes hibat. A MyISAM eleg korlatos, viszont pont a korlatjai nem engednek majd ilyen hibakat. A PHP szinten ilyen.

Ilyenek nyilvan a Map-Reduce adatbazisok is (sz'tem a legelvetelmultebb mongodb/couchdb fan is elismeri, a cucc erosen korlatolt), csak annyira szokatlanok es ujak, es neha meg annyira lassuak is tudnak lenni, hogy jobb, ha maradunk az ISAM-nal :)

De osszessegeben: a korlatok jok - nem hagynak leesni.

Ezzel kb egyet is értek. Mondjuk én java-zok, kb. a 10 és is meglesz lassan, de
amikor egy webes cuccot kell csinálni, akkor én is symfony-t használom, mert
egyszerűen jól össze van rakva, és mindig csodálkozom, hogy miért nincs ilyen
java-hoz, bár a play! framework már majdnem olyan.

A javajozsi is tetszik, engedelmeddel átveszem :D

Igen, a javas megoldásoknál talán ott lehet a gond, hogy az emberek bíznak a j2ee igéretekben,
hogy az majd skálázódni fog, aztán vagy fog, vagy nem. Egy sima servlet szintű megoldásnál (gyakorlatilag php, max egy kis framework fölötte) elég nagy eséllyel fog a cucc skálázódni.

Érdemes egyébként átpörgetni a google io youtube videókat, ott rengeteg órában arról beszélnek a google's kollégák, hogy miért úgy csináltak, hogy rendesen skálázódó rendszert tudjanak csinálni.

Ha már javas framework, akkor a wicket megvan? Vagy mit tud a symfony olyan nagyon jól?

javajozsi helyett javagupta? Csak hogy a Józsik ne sértődjenek meg nagyon. Nemzetközi fórumon meg lehet javajózsi...

"a javas megoldásoknál talán ott lehet a gond, hogy az emberek bíznak a j2ee igéretekben"

+ emellett nem gondolkodnak, mert más az ígéret technológiai és más az ígéret marketing-brossúra szinten :)

A symfony egy teljesen összeintegrált rendszer, model, controller, view szinten. Az
adatbázis sémádat megcsinálod egy yml-ben, ebből egy paranccsal legenerálja a model osztályokat (create scriptekkel együtt), ha kell, akkor a CRUD-okat is (weboldal, ahol az adott táblát tudod bizgerálni) amit csak testre kell szabni, mindennek megvan a helye (hova kerül a model, a controller, a form, stb.), van szép form validátor, vannak hozzá modulok is, amiket egyszerű telepíteni, szóval tip-top kis összerakott rendszer.

Ehhez jön még a symfony 2, ami még sokkal jobb lesz. (http://symfony-reloaded.org/)

Syntern, ha miattad kerultem a Pistike kifejezest, akkor ennyi hadd legyen mar... ;)

Az a baj, a Sunnak voltak dev marketingesei. Ugye nem kell bemutatni az IBM dev-marketing reszleget se?:) (azaz milyen a WebSphere a marketingben, meg milyen amikor programozni kell benne :)

A symfonyt leginkabb full stacknek lehet tekinteni: MVC, perzisztencia, elosztott cache, dependency injection, unit testing, functional testing,valami olyasmi, mint a J2EE (bar ez termek, nem szabvany) vagy a Spring MVC. Szempontunkbol itt most az szamit, hogy a perzisztencia, meg a kontrollerek tiszteletben tarjtak a cache-t meg korlatos mertekben az eloszthatosagot is, es ha nem nyulsz le privat melysegekbe, akkor nem lesz nagy baj.

Nagyon kedves Tőled, hogy kerülted, és igen, a dev-marketingből ismerek mindkét oldalról embereket :)

Az összehasonlításoknál az a bajom, hogy attól hogy valami épít az MVC-re, még nem hasonló egy másik MVC-s projektre. Amennyire érzem a symfony-hoz legközelebb talán a grails áll... Mindkettő érdekes játékszer, de ahogy nézem egyik sem támogatja az általam preferált document-based architektúrát (azaz nem relációs táblákban, hanem pl. json/xml dokumentumokban való gondolkodást. ez utóbbi nehézsége egyébként a hierarchiát bejáró indexekben van)...

Uj doctrine tamogatja a mongodb-t es az uj symfony is talan. XQuery-szeru vilag nem nagyon van szerintem, nem tudom, melyiket jelenti szamodra a dokumentum-alapu architektura (mert ugye azt meg lehet kozeliteni REST felol is pl.)

Map-reduce-hoz meg kell par ev, amire "normalis" lesz a hasznalata, jelenleg meg ott tartunk, hogy kozosen elfogadott query nyelv se nagyon van feleje, nem az, hogy nagyobb MVC frameworkok tamogassak...

Az osszehasonlitas alapja sokkal inkabb kulturalis szerep, semmint technikai volt (mar amennyiben lehet az egyes ecosystemekrol, mint kulturarol beszelni)

Ezzel én nem értek egyet teljesen. Ha valaki már fejlesztett mondjuk Symfony alatt,
az kb. tudja, hogy milyen lehetőségek, megoldások vannak adott problémákra, mi
lesz a controller, mi a model, mi a view, ezek hogy kapcsolódnak össze, hogy szokták
megoldani a route-olást, a unit tesztelést, stb., és én ahogy nézegettem a többi keretrendszert,
logikailag nagyjából hasonló megoldások vannak, kisebb eltérésekkel.

A "document-based" architektúráról írnál egy kicsit bővebben, hogy hogyan is működik egy ilyen, milyen feladatnál jött elő, stb?

document-based: van úgy hogy egy képernyőn (relációs modellre vetítve) 4-5 mélységű master-detail nézetet kellett megjeleníteni. Relációs, főleg erősen normalizált modellben ez elég macerás, mert kereséskor a több tábla joinja jön be a képbe, megjelenítéskor meg szépen végig kell olvasni a hierarchiát. Ezzel szemben ha a master-detail-t document-be szervezed (nevezzük XML-nek de alapvetően mindegy a fizikai formája), akkor csak egy read műveleted van, cserébe a hierarchián történő keresések indexelését kell másképpen megoldanod. Tehát ez sem csoda, csak máshova helyezhető a komplexitás, és az én esetemben ez így jobban kezelhető...

A VMware licenc részt nem nagyon értem, mert 32GB RAM elvileg nem gond az ingyenes ESXi-vel sem. Inkább a szolgáltatónál lehetett valami korlát, és így könnyebb volt megmagyarázni (például nem volt olyan gépe, amiben 32GB-nál több RAM lett volna szabadon, és ezt nem akarta bevallani).

Egyébként a VMware ez esetben arra is jó, hogy a fejlesztés/bevezetés már az elejétől elosztott architektúrán fusson, és ha beindul a biznisz, akkor már könnyen bővíthető legyen (nehogy pont a nagy siker elérésekor essen össze a teljes alkalmazás, mert nem oldható a meg a skálázása - elég morbid lenne).

Inkább tömörebb leszek, mint hosszabb, aztán úgyis bele lehet majd kötni :)

1. A PHP skálázódás-indifferens technológia. Önmagában nem dolgozik a skálázódás ellen, de nem is segíti kifejezetten, mert egy "buta" (*) technológia, és ahogy írtad, sok múlik a DB-rétegen, illetve annak kezelésén, sőt: leginkább csak azon múlik (innen az hogy a PHP indifferens a képletben).

(*) Összehasonlítva Java és .NET alkalmazásokkal, ahol azon kívül hogy a rákövetkező architektúrára tolod a komplexitást, jobban szét tudod választani az adott gépen belül is, jópár dolgot okosabban kezelve mint egy RDBMS. Én belevonnám ide a szinkronizációs és az aszinkron feladatfeldolgozást is, amit sokan megintcsak a DB-rétegbe tolnak be, és akkor persze hogy a PHP-n nem múlik semmi.

2. memcached: Itt arról beszélünk, hogy az RDBMS nem alkalmas egy feladatra (gyakori read műveleteket), tehát bevezetsz egy technológiát, ami alkalmasabb. Ezt (főleg ha Java-ban gondolkodik valaki), tovább lehet gondolni úgy, hogy a különböző intenzitású, konzisztencia-szintű, tranzakció- és sebesség-igényű műveletekre különböző technológiákat, különböző indexeket használunk, amelyek az adatra eltérő életkorban és módon pakolódhatnak rá. Ilyenek indexek lehetnek: near-cache, far-cache, RDBMS (b-tree index), NoSQL (hash- és inverted-index). Tudatosan nem egyik vagy másik kiemelését írtam, mi már kialakítottunk egy egész korrekt keretrendszert annak elérésére, hogy ezek megfelelően egymásra épüljenek. A "rápakolódás" sorrendje, mértéke és igénye eltérő lehet adat-típusonként, ezért érdemes az adatbázis többszintű partícionálásával is foglalkozni, mert a különböző adategységek más- és más erőforrás-igénnyel rendelkezhetnek.

Itt jön be nagyon az, hogy példázódhatunk flickr, facebook, twitter és hasonló rendszerekkel, hogy melyik mit használ, de minden egyes esetben eltér az adatkezelés módja és igénye -> más esetekben más technológiák kombinációja lesz a nyerő.

3. webkit: pipa, nincs értelme feleslegesen szabványokhoz ragaszkodni akkor, ha az nem jár előnyökkel.

4. ügyfelek kérdése: az Amazon európai datacenterét használjuk már több mint egy éve, és eddig sohasem volt panaszunk a sebességre.

Összességében egyetértek azzal, hogy a világuralomra törést későbbre kell halasztani, de előtte azért tisztában kell lenni, hogy melyik használt technológiának hol van a limiting point-ja.

( vizsla | 2010. 08. 20., p – 13:18 )

nem tudom pontosan milyen projektről van szó, de ha nem külső megrendelésre dolgozol, akkor először a product-market fit nevű szörnnyel kell megküzdened. Teljesen biztos, hogy nem tudsz egy bonyolult webalkalmazást nulláról megszülni úgy, hogy minden feedback és kisérletezés nélkül egyből jól használható lesz és népszerű.

az első alfa teszt simán futhat shared hostingon, lamp alapon. ha az elején elkezdesz osztott adatbázison meg dedikált szerveren gondolkozni, mikor még egyetlen usered sincsen, akkor biztos lehetsz benne hogy nem a valódi feladatra koncentrálsz.

a technikai megvalósítás a legutolsó probléma, soha nem abba buknak bele az ilyen projektek!

fejlessz ki egy alfát minél gyorsabban, minimális feature set, minimális hardware, minimális költség. mutasd meg sok embernek. a visszajelzések alapján változtass a koncepción.

ha majd már az lesz a legfőbb problémád hogy a VPS sem bírja a brutális forgalmadat, akkor elkezdhetsz azokon agyalni amiket írtál, de akkor már nagyon-nagyon jó helyzetben leszel. legtöbben nem jutnak el odáig. többek között azért, mert rosszul mérik fel a prioritásokat.

a tanulást itt érdemes kezdeni:
http://ecorner.stanford.edu
http://gettingreal.37signals.com/toc.php

sok sikert és kitartást kívánok!

Természetesen nem abban gondolkozok, hogy egyből egy teljes cloud-t bérelek, és 16 évig fejlesztem az elosztott adatbázisomat.

Csupán el szeretném kerülni azt, hogy ha netalántán sikeres lesz a prototípus, akkor ahhoz, hogy továbblépjek, nagy változásokat kelljen eszközölni.

Mindenkinek köszönöm az eddigi válaszokat, már nagyon tanulságos mindegyik! Csak így tovább! :)

értem hogy mire gondolsz, mégis éppen azt szeretném tanácsolni, hogy ne erre gondolj.
php, mysql, shared hosting. bőven ráérsz bonyolítani.
az aktuális problémára koncentrálj, az pedig a termék használhatósága a user szemszögéből. a skálázást sokkal könnyebb lesz megoldani később, mint ezt.
nehéz ezt elfogadtatni egy technikai fórumon, tudom. de sajnos tényleg az a helyzet, hogy az alkalmazásod sikere elsősorban nem a technikai megoldásokon fog múlni.

ezt nem én találtam ki, ezer helyen fogod ugyanezt olvasni, ha elkezded tanulgatni az online startup műfajt. itt van például a 37signals nevű sikercég véleménye a skálázhatóságról, szó szerint ugyanezt tanácsolják:

http://gettingreal.37signals.com/ch04_Scale_Later.php

a későbbi nagy változtatások elkerülésével pedig azért nem érdemes foglalkozni, mert nem tudod elkerülni. az online piacon olyan gyors üteműek a változások, hogy meg kell barátkozni a gondolattal, hogy ha versenyképes akarsz maradni, úgyis lényeges elemeit kell rendszeresen újragondolni az alkalmazásodnak.

"You have to revisit anyway
The fact is that everyone has scalability issues, no one can deal with their service going from zero to a few million users without revisiting almost every aspect of their design and architecture."
—Dare Obasanjo, Microsoft (from Scaling Up and Startups)

( tamaas | 2010. 08. 20., p – 15:29 )

Akkor pár tipp tőlem is, csak hogy ellentmondjak az előttem szólóknak:

1. Adatbázis: PostgreSQL, nekem tetszik, megszoktam, szerintem nagyon sok dolog kényelmesebb benne, mint MySQL-ben, de ez hitvitába menne...

2. Kontrollernek milyen alapot és framework-t választanál? Java, JSF, IceFaces, EJB-k, Hibernate a DB-hez

3. A View-t miként érdemes létrehozni? (HTML + CSS, XML+XSLT+CSS, XHTML+CSS, ?) Ugye itt a mobiloldal az érdekes: HTML(5) + CSS. Az én mobilom megeszi, szerintem lassan mind elfogadja ezt a kombinációt. De csak óvatosan és sokszor tesztelve a különböző böngészők eltérő CSS kezelése miatt.

4. Testbed: Hogyan oldanád meg ügyesen a rendszer tesztelését? Értem itt pl. a modulok unittest-jét.: jUnit

5. Google Maps: Valami olyanra lenne szükségem mintha az autocad 2D-s poligonrajzolóját ötvöznénk a Gmaps-el. (lásd. http://www.wikimapia.org ) Továbbá érdemes-e a google-t választani v. más térképet használnál? (Yahoo/Bing/NAVTEQ/Digital Globe, stb)
Ilyet még nem csináltam. IceFaces tud alap google map-et, de ilyet nem. De biztos megoldható...

6. Hardver: Milyen vasra tennéd? Külön vásárolt szerver, VPS, Rackspace, ... ?: Ehhez nem értek, de én is eleinte bérelnék valamit és ha idővel szükség van rá, úgy mozgatnám nagyobb, egyedi hardverre...

( lzskiss | 2010. 08. 21., szo – 14:57 )

ha ilyen php vonalon gondolkodsz, vess egy pillantast a silverstripre is.

OpenBSD 4.7/i386 theo for the prezident:D

( Kormoraan | 2010. 08. 21., szo – 15:40 )

Nem kötözködésképpen, hanem a legteljesebb jószándékkal mondom:

Ha mindezt nem tudod, akkor eszedbe ne jusson nekiállni egy igazán komoly alkalmazás fejlesztésének. A fentiek közül több jó megoldás is van, de némelyeket alaposan ismerned kellene ahhoz, hogy valóban szinvonalas munkát tudj a kezedből kiadni ésszerű határidőn belül.

Ha nem vagy profi a fentiek közül jónéhányban, bele fogsz fulladni a projektbe.

Pont ezért szeretnék elmélyedni azokban, amiket javasoltok. Természetesen nem azt várom, hogy elsőre csúcssiker lesz és bárki megirigyelheti az eredményt.

Lehet hogy így kellett volna írnom a topik címét: nagyobb terheltségű weboldalról milyen cimkefelhő jut eszedbe?

Ok, akkor én a következőket ajánlom:

Azt a programozási nyelvet válaszd, amit jobban ismersz, ez a legfontosabb.
A php, java, c#, perl, python, puby stb. is tökéletesen alkalmas, neked az a legjobb amiben leginkább otthon vagy.
Ha egyiket sem ismered igazán, válaszd a phpt, azzal gyorsan fogsz haladni, és hamarabb találasz embert is.
Azzal együtt is ezt mondom, hogy nem szívem csücske.
Tanulmányozd Schlossnagle: PHP fejlesztés felsőfokon c. könyvét. Kissé régicske már, viszont azóta sem ismerek jobbat a nagy teljesítményú PHP portálokról.

Framework témában ua. Azt válaszd, amelyiket a legjobban ismered, ha nem ,akkor azt amihoz a legjobb támogatást találsz. Találtam én már több frameworkről szakdolgozatot magyar nyelven is a neten. Ja igen; a framework nem kötelező!

DB no igen, ez lesz az achilles-sarok, de megoldható. Ha hordozható SQL-t írsz illesztő minta szerint, vagy akár PDOval, akkor tudod a motort cserélni alatta később is, ha muszáj. Hogy ezt hogy kell csinálni... tippek pl a fenti könyvben, de leginkább a rutin.

XSLT a szívem csücske, de sajnos inkább lebeszéllek róla, mert nem találsz rá fejlesztőt, és néha akadhat a javascripttel, ugyanis az XSLT-s böngészőbugokat kevéssé javítgatják a gyártók sajna.
Inkább html, az xhtml-t nem fejleszti már tudtommal a 3WC.

Js framework igény szerint. Leginkább a jQuery-re találsz fejlesztőt.

És tessék hozzárakni azt is, hogy SQL. Első körben célszerűen az alapvető dolgok, lehetőleg RDBMS-től függetlenül, utána a finomságok, a kiválasztott adatbázishoz kapcsolódóan.
Nekem az Oracle picit szívemcsücske (hegesztettem webes alkalmazást pl/SQL-ben - toad rulez), úgyhogy abba az irányba indulnék, bár production-be tett cucc esetén egy webes alkalmazás alá csillió forintba kerül :-/

( profeta | 2010. 08. 21., szo – 16:59 )

Csatlakoznék az előttem szólóhoz ...
Sokan sok mindent elmondtak már, de szerintem is azt gondold végig, hogy ha nem tudod hogy kell csinálni, akkor pár jó tanács kevés lesz. Kell ide legalább egy hasonló (sikeres) projekt ismerete, meg kb. 10+ év iparági tapasztalat. Nem véletlenül van a projektekben architekt pozíció, és nem is kezdők szokták betölteni.
Mert ha nem tudod mi működik a gyakorlatban és hogy, akkor nagyon mellé lehet nyúlni. Mire kiderül, késő lesz.
Ha mégis muszáj belevágnod, akkor azt mondanám keress egy működő (teljes) megoldást, és másold le. Egy jól használható keretrendszer kialakítása a meglévő komponensek összecsiszolásával, még ha sikerül is, fél év minimum, és nem is biztos hogy jó lesz. A php pedig tényleg kevesebb bajt okozhat a skálázódás szintjén, de ezt az előttem szólók már kifejtették.
Amire nagyon oda kell figyelni az a DB skálázódás. Az elosztott adatbázis (amikor az egyes adatokat osztod szét gépekre) nem jó. Abban a pillanatban, amikor olyan lekérdezésre lesz szükséged, ami két különböző adatbázisból kapcsol össze adatokat, működésképtelen lesz az egész. Skálázódást ettől várni badarság.
Skálázódást (nagy vonalakban) háromféleképpen lehet elérni.
A legegyszerűbb ha sok pénz van rá, egy Oracle RAC. Drága a licence, + a hardver amit igényel, + be kell állítani, de transzparensen skálázódik. (azért partícionálást itt sem árt használni)
Kevesebb pénzből marad a replikáció. Ennek különböző fajtái vannak, attól függően, mennyire kell szinkronban lenni az egyes node-oknak. Általában akkor jó, ha sok az olvasás. Sok tranzakció estén nem segít. Rengetegféle megoldás létezik (nem is jó mind), ide is kell valaki aki ért hozzá.
Ha rengeteg az írás, (pl. a felhasználók összes kattintását tárolni kell), akkor jöhet valamilyen NOSQL-es megoldás. Ezek erre vannak kitalálva, de a lekérdezések lehetősége korlátozott, és nem ACID-ok, szóval számlavezetést pl. nem lehet alapozni rájuk.
De még egyszer hangsúlyoznám, ez is külön szakma.

Ismerj meg néhány nagyobb portálrendszert, fejlessz hozzájuk/bennük sokat - azaz szerezz sok tapasztalatot. Találd ki, hogy az egész projektben mit szeretnél csinálni, és gyúrj rá arra - ugyanis az, amit felvázoltál, az nem egy emberre méretezett dolog - hiába a jó ötlet, ha nem tudsz belőle a megfelelő időben terméket/produktumot csinálni, akkor hamvába holt az egész.

( sj | 2010. 08. 21., szo – 18:30 )

csak kivancsisagbol: mi lesz ez a projekt?

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Az eddigiek alapján nem hiszem hogy bármilyen információt ki fog adni erről a szerző. Pedig kb. 99.99% az esélye, hogy már elég sokan elgondolták ugyanazt az ötletet, jó eséllyel páran már meg is próbálták az implementációját. Eladni az ötletet nem lehet (van bárhol olyan piac, ahol ötletet adnak-vesznek?), a megvalósításon múlik az értéke. Gondolj egy millió dolláros ötletre, és hátha ugyanarra gondoltatok :)

Jól gondolja syntern, magát az alapötletet nem szeretném elmondani. Miért? Mert annyira egyszerű és frappáns, hogy aki igazán benne van a webes témakörben, az kb 2 hónap alatt megcsinálja a Teaser + Preview + Launch kombót.

Természetesen a megvalósítás kelti életre, de nem mindegy ki van helyzeti előnyben.

( Nickname | 2010. 08. 24., k – 12:54 )

http://zkoss.org

ha lenne olyan témájú projectem biztos ebben csinálnám. :) Db-nek postgres, template kütyü, MVC meg ilyesmi van benne, de cserélhető is. És a ma annyira divatos jquery-vel is barátságban van. Tudom, szeret sokat beszélgetni magával a hálózaton, de akkoris, szerintem igen impresszív, bár tény mélyvíz lehet java csekély java tudásssal és kis rutinnal.

( rumi v | 2010. 11. 05., p – 23:43 )

számomra is érdekes volt, köszi mindenkinek.

( ssikiss | 2010. 11. 06., szo – 01:04 )

Ha én most állnék neki valami nagyobbacska dolognak, akkor valószínűleg a Seam framework (java) lenne az alapja. Ha valamilyen elborult körülmény miatt a perl játszana, akkor meg a Catalyst web framework.

( aCidicE | 2010. 11. 06., szo – 09:18 )

sub o.O

if(you == understand.this){
          get.a.girlfriend;
}