SQL Azure Databases - Init

<body> <h1>SQL Azure Databases</h1> <p>Als ik een sessie doe over <a href="http://www.microsoft.com/windowsazure">Windows Azure</a>, dan komt daar ook <a href="http://www.microsoft.com/windowsazure/sqlazure/">SQL Azure</a> bij ter sprake. Bijna altijd komt er een opmerking over de maximale grootte van een SQL Azure database.</p> <p>Even een klein recap. Er zijn 2 edities van SQL Azure beschikbaar: Web en Business. Op dit moment heb ik nog geen verschillen tussen die twee kunnen ontdekken, maar wellicht gaat dat ooit nog komen. De Web editie is er alleen als 1 Gb en 5 Gb. De Business editie begint bij 10 Gb en eindigt bij 50 Gb, in stappen van 10 Gb. Vanaf december zal het maximum overigens liggen op 150 Gb (<a href="http://blogs.msdn.com/b/avkashchauhan/archive/2011/10/13/sql-azure-databases-will-be-expanded-3x-from-50-gb-to-150-gb-and-sql-azure-reporting-amp-sql-azure-data-sync-ctp.aspx">zie hier</a>). De kosten van een SQL Azure database worden op dag basis bepaald. Het is geen lastig rekenmodel.</p> <p>Op dit moment is het maximum van een SQL Azure database dus 50 Gb. Tijdens veel van mijn sessie hoor ik dan, dat mensen dat weinig vinden. In eerste instantie dacht ik dat ook, maar ik heb mijn menig bijgesteld.</p> <p>Mijn laatste grote (niet Windows Azure gerelateerde) opdracht was een project bij een overheidsinstelling. Bij dit project maakte we gebruik van SQL Server databases. De beheerders hadden daar geen probleem mee, maar wel met de groei. Met de groei van de databases zouden ook de storage vraag en de backup tijd toenemen. Op zichzelf niet zo erg, maar om hun SLA’s te kunnen halen moest de backup wel in een bepaalde tijd geklaard zijn. En voor een aantal fikse databases was dat lastig. Uiteindelijk zijn er schoningsscripts gebouwd en is er efficiënter met de databases omgegaan.</p> <p>En deze situatie geldt ook gewoon voor SQL Azure. We zullen weer efficienter met de databases om moeten gaan. Met wat we er in stoppen en wat we bewaren etc. Tenslotte zullen alle kosten gerelateerd moeten zijn aan een business case / behoefte. Als dat niet het geval is, dan zul je een oplossing moeten verzinnen.</p> <p>Tijdens mijn praatjes geef ik ook altijd aan, dat wij als developers in de afgelopen jaren nogal gemakzuchtig zijn geworden. Disks / CPU en memory kosten bijna geen drol en zijn er bijna in overvloed. We werden niet gedwongen om na te denken, zoals we in de begintijd met schaarste wel deden. Veel oudere ICT-ers kennen dit nog wel, toegangspadanalyses etc.</p> <p>Kijk dus goed naar wat je in de database wilt bewaren en opslaan. En kijk of er niet een ander wellicht goedkoper alternatief is. <a href="http://www.microsoft.com/windowsazure/features/storage/">Windows Azure storage</a> is erg efficient voor blobs etc. Windows Azure storage tables is erg efficient voor niet relationele data. Dus deze zaken hoef je niet in een SQL Azure database op te slaan.</p> <p>En als je dan toch iets in een SQL Azure database gaat opslaan, denk dan ook na over schoningstermijnen en schoningsscript. In <a href="http://blogs.msmvps.com/marcelmeijer/blog/2011/07/28/sql-azure-custom-logging-naar-windows-azure-table-storage/">mijn blogpost</a> van een aantal maanden geleden beschrijf ik een alternatief.</p> <p>Windows Azure en Cloud computing in zijn algemeenheid dwingen ons om kosten en daarmee vaak ook over efficiëntie na te denken. Dat is geen bedreiging dat is een kans! Je zou het nu ook al moeten doen.</p><img src="http://marcelmeijer.net/aggbug.aspx?PostID=4434" width="1" height="1"> </body>