ugrás a tartalomhoz

Ha MySpace -t vagy iWiW-et kellene készítened... hogyan csinalnad?

mcz · 2007. Júl. 5. (Cs), 20.28
Elég sokat foglalkozok mostanában adatbázis tervezéssel és egyik nap elgondolkodtam: Ha egy myspace vagy iwiw szerű alkalmazást kéne készítenetek akkor milyen fajta adatbázis modellt használnátok ? Egyáltalán milyen adatbázist ?

Vegyük az egyszerű példát mysql-ben: myisam, vagy innodb motort használnátok? Szükség van tranzakciókra egyáltalán?

A másik kérdés ami foglalkoztatott, az az hogy az emberek egymással való kapcsolatát miben tárolnátok ? Az rendben van egy létrehozhatunk neki egy xref adatbázis táblát, de amikor arra kerül a sor, hogy a legrövidebb utat megtaláljuk két ember között akkor (szerény tudásom szerint) egy gráfban való keresést kell végrehajtani valahogyan, ami igencsak sokszor fordul adatokhoz, így sok select lassú ... tehát célszerű lenne a kapcsolatokat (emberek egymással való kapcsolatát) valami más módon is tárolni nem?

mcz
‹ Baromi nagy segítség kellen! Adatbázis költöztetés. mysqld.sock fájl eltünt :-/ ›
 ■
1

Tárolt eljárás plusz gráfalgoritmusok

janoszen · 2007. Júl. 5. (Cs), 21.54
Két dolog van erre, amit javasolni tudok. Az egyik az, hogy használj tárolt eljárásokat és skálázást, mert az nagyon meggyorsítja a dolgot, a másik, hogy barátkozz meg a Bellman-Ford algoritmussal. Ha inkrementálisan építed föl az adatbázist, sokat tud segíteni mert előre földolgozod az adatokat, így szétterítve a terhelést.

Ami a skálázást illeti, ha egy mysql-en dolgozol, szinte biztos hogy előbb-utóbb korlátnak ütközöl, mert egy kép vagy egy master-slave cluster már nem tudja ellátni a dolgokat, kénytelen vagy egy több gépes, middleware támogatott adatrendszert létrehozni, értelmes részfeladatokra bontani a dolgot.
2

felmerülő kérdések

Hodicska Gergely · 2007. Júl. 5. (Cs), 22.23
hogy használj tárolt eljárásokat és skálázást, mert az nagyon meggyorsítja a dolgot
Ez nem túl konkrét tanács. Illetve a tárolt eljárás része az talán (bár nem hiszem, hogy ez jelentene óriási pluszt, bár adott esetben jelenthet), de a második fele az nem sok mindent jelent. Eleve fura, hisz "skálázás" mint konkrét megoldás nem nagyon van, ráadásul egy skálázható megoldás többnyire nem jelent önmagában teljesítmény növekedést, sőt, elég gyakran nem is a leggyorsabb.

hogy barátkozz meg a Bellman-Ford algoritmussal
Miért pont ezzel, hisz a Dijkstra gyorsabb, és egy iwiw esetén nincs szükség negatív élekre?

inkrementálisan építed föl az adatbázist
Mit értesz ez alatt?

Ami a skálázást illeti, ha egy mysql-en dolgozol, szinte biztos hogy előbb-utóbb korlátnak ütközöl, mert egy kép vagy egy master-slave cluster már nem tudja ellátni a dolgokat, kénytelen vagy egy több gépes, middleware támogatott adatrendszert létrehozni, értelmes részfeladatokra bontani a dolgot.
Ez itt szintén kicsit ködös fogalmazás, szerintem érdemes lehet jobban kifejtened a kérdezőnek.


Üdv,
Felhő
3

Bocs'

janoszen · 2007. Júl. 5. (Cs), 22.45
Bocs, kicsit fáradt vagyok, elírtam pár dolgot.

Szal első körben nem a Bellman-Fordról, hanem a Floydról van szó, ami az össze lehetséges pont között leképezi a távolságokat. Szal Dijkstra és Floyd, ebből lehet valamit elkezdeni.

Ami az inkrementális fölépítést illeti, ha tfh van egy halmaz, amelyben ismertek a távolságok, akkor egy új pont fölvétele nem nagy overhead, viszont meg kell nézni egy-egy új él hogyan változtatja meg az adatbázist... szóval ezzel lehet játszani, de minél több adatot célszerű adott esetben előre földolgozni.

