MySQL segédprogramot tett nyílt forrásúvá a Facebook

Open Source

A Facebook nyílt forrásúvá tett egy segédprogramot, amelyet arra használnak, hogy éles MySQL szervereiken menet közben sémát változtassanak. A Facebook azzal a problémával szembesült, hogy éles rendszerein hosszú ideig futnak egyes MySQL műveletek, például az "ALTER TABLE".

A Facebook fogta a meglevő, BSD licences, openark kit-ben megtalálható oak-online-alter-table-t, portolta PHP-ra és az igényeinek megfelelően kiegészítette.

A H Open szerint a Facebook egyik fejlesztője azt nyilatkozta, hogy a segédprogram használatával sikerült a korábbi hat hónapról fél napra csökkenteni az összes rendszerük sémaváltására fordított időt.

Az Online Schema Change-ről (OSC) bővebben itt.

( Dacr (nem ellenőrzött) | 2010. 09. 23., cs – 15:53 )

Tyűha. Köszönjük a kódot!

:) Amugy meg tudom erteni, en sem orulnek, ha a munkamat csak ugy "lenyuljak" egy closed source software-be is akar, az mindig maradjon csak open. Pont ezert szamomra a GPL "szabadabb" licenc mint a BSDL, mert a szabasag alatt en azt ertem, hogy az eredeti (na meg a hozzajarulok fejlesztok) szabadsaga, nem egy XYZ cege, aki aztan abbol kreal valamit, es megtartja maganak "a hasznot" (itt most nem penzre gondolok, hanem a hozzaadott ertekrol, ami azonban feltetelezi az eredeti megletet, ami pl az en munkam erdeme). Dehat ez izles kerdese, tudom, mas a szabadsag alatt az emlitett XYZ ceg, mint "felhasznalo" szabadsagat erti, hogy o megteheti azt, amit :) Ja, es ez most altalanossagban, XYZ nem feltetlenul Facebook, sot ok ki is adtak, annak ellenere, hogy nem lettek volna ra kotelezve, thanks.

Ez igy van, csak elgondolkoztam a dolgon, ahogy a cikkben emlitett szerzo is, nem feltetlen _csak_ a konkret ugy kapcsan, amirol itt szo volt. Amugy ez erdekes problemat vet fel: tfh, a jovoben hodit a "cloud computing" meg ilyesmi, es kvazi szinte minden webes/netes/stb lesz. Akkor nem igazan lesz "terjesztve" semmi a koznapi ertelemben, hiszen halozaton at vesszuk igenybe a szolgaltatasait egy adott sw-nek. Azonban ha ezek szama no, es egyre tobb ilyen lesz, akkor egyre problemasabba valhat az az alkepzeles, amit nehany sw licenc kinal, hogy "terjesztese" eseten ez-meg-az van, hiszen semmi nem lesz terjesztve igazan. Akkor viszont kisse elveszti az ertelmet ...

( petya | 2010. 09. 23., cs – 16:54 )

Nem ertem, hogy milyen elonye van ennek a slave promotalos megoldashoz kepest. Nyilvan a fast index creation akkor is mukodik, igy pedig plusz limitaciokat es nagyobb lockokat hozol be.

Tehat ez azert jo, mert egy kiforrottabb valami funkcioinak egy reszet kivaltja, es jobban bizunk egy kevesbe kiforrott dologban, mint a regebben jelen levoben? Ne erts felre, ismerem az MMM-et, hasznalom is, az MMM 1.x egy dirty hack, a 2.x mar tisztabb. Azt gondolom, hogyha a facebooknal ebbe enegergiat tettek van valami elonye, amit nem latok mi. Egyebkent ilyen failovert nem csak framework-kel lehet csinalni, linux-ha-ban is van mar olyan agent, ami ezt oldja meg.

( Tyra3l | 2010. 09. 23., cs – 17:35 )

erdemes lehet tudni, hogy a triggerek nem sulnek el az idegen kulcsok kaszkadolasa miatti valtozasokra (de a row, vagy mixed tipusu replikacional bele kerulnek a binlogba, szoval ez ott nem feltetlen para), ezert a Facebooknak bemutatott modszer inkonzisztenciat okozhat ha idegenkulcsokkal modositunk adatot az online schemamodositas kozben.

Tyrael

Valahol volt szó arról, hogy az FB-nél inkább szétszedik a DB-t (vagy akár táblákat) több gépre és a felsőbb rétegekben (PHP, Java, C++) oldják meg a JOIN-okat és hasonlókat. Gondolom, ebből kifolyólag a konzisztencia annyira náluk nem játszik, már csak azért is, mert inkább 1x beírnak valamit, utána meg olvassák. Néha meg törlik.

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

Es nagyon jol is teszed. Peldaul php/ruby/webszerver/akarmilyen klienst "konnyebb load balanceolni", ha meg sql szervered "totyog", annak tobb helyen lesz hatasa. Amit en tanultam az az, hogy ahol csak lehet nem joinolunk es a leheto legkisebb/legegyszerubb vagy legkevesebb sql lekerdezest kell elerni sok konkurrens olvasas/iras eseten, de inkabb legyen 2 select, mint egy join, ami aztan lehet, hogy vegignyalaz ket nagy tablat. Raadasul mysql belso titkait nehezebb atlatni/kikutatni, kesobb emiatt atirni a kodot meg dupla(ha regen csinaltad akar tripla) munka.

"inkabb legyen 2 select, mint egy join"

Ezt hogy kell érteni? Én egy joint egy selecttel, aztán egy ciklussal, és abban annyi újabb selecttel tudnék helyettesíteni, ahány sort az első select kiválasztott. Vagy valami olyan algoritmussal ami összepasszintja nekem a kiválasztott táblák összetartozó értékeit. [Szerk: tehát query után] Viszont ez biztos hogy nem lesz jobb mint egy join. (Talán akkor ha direkt elrontom a joint...)

(hehe, joint)

felhasznalastol fugg, sok kliens buta lekereseit kiszolgalni valoban bottleneck.
viszont lehet olyan use-case, ahol keves kliens vegez bonyolult lekerdezeseket (reporting, bi, mittudomen), amiket nagysagrendileg tobb ido lenne applikaciobol rendezni/agregalni, es megis szukseg van az online schema modositasra.
de webre altalaban nem ez a jellemzo.

Tyrael

( uid_17626 | 2010. 09. 23., cs – 22:09 )

szerintem hiba volt, mert most lehet emiatt nem elérhető a site :)

( emre33 | 2010. 09. 23., cs – 22:14 )

6 hónap? Valahogy ezt nem tudom lhinni, ilyen nagy gyorsulást.

( current88 | 2010. 09. 23., cs – 22:27 )

Kösszönjük, remélem a mostani leállás nem tart ennyi ideig...