O soluție ar fi cu ajutorul lui SQL Azure Migration Wizard, acum în versiune alpha, publicat pe Codeplex sub licență Ms-PL.
……………
PS: De la începutul acestei luni, puteți obține codul de acces pentru Windows Azure pe loc. Fără timpi de așteptare.
Filed under: OSS, SQL Server, Windows Azure, SQL Azure
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
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 
Filed under: SQL Server, Azure, Arhitectura
Wednesday, March 11, 2009 5:59 PM by MrSmersh
No si sa mai zica careva ca nu asculta …
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.
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 …
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 …
Thursday, March 12, 2009 8:30 AM by zoltanhe
Pe cât?
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.
Discutam zilele trecute dacă cloud platforms au sens sau nu. Dacă reușim să valorificăm punctele de atracție ale norului (scalabilitate, cost redus etc), putem spune: de ce nu? S-ar putea să fie următoarea mare chestie. Gândiți-vă doar la apariția PC-ului și a serverului obișnuit pe vremea mainframe-urilor. Azi, avem tot felul de tehnologii interesante care apar: Google AppEngine, Amazon EC2, Force.com, SQL Server Data Services etc. Citiți părerea lui David Chappell în ”A Short Introduction to Cloud Platforms”. Noi vom vorbi mai multe la și după PDC2008, cînd vom avea povestea închegată.
Filed under: S+S
Monday, August 18, 2008 3:52 PM by B_gd_n[ ]Sahlean
La prezentarea de sâmbătă ai folosit intens termenul de [serviciu]. De asemenea ai amintit la un moment dat de combinarea serviciilor. Inteleg prin asta ochestrare serviciilor. Până la urmă este vorba 🙂 … [şi] … de SOA. Totuşi nu-mi amintesc să fii amintit cel puţin o dată de SOA.
Tot in prezentarea de sâmbătă ai subliniat faptul că IBM nu are prezenta la nivel de „cloud platforms”. Explicaţia ar putea veni din faptul că IBM se simte foarte bine/e poziţionată ft. bine pe segmentul de SOA „premises”.
SOA „in the cloud” ar putea fi următorul nivel din SOA (adică după SOA „premises”).
Tuesday, August 19, 2008 11:19 AM by zoltanhe
Mda. În contextul ăsta (simplist), SOA înseamnă compoziția serviciilor, adică modul în care compui serviciile cu scopul de a le refolosi (intern). Dacă luăm în calcul și servicii în nor, atunci SOA se extinde și în afara firmei. Chiar și așa, trebuie să ne reamintim mereu pentru ce a fost introdus conceptul de SOA și anume pentru a face business-ul mai agil și mai eficient.
Unii spun că SOA e despre servicii ”on premises” și SaaS e despre servicii în nor. Totuși, eu consider că SaaS este doar o modalitate de livrare (dpdv business) a serviciilor din nor.
Tuesday, August 19, 2008 12:26 PM by B_gd_n[ ]Sahlean
SOA este mai mult decât compunerea si reutilizarea serviciilor. SOA nu restricţionează serviciile la nivel „intern”. Spun asta deoarece serviciile trebuie sa „poată” fi descoperite („service discoverability”) pentru a putea fi consumate. Indirect, asta presupune faptul că serviciile pot să fie consumate şi extern. Asta dacă se doreşte …
Agilitatea este doar un aspect al SOA. Celalantă (poate chiar prima) promisiune ar fi integrarea sistemelor informatice existente (la nivelul unei întreprinderi … şi nu numai). Să nu uitam exemplul clasic din SOA în care o bancă dispune de un sistem informatic pentru conturi care stochează anumite date despre clienţi, are un sistem informatic pentru carduri care stochează alte informaţii despre clienţi şi un sistem informatic care gestionează creditele acordate clienţilor (binenţeles, sistem care memorează anumite date despre clienţi). SOA promite integrarea acestora şi oferirea unei singure viziuni despre un client. Teorie …
Tuesday, August 19, 2008 12:54 PM by zoltanhe
Integrarea este implicită. Așa este. Dacă nici integrare nu faci, atunci rămâi doar cu silozuri. Totuși, integrarea nu este suficientă (e doar EAI), pentru SOA trebuie să am și refolosirea serviciilor.
Tuesday, August 19, 2008 1:09 PM by B_gd_n[ ]Sahlean
Hmmm … Discutabil. Ce ar putea să mă împiedice să dezvolt de la zero un sistem care „are şi o arhitectură SOA” fără să integrez ?
Tuesday, August 19, 2008 1:30 PM by zoltanhe
Nu prea are sens. Dar, dacă ești (un) SAP (shop) și totul se învârte în jurul tău, atunci ești în barca aia în care nu îți pui problema de integrare (fiindcă ești deja integrat) ci de expunerea serviciilor și refolosirea lor.
Tuesday, August 19, 2008 3:14 PM by B_gd_n[ ]Sahlean
🙂 De ce nu ? Te citez: „.. SOA și anume pentru a face business-ul mai agil … „. Dacă aş fi furnizorul X de floricele (pop-corn) :-() poată că doresc să ofer clienţilor posibilitatea să acceseze stocurile (~), să-mi trimită comenzi … Toate astea prin intermediul unor servicii pe care clienţii să le consume la nivelul sistemelor informatice proprii. Simplific astfel interacţiunea cu aceşti clienţi.
Iar integrarea (din păcate ideea nu-mi aparţine) nu s-ar putea realiza mult mai simplu prin conectarea directă la bază/ele de date ale celuilant sistem informatic ?
Tuesday, August 19, 2008 9:47 PM by zoltanhe
Sunt de acord cu prima idee, deşi integrarea este doar la un (mic) pas. E păcat să ai serviciile şi să nu beneficiezi la maxim de ele.
Integrarea la nivelul bazelor de date este ok, însă implică o dependenţă de celelalte servicii, şi asta este contrară ideii de SOA, care (ştim de la grădiniţă) are la bază loose-coupling.
SSDS e… big! Aşa cum Biztalk Services este (va fi) Internet Service Bus (ESB în nor), aşa SSDS va fi un store de date structurate în nor accesibil prin Sync Framework, ADO.NET Data Services Framework (aka Astoria) sau REST.
Cristi zice că „When I thought I know everything about SQL Server, I was hit” şi ne dă o listă barosană de resurse. Enjoy!
Filed under: SQL Server, S+S
Saturday, March 08, 2008 11:36 PM by Anonymous
Ca si o vizionare este http://channel9.msdn.com/showpost.aspx?postid=388698.
„database world.” 😀
Sunday, March 09, 2008 12:11 PM by MrSmersh
Si citit printre linii vestea mare de aici e ca Service Bus e mainstream, care tehnologic deschide o tona de directii pentru S+S in particular si in general pentru (WCF mai ales) web services.
Zoli Herczeg 