Ami a mysql-t illeti, ha nem skálázhatóan építi föl a rendszert, max. master-slave elrendezéssel, mint ahogy a MySQL azt támogatja (replikációval), akkor egy idő után ki fog futni a dologból mert a szükséges írások mennyisége annyira sok lesz, hogy a master gép azt nem bírja.
4

mysql multi master

Hodicska Gergely · 2007. Júl. 5. (Cs), 23.04
Ami az inkrementális fölépítést illeti, ha tfh van egy halmaz, amelyben ismertek a távolságok, akkor egy új pont fölvétele nem nagy overhead, viszont meg kell nézni egy-egy új él hogyan változtatja meg az adatbázist... szóval ezzel lehet játszani, de minél több adatot célszerű adott esetben előre földolgozni.
Erről van esetleg valami linked? (per pillanat nem érint, de sose lehet tudni :))

max. master-slave elrendezéssel, mint ahogy a MySQL azt támogatja (replikációval),
Tudsz simán az alap replikációval is multi master cuccost összehozni. A szerverek körbe replikálnak: A->B->C->A. Mindegyik szerver külön szerverid-t kap. Be kell állítani, hogy a replikálásból érkező queryk is kerüljenek bele a binlogba, viszont emiatt fontos beállítani, hogy a saját serverid-jú query-ket figyelmen kívül hagyja. Eznekívül amire figyleni kell, hogy mindegyik gépen legyen eltérő autoincrement offset, illetve az autoincrement increment legyen nagyobb, mint a szerverek száma.


Üdv,
Felhő
5

Körbemegy

janoszen · 2007. Júl. 6. (P), 07.38
Nem tudok most linket az inkrementális fölépítésről, algoritmusok elméletén tanultunk ilyesmiket. A tényleges algoritmus attól függ, hogy konkrétan mit csinálsz, mert más adatok eltárolására van szükség. Ha megnézitek, a legrövidebb út az iWiWnél is problémát okoz sokszor. Konkrétan egy közösségi hálónál az a probléma, hogy közben is bármikor változhat a "gráf", szóval azt kell kitalálni, hogy egy új él bevezetésénél hogyan lehet minimális lekérdezéssel megállapítani a változásokat.

Ha mondjuk összekötök két új pontot, akkor az összes utat végig kell nézni (kényszerűen) de gyors lesz, mivel minden távolság ismert az új él két pontjáig. Innentől kezdve csak azt kell végignézni, hogy az új él lerövidíti-e az utat.

Persze ez megint bajos, mert exkluzív üzemmódban fusson és nem is biztos hogy megéri, mert az iWiW esetén szvsz gyakoribb az élmozgás mint a legrövidebb út lekérdezés. Ergo ott vagyunk, ahol voltunk, hogy esetenként kell eldönteni.

Ami a master-slave-et illeti, tudom hogy lehet multi-masteres rendszert csinálni, (nem tudom, mennyire stabil és mennyi erőforrást takarít meg) de amire utalni próbáltam, hogy szerintem szolgáltatás szervereket kell fölépíteni és azokat összekötni egy skálzható, nagy rendszernél ahelyett, hogy egy "vas" szolgál ki mindent. (Tehát pl. az iWiW-nél az emlegetett legrövidebb út egy szolgáltatás lenne.)
6

szolg szerv

mcz · 2007. Júl. 6. (P), 10.22
lighttpd + fastcgi + php app serverek + clusterezett mysql ? erre gondolsz ?

amugy gráfokkal kapcsolatban annyit, hogy algoritmus elméletből télleg volt szó erről a 3 algoritmusról, de lehet sokkal egyszerűbb ha egy külön program memóriába saját magának replikálja a kapcsolat táblát, és azon hamar egy dijkstra végigfut, ha szükség van egy legrövidebb út lekérdezésre. pl. boost c++ libraryban vannak jo gráf algoritmusok, asszem dijkstra is van közöttük.
7

multi master

Hodicska Gergely · 2007. Júl. 6. (P), 10.48
nem tudom, mennyire stabil és mennyi erőforrást takarít meg
A legnagyobb hazai free tárhely szolgáltató elfut vele.

de amire utalni próbáltam, hogy szerintem szolgáltatás szervereket kell fölépíteni és azokat összekötni egy skálzható, nagy rendszernél ahelyett, hogy egy "vas" szolgál ki mindent.
Egyrészt ez így nem egy vas, hanem pont egy skálázható megoldás, hisz bármikor új vasat tolhatsz be a rendszerbe. Másrészt igazad van, hogy érdemes külön pakolni amit csak lehet (csak nem mindig lehet), pl. session kezelés mehet külön, meg lehet találni dolgokat, amiket külön lehet tenni.

