A Twitter nyílt forrásúvá tette saját igényeit kielégítő MySQL fejlesztéseit

MySQL, MariaDB

A Twitter az egyik legnagyobb MySQL felhasználó. Állandó adatainak túlnyomó többségét MySQL-ben tárolja. Ilyen adatok például a felhasználói beállítások, idővonalak és maguk a tweet-ek. A Twitter a legtöbb vállalathoz képest komolyabb szinten használja a MySQL-t, éppen ezért, ahol azt szükségesnek érezték kiegészítették, átdolgozták.

Könnyen megtehették, hiszen a MySQL open source (vagy újabban: "open core") szoftver. Mivel a Twitter-nél hisznek a tudásmegosztásban és abban, hogy a nyílt forrás előmozdítja az innovációt, úgy döntöttek, hogy az általuk végzett MySQL fejlesztéseket közzéteszik a GitHub-on egyszerűsített (2 cikkelyes) BSDL alatt. A Twitter által végzett változtatások közt megtalálhatjuk például a MySQL SSD tárolókkal rendelkező gépekre való optimalizálását, vagy éppen a memóriaallokáció optimalizálását nagy NUMA rendszereken.

Részletek a bejelentésben.

( turul16 v | 2012. 04. 10., k – 11:22 )

"SSD tárolókkal rendelkező gépekre való optimalizálását" - ez itt is az optimalizacio kikapcsolasat jelenti ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( nevergone v | 2012. 04. 10., k – 11:32 )

Én úgy tudtam, hogy valamelyik NoSQL rendszert használják.
Viszont ha már Twitter a téma, egy kérdés: Hogyan lehetséges a Twitterből a régi (több éves) üzeneteket kinyerni?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Csak sajnos nagyon sok pelda mutatja, h MySQL eseteben meg egy a fejlesztok altal meghatarozott metodus szerint vegrehajtott restart folyamatnal meg a lotto otosnek is sokkal jobbak az eselyei, mint db crash elkerulesenek. Lehet akarmilyen faszan skalazhato termek ha nem elegge megbizhato. Mert az, h elveszik egy twitter uzenet, vagy egy talalat egy google cache-bol, kit erdekel.

---
pontscho / fresh!mindworkz

( log69 | 2012. 04. 10., k – 11:51 )

A fenti open-core-os link-hez egy másik link (az utolsó hozzászólásból) itt, ez is érdekes.

( csababoro | 2012. 04. 11., sze – 00:17 )

Egy Twitter oldalnak tökéletes vagy akár a Facebook számára. Szerintem akkor van gond, hogyha 8 processzor felett tranzakció műveleteket kell végrehajtani, mert akkor tesztek szerint lassabb egy PostgreSQL adatbázisnál. Egy Twitter számára 10 képzett programozó fizetése nevetséges összeg.
Szerintem MySQL konkurense a PostgreSQL, de csak a tranzakciós környezetben, de egyre jobban fejlődik ott is.

Ja, twitter meg facebook meg google es a MySQL jo nekik sztorikkal csak annyi a gond, hogy nagyon mashogy hasznaljak ezek a cegek a MySQL-t, mint ahogy altalaban egy relacios adatbaziskezelot szokas.

"Egy Twitter számára 10 képzett programozó fizetése nevetséges összeg. "

Egyaltalan lehet mar tudni, hogy mibol kivanja fenntartani magat a twitter?

----------------
Lvl86 Troll - Think Wishfully™

Pl. nem mint relációs adatbázis használják, hanem szanaszét particionálva csillió darabra a táblákat és magasabb szinten, PHP/Java/C++ szintjén oldják meg mindazt, amit pl. "átlag" méretben egy szimpla JOIN -nal oldasz meg.

Gyakorlatilag mint egy buta tárolómotor.

----------------
Lvl86 Troll - Think Wishfully™

Ha jol tudom, a twitter nagy resze Rubyban van irva, es jo eselye van annak, hogy a ket meglevo ORM megoldas egyiket hasznaljak (ActiveRecord vagy DataMapper). Mindket megoldas gazdagon operal JOIN-okkal ha arrol van szo.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A twittert nem tudom, ezt az infot a Facebookrol olvastam. Mindenesetre a relacios adatbaziskezeloket nem arra terveztek, hogy ekkora meretekre felskalazodjon.

(ORM meg eleve broaf, nem ertem, hogy barki is komolyan gondolja azt a zsakutcat.)

----------------
Lvl86 Troll - Think Wishfully™

