A scala sau a nu scala – stocarea de date in cloud

Cum scalează marile siteuri de pe net? Google, Yahoo, Windows Live, Amazon etc, ce baze de date folosesc? Relaționale? Nope…

Când am anunțat platforma Azure în octombrie 2008, erau două moduri de a stoca date:

1. cel simplu, direct în Windows Azure ”tables”, după un model ierarhic și cu acces prin REST

Windows Azure

2. cel (mai)complex, prin SQL Services, după un model relațional, cu acces prin REST sau SOAP, dar având totuși asemănări minore cu bazele de date relaționale obișnuite (SQL Server, MySQL, Oracle sau DB2). Practic, era cam forțat să spunem ”relațional” fără suport T-SQL…

Se dorea pentru SQL Services, păstrarea eficienței în scalabilitate, adică prin adăugarea de fier ieftin, folosind mașini virtualizate pe rack-uri de blade-uri în datacentere modulare ca aici. Știm deja, de la grădiniță, că este foarte greu să scalezi eficient bazele de date relaționale, dacă nu impui restricții aplicațiilor.

Ca o paranteză, soluția cu big-ass iron a la IBM e nasoală din start, dar mai ales după ce vezi factura de mentenanță. Oracle RAC promite scalare eficientă însă îți piere cheful după ce te taxează pentru licențele de RAC și până la urmă ieși chiar mai scump decât cu big-ass iron.

Și atunci, ideea inițială la SQL Services era să impunem restricții aplicațiilor pentru a putea scala eficient. Totuși, feedbackul a fost din ce în ce mai puternic: ”vrem un SQL Server în nor, pentru a putea urca aplicații existente cu minim de efort”. Asta însemna să oferim facilitățile obișnuite din SQL Server, să scalăm dinamic la nivel de enterprise și să păstrăm, bineînțeles, promisiunile de disponibilitate, provizionare etc. Iar cei care vor să facă următorul Google, să folosească modelul ierarhic din Windows Azure (punctul 1).

Conform blogului SDS, se va întâmpla în acest an, printr-o schimbare majoră de macaz:

Tables?…Check
Stored Procedures?…Check
Triggers?…Check
Views?…Check
Indexes?…Check
Visual Studio Compatibility?…Check
ADO.Net Compatibility?…Check
ODBC Compatibility?…Check

Săptămâna viitoare este conferința MIX09, prilej pentru astfel de anunțuri.
E interesant și articolul lui David Chappell (care a anticipat un pic acest anunț, deh, are ”sursele” sale).

În concluzie, răspunsul la dilema din titlu ”a scala sau a nu scala”, este… da Smile

Filed under: SQL Server, Azure, Arhitectura

# re: A scala sau a nu scala – stocarea de date in cloud

Wednesday, March 11, 2009 5:59 PM by MrSmersh

No si sa mai zica careva ca nu asculta Smile

Inca 2-3 chestii  din astea mai trebuie si imi schimb parerea si o sa zic si ca e si acuma cea mai faina chestie de le inventie piinei feliate. Smile

# re: A scala sau a nu scala – stocarea de date in cloud

Wednesday, March 11, 2009 8:56 PM by ignatandrei

Daca intr-adevar o sa putem porta EF si L2S in cloud, o sa fie cea mai tare chestie din lumea intreaga …

# re: A scala sau a nu scala – stocarea de date in cloud

Thursday, March 12, 2009 2:20 AM by B_gd_n[ ]Sahlean

Eu aş paria că folosesc în primul rând SGBD-uri relaţionale …

# re: A scala sau a nu scala – stocarea de date in cloud

Thursday, March 12, 2009 8:30 AM by zoltanhe

Pe cât? Smile

# re: A scala sau a nu scala – stocarea de date in cloud

Thursday, March 12, 2009 3:55 PM by B_gd_n[ ]Sahlean

Cam doi cenţi.http://itboard.ro/emoticons/emotion-1.gif

Un exemplu:

http://hurvitz.org/blog/2008/06/linkedin-architecture

Pentru mine stocarea in cloud este o mare tâmpenie dpdv al modelului de date. Este un pas uriaş înapoi. O întoarcere la începuturile istoriei bazelor de date.

Scalabilitatea este o problema în primul rând de arhitectură şi … apoi de model de date. Practic, se încearcă transferarea efortului depus cu arhitectura aplicaţiei la un efort financiar (în primul rând): bani pentru hardware. Care este costul secundar ? O înapoiere teribilă dpdv al tehnologiei bazelor de date !

Poate că spun în continuare doar o prostie, dar cred că dacă MS ar fi luat SQL Server Compact Edition şi l-ar fi optimizat, le-ar fi dat peste nas celor de la Google şi Amazon cu aberaţiile lor legate de stocarea în nor.