Tehát pl. az iWiW-nél az emlegetett legrövidebb út egy szolgáltatás lenne.
Ez így is van: http://files.meetup.com/408089/IWIW-NewTech-2007-07-04-Eloadas-2007-07-02-B-02.ppt (7. fólia).


Üdv,
Felhő
13

Csúcsterhelés

vbence · 2007. Júl. 7. (Szo), 14.02
Nagyon érdekes, hogy az 1600 dinamikus oldal / mp. számítási értelemben nem akkora wasistdas. Legalább is nekem nem tűnik annak. Amikor ma HD videókat konvertálunk stb... ezek csak textet kell generáljanak. :) Jó, hogy ott van 2.5 millió felhasználói rekord a háttérben, de ez biztos agyon van indexelve. A 300 millió kapcsoaltot sem úgy kell ám elképzelni, hogy minden kéréskor végignyálazzuk mind a sokmilliót.

Nem tudom, hogy melyik funkciók között oszlik meg az a bizonyos 1600 kérés. A legbonyolultabb biztosan a legrövidebb út funkció, ami a kapcsoaltok növekedésével már 90%ban 2 ember, tehát azt is gondolhatnám most kevesebb számítást igényel, mint hajdanán.

Lehet, hogy teljesen téves a benyomásom, de szerintem ha ezt a feladatot valakinek le kéne programozni, mondjuk C-ben úgy hogy adatkezelésre is a legalapabb algoritmusokat használja, amiket megvesz egy könyvesboltban, azt az 1600/mp -t. Egyetlen doboz meg tudná oldani mondjuk 90%ban. (Lehetnek oyan trükkös kérések, amik annyi számítást igényelnek, mint ezer másik, úgyhogy csak 90%-ot mondok).

Érdekes lenne kiszámolni, hogy a különböző absztrakciók milyen árat is képviselnek overhead szempontjából. Mikor éri meg a kevesebb programozói órát és tapasztalatot gépek tucatjaival pótolni?
15

hát ja

Hodicska Gergely · 2007. Júl. 7. (Szo), 19.21
Nekem is úgy tűni, hogy ott alapjában vannak dolgok elszúrva, amiket már nehezen tudnak utólag kiváltani. Persze látatlanban nehéz bármit is mondani. Azért az 1600/s-et túlzásnak érzem, meg hát nagyon nem mindegy, hogy milyen adatigénye van egy oldalnak. A DB/memcache az C-ből is ugyanolyan lassú lesz. Az se mindegy, hogy megenged-e, hogy akárcsak egy rövid ideig megenged-e, hogy ne a tényleges adatoknak megfelelő állapotot mutasd az oldalon. Pl. egy híroldalnál drasztikus különbség lehet, ha mondjuk csak percenként frissíti a címoldalát. De adott esetben egy 2 sec-es cache is jelentheti az alkalmazás stabil futását csúcsidőben.


Üdv,
Felhő
8

bevallom :D

TIV · 2007. Júl. 6. (P), 18.18
üdv.

bevallom nem sok mindent értettem az előző beszélgetéseitekből, de lenne egy kérdésem.
Miért jsp-t használnak iwiwnél, miért nem pl php-t vagy akármi mást szerintetek? gráfok miatt?
Köszönöm
9

JSP

janoszen · 2007. Júl. 6. (P), 23.55
Őszintén megmondom: nem tudom. Talán azért, mert a PHP alapvetően arra készült, hogy egy webszerveren futkorásszon, valószínűleg soha senki nem gondolta volna hogy valaki ilyen léptékű, több gépesre skálázott rendszer alapjául akarja használni. A JSP/Java meg jön egy csomó alap osztállyal, többek között kommunikációra is, SOAP-ra is, stb. úgyhogy valamivel jobb táptalaj erre... Ennek ellenére hallottam elég sok olyan (szak)véleményt, hogy az iWiW alapjaiban van elrontva, nem megfelelően skálázható. Nyilván senki nem gondolt rá, hogy _ekkora_ sikere lesz.
10

iwiw

Fraki · 2007. Júl. 7. (Szo), 03.57
Ennek ellenére hallottam elég sok olyan (szak)véleményt hogy az iWiW alapjaiban van elrontva


Hát, ehhez még csak szakvélemény se kell, elég böngészni... rettenetesen gyengélkedik. Ha csak azt nézzük is, mit szenvednek az összevissza kibe-kapcsolt ajaxos lapozással...
11

share nothing