Miert lenne zsakutca? Az, hogy jelenleg relacios adatbazisokat hasznalnak hozza, az azert van, mert egyaltalan nincs a piacon olyan adatbaziskezelo, ami jo hatekonysagu lenne, jol tamogatott, igy erdemes lenne hasznalni objektumok tarolasara. Olvasom hogy kinlodnak a mongodb-vel, probaljak eletre kelteni a redis-t, de mindnek van valami apro pici nyugje, ami miatt megsem tud _igazan_ elterjedtte valni. A relacios adatbaziskezelok meg legalabb mukodnek.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Mert nem skalazodik, azert zsakutca egy ido utan. 100000 gepre nem fogsz te jol felskalazni relacios adatbazist ugy, hogy mellete konzisztens is maradjon az adat es gyors is legyen.

Sajat tapasztalatom az, hogy egy rendszer valamely parameterenek 2-3 nagysagrendbeli caltozasakor valtozik az alkalmazhato es/vagy hatekony modszer.

Szerk: bocs, nem emlekeztem teljesen jol, hogy mire is valaszoltal: az ORM-mel az a problemam, hogy alapvetoen megprobalja ugy reprezentalni a relacios adatbazisban tarolt adatokat, amely ilyen formaban ("objektumok") sosem volt es nem is igazan osszeparosithato fogalom. Bele lehet eroszakolni abba, hogy az objektum egy tabla egy rekordja, de ez nem igaz. Masik: egy select query sem egy objektumhalmazt ad vissza, hanem egy kerdesre a valaszt.

----------------
Lvl86 Troll - Think Wishfully™

Most megis mennyivel jobb az, hogy lekerdezed az adatokat mondjuk hashmapek egy tombjebe, es utana az oszlop nevet, mint kulcsot hasznalva ered el az adatokat egy soron belul? Mert 99%-ban igy dolgoznak a relacios adatbazisokkal. Innen mar csak egy lepes az, hogy ne hashmapbe, hanem objektumba toltsd bele a lekerdezes eredmenyeit.
Mas: a select query valoban egy kerdesre ad valaszt, de a legtobben nem azt szoktuk megkerdezni tole, hogy mennyi 2*2 mert erre egyreszt felesleges relacios adatbazist hasznalni, masresz iszonyu lassu es koltseges is.
Altalaban olyan adataink vannak, amik valamihez kapcsolhatok. Ha a tabla egy sora nem is egy objektum, altalaban egy entitas, amit mindenkeppen egy egysegkent kell kezelni. Az ORM-ek csak annyit adnak ehhez hozza (amennyire en ertem), hogy mint objektumot, konnyebben tudod kezelni a visszakapott adatokat. De ez teljesen rajtad al, kezelheted hashmappel is, sot indexelheted a cellakat numerikusan is, mert a legtobb megoldas erre is ad lehetoseget.

Ahogy en latom, az ORM csak egy absztrakcioja az adatkezelesnek, es a legtobb fejleszto ha nem hasznal ORM-et, akkor bizonyos szempontbol ir maganak egyet. Mert az megintcsak koltseges, hogy cellankent olvassuk ki az adatokat.

Persze, az ORM-nek megvan az a hatranya, hogy a legtobb megoldas ugymond felesleges adatokat is eloszed, amiket valojaban sosem hasznalsz fel. Viszont epp itt van a szepsege is a dolognak: ha ugyanis okos ORM-ed van, akkor a lekerdezesek eredmenyet cacheli, igy legkozelebb, amikor egy mas kontextusban kered le az objektumot, es mas tulajdonsagait fogod felhasznalni, akkor mar nem is kap hitet a DB.

Nyilvan felhasznalasi modja valogatja, hogy hol erdemes ORM-et hasznalni. Ott ahol a lekerdezesek eredmenyei nem lesznek entitasok, vagy bonyolultabb szamitasok eredmenyei jonnek vissza, ott celszeru lehet a "normal" relacios megkozelites. De sok esetben irto sokat hasznal az ORM.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az ORM inkabb kenyelmi irany (SQL helyett sima objektumokkal dolgozhasson a programozo), mintsem hatekonysagbeli. Hatekonyabb nyilvan nem lesz attol a plusz retegtol (ill. nem trivialis megoldani, hogy az legyen), de kenyelmesebb meg lehet. Ilyen modon nem zsakutca, performanciaban persze lehet.

--
In truly successful relationships...
no one wears the pants.