ugrás a tartalomhoz

SQL Databases Don't Scale

yaanno · 2009. Júl. 10. (P), 18.59
Érdemes észben tartani
 ■
1

Vajon

deejayy · 2009. Júl. 11. (Szo), 09.45
Vajon a cikkíró hallott már az Oracle-ről, vagy esetleg kikötötte a cikkben, hogy "azon kívül" ?
2

Nem derül ki

yaanno · 2009. Júl. 11. (Szo), 10.10
Bár én azt valószínűsítem, hogy amit állít az az, hogy en bloc az SQL nem skálázható.

Mellékszál, de a kérdésedből mintha az derülne ki, hogy webalkalmazások skálázáshoz Oracle terméket kell venni és már kész is vagyunk. Így van-e?
8

Nem, én azt mondanám, hogy

deejayy · 2009. Júl. 16. (Cs), 10.15
Nem, én azt mondanám, hogy "SQL Databases do scale!", csak meg kell válogatni az eszközöket hozzá. Az Oracle rengeteg eszközt biztosít ennek elérésére.
3

Nem tudom...szerintem a

virág · 2009. Júl. 13. (H), 08.13
Nem tudom...szerintem a "cikk" írója nem túl bonyolult lélek, úgyis mondhatnám, hogy egyszerű mint a faék... Picit unom azt amikor valaki egy blogon belül, mondjuk 17 mondatban meg akarja mondani a tutit egy olyan témakörről amiről ezer oldalas könyvek szólnak és több 10 éves db buherátori tapasztalattal rendelkezők (pl. Celko) sem mernek örök érvényű kijelentéseket tenni. Szóval jót nevettem. :D
4

fekete-fehér

yaanno · 2009. Júl. 13. (H), 17.40
Valószínű, hogy a világ nem igazán fekete/fehér. Feltételezem, hogy végigolvastad a sokezer oldalas könyveket és ennek alapján gondolod azt, hogy a linkelt post jó vicc.

Arra kíváncsi lennék, hogy ha mindezt 1000 oldalas könyvben írta volna meg, számítana-e valamit az illető véleménye; meg arra is, hogy ahol életbevágó a db skálázás (facebook, yahoo, google), miért nem SQL-t használnak. Ezek nyilván extrém esetek, de azért érdekesek, nem? No és ha az SQL egy belső tulajdonsága, hogy ilyen szempontból merev, akkor sem dől össze a világ, attól még pont jó lehet a legtöbb webalkalmazáshoz.
5

facebook, yahoo, google

Hodicska Gergely · 2009. Júl. 13. (H), 22.13
Már miért nem használnának SQL-t ezek a cégek?
6

Lehet hogy kő alatt élek

yaanno · 2009. Júl. 14. (K), 10.42
De mintha hallottam volna, hogy Yahoo! -> Hadoop, Google -> BigTable, Facebook -> Cassandra. Emellett nyilván alkalmaznak nem elosztott, sql szervereket is, de mintha a fő irány nem ez lenne.
9

nem voltam kicsit

Hodicska Gergely · 2009. Aug. 5. (Sze), 01.59
Kicsit késői válasz, de elmúlt időszakban elég húzós időket éltünk/élünk. Van amire használnak nem relációs adatbázist, de rengeteg dologra igen. Ha megnézed pont pl. a google az aki elég sok olyan extrát adott a mysqlhez, ami nagy terhelésű site-ok esetén jól jön. Facebook pl. alapvetően MySQL-t használ a site-hoz, egyéb adatbányász dolgokhoz használ más cuccokat. Pl. érdekességképpen a a Memcache-ek datacenterek közötti replikálásához is MySQL-t használ (némi saját kiegészítéssel a binlogban tároltakat illetően). Illetve egy idézet: "Off the top of Jeremy's head, where does Yahoo! use MySQL? Sports, games, news, finance, mail, movies, abuse, classifieds, shopping, search, personals, blogs, message boards. It's probably easier now to ask where is Yahoo! not using MySQL."
7

Nem SQL probléma

vbence · 2009. Júl. 14. (K), 11.23
Tekintsünk el egy pillanatra a relációktól és kulcsoktól, és vegyük a legbutább adatszerkezetet ami el tudunk képzelni: adatblokkokat egy lemezen. A bejegyzés írója egy RAID5-tel példálózik, mint eszményi meggoldással. Ebben csak annyi tévedés van, hogy a raid a legrosszabbul skálázható adatszerkezet ami valaha is létezett. Ha összeraktál egy raidet, a lemezek száma nem változtatható, egy év elteltével nem dobjhatsz rá nagyobb vinyókat, de még csak ugyanolyanokat sem, amiket eredetileg használtál.

A raidet ilyenkor újra kell épteni. Én nem tudok olyan megoldásról, ami ezt transzparens módon (adatbiztonságot és működést folymamatosan megőrizve) megtenné.

Egyedül a drobo nevű képződményről tudok, ami eleget tenne ennek a triviális követelménynek. - Különböző méretű hotswap lemezekből építkező transzparensen működő tárterület. - Aminél még mindig fennáll a "single point of failure" veszélye, a tárolót működtető "fedélzeti számítógép" részéről.

Most - az eredeti problémára visszatérve - képzeljük el, hogy nem lemezekről van szó, hanem különálló szervergépekről. Akár P2P rendszerben, akár 2 koordinátor géppel (ugye egy az kevés). Nem lehetetlen feladat, de ha még egyszerű adattárolásra sem sikerült egy működő megoldást prezentálnunk (lealább is én ilyenről nem tudok), addig kár azon elmélkedni, hogy vajon az SQL-lel van-e a probléma.