Hodicska Gergely · 2007. Júl. 7. (Szo), 09.50
TIV: szerintem ehhez értettek, ennyi. Itt elég sokszor elhangzik több embertől, hogy mindig a megfelelő eszközt kell használni adott feladatra, csak hát többségünk nem ismer profin túl sok eszközt, így azért a választás nagyon ritkán/nagyon indokolt esetben fog mondjuk egy új nyelvre esni. A Virgo meg ahogy én tudom csinált különböző banki rendszereket is (talán Budapest Bank rémlik), az is java volt, ebben vannak otthon.

mert a PHP alapvetően arra készült, hogy egy webszerveren futkorásszon
Kifejezetten erre alkalmas, keress rá a share nothing kifejezásre. Rasmusnak is volt nagyon jó előadása ebben a témában.

Ennek ellenére hallottam elég sok olyan (szak)véleményt, hogy az iWiW alapjaiban van elrontva, nem megfelelően skálázható.
Hát az könnyen lehet, csak lassan ideje lenne nekik rendbe tenni a dolgokat. Amit pl. nem értek, hogy hogyan sikerül nekik a képeket lassan kiszolgálni, mert ahhoz tényleg nem kell akkora művászet.


Üdv,
Felhő
12

pdf?

lacy · 2007. Júl. 7. (Szo), 13.24
Csöv..Gergő nagyon tetszik ez a pdf (az iwiwet bemutató), honnan van? amúgy én sem értem a képes dolgot, hisz ahhoz csak sáv kell elvileg, mivel ha jól láttam a thumbnail készítésre külön vannak szervereik. kíváncsi lennék amúgy a szerverek számára is, mihez mennyi kell és milyen hardware van alattuk :D

ui: a 900Mbit/s pedig még LANban sem kutya :D:D
uui: Tudja vki, hogy a belföldi ingyenes szolgáltatók közül melyiknek van a legnagyobb sávja külföld felé? Csak úgy érdekel...fizetősek közül a tox.hu 1gbps nyom külföld felé, legalábbis azt állítják...csak nem túl friss phpvel mysql-el kínálják.
14

pdf

Hodicska Gergely · 2007. Júl. 7. (Szo), 19.00
Van ez a meetup.com (1-2 hete akadtam rá véletlenül), és van egy csoportosulása Budapesten is. Ahogy néztem kb. havi összjövetelek vannak néhány előadüval. A mostani pont nem jött össze, de mint kiderült utólag, 5 perces előadások vannak, aminek fényében nem teljesen tiszta, hogy mi is itt a cél. 5 percben kb. a problémát alig lehet vázolni, nemhogy a megoldást. No mindegy, itt volt most szó az iwiwról is, innen a pdf. A szerverek száma amúgy benne is van.

ui: a 900Mbit/s pedig még LANban sem kutya :D:D
100GB-es hálón már alig látszik. :)

uui: Tudja vki, hogy a belföldi ingyenes szolgáltatók közül melyiknek van a legnagyobb sávja külföld felé? Csak úgy érdekel...fizetősek közül a tox.hu 1gbps nyom külföld felé, legalábbis azt állítják...
Extrásokat kérdezd meg. Nekik lehet a legnagyobb, de nem tudom, hogy van-e valami fajta mesterséges korlátozásuk.


Üdv,
Felhő
16

iwiw előadás

gonoszcsiga · 2007. Júl. 7. (Szo), 21.45
azoknak akik még nem látták itt egy videó+pdf az iwiw-ről.
17

Thumbnail generálás

saxus · 2007. Júl. 9. (H), 19.57
Ahogy eddig észrevettem nem a képek kiszolgálása a legvészesebb, hanem a thumbnail generálás tart nagyon sokáig. (Rendes méretű kép időnként hamarabb lejön, mint a thumbnail).

Másik kedvencem, hogy sokszor nem is magára az iwiwre kell várni, hanem az audit.median.hu -ra.
18

Median

Max Logan · 2007. Júl. 9. (H), 20.46
Ezért van nekem az adblock plusz-ban egy ilyen szűrési feltételem:

http://audit.median.hu/*

De ettől függetlenül soxor olyan van, hogy katt egy gombra, várakozás. Katt még1x a gombra és bejön az adott menüpontnak megfelelő tartalom. Szóval maga az iWiW is katasztrófálisan lassú tud lenni.
19

hosts

Wabbitseason · 2007. Júl. 10. (K), 10.41
Hasznos tud még lenni, ha az ember ilyesmiket írogat a hosts fájljába, hogy:
127.0.0.1 audit.median.hu
meg
127.0.0.1 sher.index.hu
és bizonyos kellemetlen dolgok igencsak meggyorsulnak.