mboost-dp1
Microsoft Corporation
Jeg er ret sikker på at ikke en eneste af mine kunder vil overveje at lægge deres data i skyen. Garantien for datasikkerhed er simpelthen ikke stor nok når man ikke selv har 100% kontrol over hvem der har adgang til ens fortrolige data.
For de firmaer som ikke har det store behov for at deres forretningshemmeligheder er 100% indenfor deres kontrol, så synes jeg dog at Microsoft's løsning lyder en en plausibel mulighed.
For de firmaer som ikke har det store behov for at deres forretningshemmeligheder er 100% indenfor deres kontrol, så synes jeg dog at Microsoft's løsning lyder en en plausibel mulighed.
#1
Mister MS Kunder på det?
Langt hen af vejen er jeg tilbøjelig til at give MS ret!
De vurderer en database i skyeen udfra de kriterier de bruger for traditionelle løsninger.
Det synes jeg ikke giver meget mening.
Hvis det er hvad de ønsker skal de kigge på IaaS ikke PaaS.
Mister MS Kunder på det?
Langt hen af vejen er jeg tilbøjelig til at give MS ret!
De vurderer en database i skyeen udfra de kriterier de bruger for traditionelle løsninger.
Det synes jeg ikke giver meget mening.
Hvis det er hvad de ønsker skal de kigge på IaaS ikke PaaS.
#1 og #3:
Det er fair nok, at I giver Rene (fra Microsoft) ret i at man ikke lige umiddelbart kan sammenligne sin egen hostede database med en database i skyen, men så stopper det imho også der. De enkelte punkter der kommer frem er sådan set valide nok. Nu nævner jeg bare lige nogle stykker, fordi jeg ikke gider metodisk at gå hele artiklen igennem for at finde alle punkter som jeg synes er relevante.
* Execution plan for udførte statements og index fragmentering
- Det er umuligt, at finde ud af hvor min database halter i performance i produktion hvis jeg ikke har adgang til det. Så kan det godt være, at Rene mener, at jeg kan bare købe flere resourcer og løse mine performance problemer på den måde, men det ville da være bedre hvis det nu kunne løses ved at omskrive min sql til at bruge left join eller lave eller rebuilde et index.
Mener I virkelig, at I hellere vil betale MS for mere CPU / hukommelse / båndbredde (alt efter hvad problemet er) i stedet for at fejlfinde og løse problemet?
* Backup
- Helt ærligt!.. SQL Azure, Windows Azure eller nogen som helst anden sky. Det er mit data. Hit med det når jeg siger det!
Der er en meget god teknisk forklaring i artiklen, men jeg synes faktisk, at argumenter er overflødige. Det er mit data. Jeg skal kunne tage en backup og restore den lokalt. Det må da være en menneskeret.
Fint nok, at I stoler på at MS vil holde Jeres data sikkert både fra nedbrud og tyveri, men mener I seriøst, at det er ok, at MS nægter, at I kan få en offline kopi?
Det er fair nok, at I giver Rene (fra Microsoft) ret i at man ikke lige umiddelbart kan sammenligne sin egen hostede database med en database i skyen, men så stopper det imho også der. De enkelte punkter der kommer frem er sådan set valide nok. Nu nævner jeg bare lige nogle stykker, fordi jeg ikke gider metodisk at gå hele artiklen igennem for at finde alle punkter som jeg synes er relevante.
* Execution plan for udførte statements og index fragmentering
- Det er umuligt, at finde ud af hvor min database halter i performance i produktion hvis jeg ikke har adgang til det. Så kan det godt være, at Rene mener, at jeg kan bare købe flere resourcer og løse mine performance problemer på den måde, men det ville da være bedre hvis det nu kunne løses ved at omskrive min sql til at bruge left join eller lave eller rebuilde et index.
Mener I virkelig, at I hellere vil betale MS for mere CPU / hukommelse / båndbredde (alt efter hvad problemet er) i stedet for at fejlfinde og løse problemet?
* Backup
- Helt ærligt!.. SQL Azure, Windows Azure eller nogen som helst anden sky. Det er mit data. Hit med det når jeg siger det!
Der er en meget god teknisk forklaring i artiklen, men jeg synes faktisk, at argumenter er overflødige. Det er mit data. Jeg skal kunne tage en backup og restore den lokalt. Det må da være en menneskeret.
Fint nok, at I stoler på at MS vil holde Jeres data sikkert både fra nedbrud og tyveri, men mener I seriøst, at det er ok, at MS nægter, at I kan få en offline kopi?
Karlkoder (4) skrev:
* Backup
- Helt ærligt!.. SQL Azure, Windows Azure eller nogen som helst anden sky. Det er mit data. Hit med det når jeg siger det!
Der er en meget god teknisk forklaring i artiklen, men jeg synes faktisk, at argumenter er overflødige. Det er mit data. Jeg skal kunne tage en backup og restore den lokalt. Det må da være en menneskeret.
Fint nok, at I stoler på at MS vil holde Jeres data sikkert både fra nedbrud og tyveri, men mener I seriøst, at det er ok, at MS nægter, at I kan få en offline kopi?
Øh.
SQL Azure tilbyder faktisk at man kan tage en lokal backup af sine data.
Kritikken går på at der ikke er en fancy backup GUI til det, men at det skal laves via SSIS (eller BCP).
Så måske skal der skrues lidt ned for paranoia niveauet.
Karlkoder (4) skrev:
* Execution plan for udførte statements og index fragmentering
- Det er umuligt, at finde ud af hvor min database halter i performance i produktion hvis jeg ikke har adgang til det. Så kan det godt være, at Rene mener, at jeg kan bare købe flere resourcer og løse mine performance problemer på den måde, men det ville da være bedre hvis det nu kunne løses ved at omskrive min sql til at bruge left join eller lave eller rebuilde et index.
Mener I virkelig, at I hellere vil betale MS for mere CPU / hukommelse / båndbredde (alt efter hvad problemet er) i stedet for at fejlfinde og løse problemet?
Der mangler alle de kendte database værktøjer.
Men de oplysninger de kendte database værktøjer leverer er ikke nødvendigvis brugbare i skyen.
Med en lokal database er et index en sure thing ved søgning i store data.
I skyen er det ikke sikkert at det er smart at bruge et index som fysisk skal hentes fra den anden side af jorden.
Enten skal MS lave nogle specielle sky tools som er 10x mere komplekse end de lokale tools og folk skal lære at bruge dem.
Eller så må folk opgive ideen om den slags optimeringer og stole på at sky softwaren laver noget fornuftigt.
Ligesom det efterhånden er gået af mode at studere assembler listing af den kode som compilerne genererer for at se om den er "optimal".
#7
Prosablandet for April har også et tema omkring cloud, og blandt andet Systime har forklaret deres argumenter for at bruge cloud.
http://www.prosa.dk/aktuelt/prosabladet/alle-numre...
Prosablandet for April har også et tema omkring cloud, og blandt andet Systime har forklaret deres argumenter for at bruge cloud.
http://www.prosa.dk/aktuelt/prosabladet/alle-numre...
arne_v (6) skrev:
Der mangler alle de kendte database værktøjer.
De kendte GUI værktøjer (til Oracle og MSSQL) har nu explain-plan funktionalitet.
Det SKAL en database have før man kan tage den seriøst.
arne_v #5 skrev:SQL Azure tilbyder faktisk at man kan tage en lokal backup af sine data.
Ikke en standard metode, den tilbyder du kan synce dine data vha Microsofts sync framework men det er en falsk sikkerhed i og med at du ikke kan sikre en konsistent backup, det er det samme som at dumpe tabeller en efter en uden at låse og uden at bruge transaktionsloggen efterfølgende til at sikre konsistens.
Derudover er jeg absolut ikke enig i din forklaring om index'er. Så længe ressourcerne for hver enkel SQL Azure instans er begrænset så vil indekser være meget relevante. At lave en søgning i et index er jo hurtigere end i en tabel, og nej de skal ikke hentes halvejs rundt om jorden det er forhåbentlig kun dine resultatsæts der skal hentes fra f.eks. Irland hvor MS har hostingcenter.
arne_v #3 skrev:De vurderer en database i skyeen udfra de kriterier de bruger for traditionelle løsninger.
Nej, vurderingen er udfra de problemer der oftes stødes på med DBMS. Og når man har købt SQL Server som Platform as a service må man også forvente at de vigtigste værktøjer til f.eks. performance troubleshooting er tilgængelige. Ydermere er det pinligt at en SLA ikke indeholder information om hvad man kan forvente af f.eks. IO/sec.
Disclaimer: Jeg arbejder for Miracle A/S ligesom en af dem der udtaler sig i artiklen
Space Hopper (9) skrev:arne_v (6) skrev:
Der mangler alle de kendte database værktøjer.
De kendte GUI værktøjer (til Oracle og MSSQL) har nu explain-plan funktionalitet.
Det SKAL en database have før man kan tage den seriøst.
Der findes nu en del der aldrig bruger grafiske værktøjer til deres database. f.eks. oracle folk der bruger sqlplus og ikke andet, så den argumentation holder ikke helt
Det er sket før at datacentre mister deres data. Microsoft var en af dem: http://gigaom.com/2009/10/10/when-cloud-fails-t-mo...
Såeh, nej jeg stoler ikke en skid på cloud backup - det er bedre med en lokal kopi, hvis vulkansk aske, jordskælv, brand, terror, pæst og dansk folkeparti ødelægger adgangen til din cloud data. Så kan du i det mindste komme videre, nu, end senere.
Såeh, nej jeg stoler ikke en skid på cloud backup - det er bedre med en lokal kopi, hvis vulkansk aske, jordskælv, brand, terror, pæst og dansk folkeparti ødelægger adgangen til din cloud data. Så kan du i det mindste komme videre, nu, end senere.
intellectdk (10) skrev:Ikke en standard metode, den tilbyder du kan synce dine data vha Microsofts sync framework men det er en falsk sikkerhed i og med at du ikke kan sikre en konsistent backup, det er det samme som at dumpe tabeller en efter en uden at låse og uden at bruge transaktionsloggen efterfølgende til at sikre konsistens.
De tilbyder SSIS og BCP.
En SQLServer DBA forventes at kunne jonglere med dem i søvne.
Men det er ikke en bruger venlig backup løsning. Det er mere tools til at brugerne kan udvikle en backup løsning. Gerne en konsistent backup.
MS er heller ikke tilfreds med nuværende status. Ifølge internettet er planen at levere database kloning i H1 og continious backup i H2.
intellectdk (10) skrev:Derudover er jeg absolut ikke enig i din forklaring om index'er. Så længe ressourcerne for hver enkel SQL Azure instans er begrænset så vil indekser være meget relevante. At lave en søgning i et index er jo hurtigere end i en tabel, og nej de skal ikke hentes halvejs rundt om jorden det er forhåbentlig kun dine resultatsæts der skal hentes fra f.eks. Irland hvor MS har hostingcenter.
intellectdk (10) skrev:Nej, vurderingen er udfra de problemer der oftes stødes på med DBMS. Og når man har købt SQL Server som Platform as a service må man også forvente at de vigtigste værktøjer til f.eks. performance troubleshooting er tilgængelige.
Hvor mange problemer med PaaS databaser er de stødt på?
Mit gæt: nul.
D.v.s. at de taler om de værktøjer de har brug for til at løse problemer med traditionelle databaser.
De antager bare at de samme værktøjer giver mening i PaaS sammenhæng.
Og det er jeg langtfra sikker på.
Nu har jeg ikke set en teknisk beskrivelse af SQL Azure arkitektur, men hvis vi antager at de laver den slags meget ligesom de andre XaaS providere gør så vil det være meget anderledes.
Med en SQLServer service og en separat datachunk service som håndterer XXX eller XXXX MB chunks of data. Principielt vil SQLServer service kunne køre i Europa, tabel data ligge i en datachunk i USA og index data ligge i en datachunk i Indien. Altså når man opretter databasen. 2 uger efter er index data flyttet til Australien, fordi der var brug for at flytte lidt rundt for at udnytte disk kapaciteten bedre.
Performance vil i høj grad afhænge hvor mange datachunks man skal bruge og hvorvidt de har været brugt fornylig.
Sekventiel scan af en 500 MB datachunk der er loadet i memory vil være hurtigere end at skulle have loadet en anden 500 MB datachunk et andet sted.
Jeg tror ikke at behovet for index vil forsvinde med skyen. Men performance optimering vil være totalt anderledes.
Og lad mig igen understrege at jeg ved ikke hvordan SQL Azure fungerer. Det er spekulation. Men det er mere velfunderet spekulation end at databaser i skyen vil fungere ligesom lokale databaser.
#mere backup
Men oprindelige bemærkning omkring backup var iøvrigt et svar til "men mener I seriøst, at det er ok, at MS nægter, at I kan få en offline kopi?".
SSIS og BCP er ikke toppen af backup, men de er gode nok til at man ikke kan sige at MS nægter brugerne adgang til deres data.
Men oprindelige bemærkning omkring backup var iøvrigt et svar til "men mener I seriøst, at det er ok, at MS nægter, at I kan få en offline kopi?".
SSIS og BCP er ikke toppen af backup, men de er gode nok til at man ikke kan sige at MS nægter brugerne adgang til deres data.
arne_v (13) skrev:De tilbyder SSIS og BCP.
En SQLServer DBA forventes at kunne jonglere med dem i søvne.
Men det er ikke en bruger venlig backup løsning. Det er mere tools til at brugerne kan udvikle en backup løsning. Gerne en konsistent backup.
MS er heller ikke tilfreds med nuværende status. Ifølge internettet er planen at levere database kloning i H1 og continious backup i H2.
Jeg kender skam udemærket SSIS (og bcp), at udvikle en metode til at lave en konsistent backup med SSIS vil kræve at du kører hele din backup i en transaktion eller lukker for adgangen til system. Hvis du kører det hele i en transaktion ønsker jeg dig held og lykke med ikke at falde for Azures hammer enten hvad angår brug af ressourcer eller tidsforbrug for en enkelt transaktion.
Jeg ved godt at Backup er på vej, men nu er artiklen en vurdering af SQL Azure som det ser ud idag.
arne_v (17) skrev:#cloud databaser
De skal iøvrigt være glade for at MS har implementeret en relations database med et SQL interface.
Google AppEngine data store tilbyder Python brugerne GQL og Java brugerne JDOQL.
Jeg er udmærket klar over at andre cloudprovidere tilbyder alternative storageløsninger hvilket der også er i Azure med blogstorage og Azura tables. Som sagt er kritikken møntet på at sælge SQL Server som en PaaS jeg synes du fjerner lidt fokus fra pointen i kritikken og begynder at snakke i øst og vest
arne_v (14) skrev:
Hvor mange problemer med PaaS databaser er de stødt på?
De er stødt på mange problemer med SQL Azure, f.eks. en inkonsistent opførsel når størrelsen på databasen rammer ens maksimum. Nogle gange kan man fylde mere data i, andre gange blokeres adgang til SQL Azure webinterfacet med en YSOD så man ikke kan opdatere sin database til en større. Og man kan ikke på andre måder frigøre plads på andre måder end at eksportere alt data og importere det igen.
arne_v (14) skrev:
Med en SQLServer service og en separat datachunk service som håndterer XXX eller XXXX MB chunks of data. Principielt vil SQLServer service kunne køre i Europa, tabel data ligge i en datachunk i USA og index data ligge i en datachunk i Indien. Altså når man opretter databasen. 2 uger efter er index data flyttet til Australien, fordi der var brug for at flytte lidt rundt for at udnytte disk kapaciteten bedre.
I SQL Azure bestemmer du selv hvor dine databaser ligger og du opretter dem i et specifikt hostingcenter (f.eks. irland som er det der er tættest på os). Her vil alle dine data ligge, og arkitekturmæssigt vil din primære instans ligge på lokale diske på en enkel "commodity" maskine i en container i irland. Derudover vil der være to replikerede sekundære instanser der ligger på andre commodity maskiner i samme hostingcenter i irland. Adgangen til dataene håndteres af en TDS proxy som sørger for at sende dine TDS pakker til den primære instans hvis den er oppe eller en af de sekundære hvis primære er gået ned.
Derudover er der en masse operationelle rutiner til at flytte dine instanser rundt mellem forskellige maskiner for at udjævne så alle fysiske maskiner i hostingcentret altid ligger på en acceptabel gennemsnits utilization (pt er den ifølge MS på under 50% på samtlige fysiske maskiner).
Så der er ikke så meget magi, det er basalt set replikering på tværs af 3 bokse med en proxy foran og en masse administrative rutiner til at håndtere at du ligger på en boks hvor der er spillerum samt der bliver spinnet en ny instans op af din database hvis den hardware en af replikaerne ligger på går ned.
Derfor skalerer du heller ikke uendeligt hvis du laver "unoder" på din database der bruger flere ressource end den "commodity" maskine din primære database ligger på er der ikke mere at give af, medmindre selvfølgelig microsoft overvåger dette og kan flytte din instans til en dedikeret fysisk boks hvor der ikke ligger andre databaser eller de evt. kan flytte dig til en større maskine.
arne_v (14) skrev:
Og lad mig igen understrege at jeg ved ikke hvordan SQL Azure fungerer. Det er spekulation. Men det er mere velfunderet spekulation end at databaser i skyen vil fungere ligesom lokale databaser.
Hvis du læser ovenstående vil jeg så håbe at du indser at dine spekulationer på det nuværende stadie med Azure ikke er helt i vinkel. Og selvom jeg ikke havde ovenstående viden kunne jeg godt fortælle dig generelt at cloud databaser ikke hænger sådan sammen. ACID properties og distribuerede systemer er MEGET svært at få til at spille sammen, og det er også derfor at vi ser de virkelig store spillere lader sig "nøjes" med eventual consistency som vi ser med f.eks. distribuerede key/value stores, kolonne orienterede databaser og MapReduce forespørgsel på data.
Godt læsestof i den sammenhæng er Brewers CAP Theorem som i folkemunde efterhånden er blevet til "Pick any two of Consistency, Availability eller Partition tolerance"
intellectdk (19) skrev:
.... hvilket der også er i Azure med blogstorage og Azura tables...
Staveplade.. Azure blobstorage og Azure tables that is
intellectdk (18) skrev:Jeg kender skam udemærket SSIS (og bcp),
Men du undload at nævne at de var til rådighed med Azure.
intellectdk (18) skrev:at udvikle en metode til at lave en konsistent backup med SSIS vil kræve at du kører hele din backup i en transaktion eller lukker for adgangen til system. Hvis du kører det hele i en transaktion ønsker jeg dig held og lykke med ikke at falde for Azures hammer enten hvad angår brug af ressourcer eller tidsforbrug for en enkelt transaktion.
Det må jo formentligt blive på den gammeldags måde med at blokere updates indtil MS leverer en bedre måde.
intellectdk (18) skrev:Jeg ved godt at Backup er på vej, men nu er artiklen en vurdering af SQL Azure som det ser ud idag.
Jo. Og hvis ens målsætning er at komme at skabe omtale for ens firma i pressen, så er der jo heller ikke nogen grund til at nævne hvilke problemer der er annonceret løsninger på. Men hvis man nu var interesseret i at give tilhørerne mulighed for reelt at vurdere Azure, så ville man nok netragte det som relevant.
intellectdk (19) skrev:Som sagt er kritikken møntet på at sælge SQL Server som en PaaS jeg synes du fjerner lidt fokus fra pointen i kritikken og begynder at snakke i øst og vest
Øh. MS sælger faktisk ikke SQL Server (TM) som PaaS. De sælger en SQL server (non capitalized) som PaaS. Som så er "built on SQL Server® technologies".
Tråden har vel haft lidt afstikkere. Men min pointe er at jeg (for en gang skyld) er helt enig med Rene Løhde.
De har slet ikke forstået hvad SQL Azure er eller hvad cloud database er.
SQL Azure leverer et SQL Server API for udviklerne med et helt andet management interface end SQL Server for DBA'erne.
Hvis det er en ægte cloud løsning, så gav det slet ikke mening at lave et traditionelt SQL Server management interface.
DBA'ere der skal igang med cloud databaser skal starte med et meget åbent sind. Nogle af de gode gamle regler gælder stadig, andre gælder kun i modificeret form og nogle gælder slet ikke.
At tage sin feature checkliste for en normal database og anvende den på en cloud database og konkludere at den ikke duer fordi der mangler en masse afslører kun at man ikke har forstået cloud.
(man kan så ikke konkludere at SQL Azure er klar til produktion - forfejlet kritik udelukker ikke at der er valid kritik)
intellectdk (20) skrev:De er stødt på mange problemer med SQL Azure, f.eks. en inkonsistent opførsel når størrelsen på databasen rammer ens maksimum. Nogle gange kan man fylde mere data i, andre gange blokeres adgang til SQL Azure webinterfacet med en YSOD så man ikke kan opdatere sin database til en større. Og man kan ikke på andre måder frigøre plads på andre måder end at eksportere alt data og importere det igen.
Nu spurgte jeg faktisk om hvor mange produktions databaser på Azure de havde optimeret på og havde savnet de værktøjer.
Det andet er naturligvis også interessant. Og giver helt klart et indtryk af version 1.0 problemer.
Måske skulle de havde forklaret mere om dette og mindre om manglen på deres traditionelle management tools.
intellectdk (20) skrev:
I SQL Azure bestemmer du selv hvor dine databaser ligger og du opretter dem i et specifikt hostingcenter (f.eks. irland som er det der er tættest på os). Her vil alle dine data ligge, og arkitekturmæssigt vil din primære instans ligge på lokale diske på en enkel "commodity" maskine i en container i irland. Derudover vil der være to replikerede sekundære instanser der ligger på andre commodity maskiner i samme hostingcenter i irland. Adgangen til dataene håndteres af en TDS proxy som sørger for at sende dine TDS pakker til den primære instans hvis den er oppe eller en af de sekundære hvis primære er gået ned.
Derudover er der en masse operationelle rutiner til at flytte dine instanser rundt mellem forskellige maskiner for at udjævne så alle fysiske maskiner i hostingcentret altid ligger på en acceptabel gennemsnits utilization (pt er den ifølge MS på under 50% på samtlige fysiske maskiner).
Så der er ikke så meget magi, det er basalt set replikering på tværs af 3 bokse med en proxy foran og en masse administrative rutiner til at håndtere at du ligger på en boks hvor der er spillerum samt der bliver spinnet en ny instans op af din database hvis den hardware en af replikaerne ligger på går ned.
Derfor skalerer du heller ikke uendeligt hvis du laver "unoder" på din database der bruger flere ressource end den "commodity" maskine din primære database ligger på er der ikke mere at give af, medmindre selvfølgelig microsoft overvåger dette og kan flytte din instans til en dedikeret fysisk boks hvor der ikke ligger andre databaser eller de evt. kan flytte dig til en større maskine.
Yderst interessant.
Jeg vil konkludere at SQL Azure intet har med cloud at gøre.
1 aktiv og 2 passive servere og en router der sender requests til den aktive (og så i et eksternt hosting center) er da så langt fra cloud som man kan komme.
Det kan enhver sætte op med stort set alle databaser bare med konfiguration.
intellectdk (20) skrev:Hvis du læser ovenstående vil jeg så håbe at du indser at dine spekulationer på det nuværende stadie med Azure ikke er helt i vinkel.
Det er vist en underdrivelse.
Jeg troede at det var en cloud database.
intellectdk (20) skrev:Og selvom jeg ikke havde ovenstående viden kunne jeg godt fortælle dig generelt at cloud databaser ikke hænger sådan sammen.
Sådan fungerer cloud databaser.
intellectdk (20) skrev:ACID properties og distribuerede systemer er MEGET svært at få til at spille sammen, og det er også derfor at vi ser de virkelig store spillere lader sig "nøjes" med eventual consistency som vi ser med f.eks. distribuerede key/value stores, kolonne orienterede databaser og MapReduce forespørgsel på data.
Nu var det jeg beskrev faktisk slet ikke distribueret database, men kun distribueret storage.
Men en cloud database kræver naturligvis også distribueret database for at kunne skalere på cloud vis.
Og ja - det giver nogle anderledes løsninger. Og det er også langtfra givet at det er en brugbar løsning for alle problemer.
Men det er en stor fejl at vurdere cloud løsninger efter om de fungerer ligesom traditionelle løsninger. Det er ikke meningen.
arne_v (22) om backup skrev:
Det må jo formentligt blive på den gammeldags måde med at blokere updates indtil MS leverer en bedre måde.
Så går pointen lidt af HA delen af at gøre SQL Azure.
arne_v(22) skrev:
Jo. Og hvis ens målsætning er at komme at skabe omtale for ens firma i pressen, så er der jo heller ikke nogen grund til at nævne hvilke problemer der er annonceret løsninger på. Men hvis man nu var interesseret i at give tilhørerne mulighed for reelt at vurdere Azure, så ville man nok netragte det som relevant.
Præsentationen kom som resultatet af en analyse af om det er noget vi i Miracle kan anbefale til vores kunder, og Mark fra iPaper var interreseret i om det var et reelt alternativ til selv at drifte og hoste deres SQL Server som de gør pt hos iPaper.
At backup er på vej har vi efterfølgende fået af vide af Microsoft, jeg har ikke fundet det officielle roadmap for azure endnu men du er da velkommen til at give mig et link hvis du har fundet det?
arne_v(26) skrev:
Jeg troede at det var en cloud database.
....
Sådan fungerer cloud databaser.
Jeg vidste ikke der fandet en officiel definition på en cloud database. Men jeg vil da gerne se dine eksempler på relationelle databaser i skyen der fungerer på denne måde, f.eks. fungerer Amazons RDS på nogenlunde samme måde, jeg skal ikke kunne sige om de har en TDS-like router og nogle replika (hvoraf flere med RDS kan være aktive ad gangen). Men princippet er det samme du starter instanser op på en specifik lokation (pt North Virginia eller Irland) og mit bud vil være det bygger ovenpå EC2 instanser og du har en form for load balancer for mysql foran.
arne_v(26) skrev:
Men det er en stor fejl at vurdere cloud løsninger efter om de fungerer ligesom traditionelle løsninger. Det er ikke meningen.
Det er vi enige om, og hvis man vil skalere til det ekstreme er relationelle databaser nok heller ikke altid det bedste valg. Men præsentationen har i høj grad været et modspil mod den noget ensidige information der har været fra Microsoft som f.eks:
"It provides a highly available, scalable, multi-tenant database service hosted by Microsoft in the cloud."
"Customers can use existing knowledge in T-SQL development and a familiar relational data model for symmetry with existing on-premises databases"
Og ting som:
"Consolidate multiple data sources in the Cloud and enable secure access from multiple locations, desktop and/or devices"
som viser sig sjældent at være praktiske pga ekstrem høj latency.
"Integration with SQL Server and tooling including Visual Studio"
Hvilket også viser sig ikke at være den fulde historie.
"Scale databases up or down based on business needs"
Hvilket heller ikke er den fulde historie da man ikke kan scalere ud over størrelsen på en enkelt boks i MS hostingcenter som ifølge dem selv er "commodity hardware"
intellectdk (27) skrev:Så går pointen lidt af HA delen af at gøre SQL Azure.
Ikke nødvendigvis. HA betyder kun at systemet altid er tilgængelig når det skal være tilgængeligt - ikke at der ikke er et dagligt service vindue.
Men natlig nedlukning har godt nok sådan en vis 90'er duft over sig.
intellectdk (27) skrev:Præsentationen kom som resultatet af en analyse af om det er noget vi i Miracle kan anbefale til vores kunder, og Mark fra iPaper var interreseret i om det var et reelt alternativ til selv at drifte og hoste deres SQL Server som de gør pt hos iPaper.
Og den tanke at det kunne give en del omtale af Miracle med nogle markante udmeldinger havde naturligvis aldrig strejfet jer.
intellectdk (27) skrev:At backup er på vej har vi efterfølgende fået af vide af Microsoft, jeg har ikke fundet det officielle roadmap for azure endnu men du er da velkommen til at give mig et link hvis du har fundet det?
Ikke en officiel roadmap.
Men http://www.develop-one.net/blog/2010/03/01/SQLAzur... viser en slide fra et par højtstående MS gutter.
intellectdk (27) skrev:Jeg vidste ikke der fandet en officiel definition på en cloud database.
Der er vel ikke nogen formel definition af cloud men jeg vil sige at cloud kræver at:
- servicen ikke kan ikke henføres til nogle bestemte fysiske servere
- har ekstreme muligheder for op og ned skalering
3 servere i Irland er en traditionel hosting løsning ikke en cloud løsning.
intellectdk (27) skrev:Men jeg vil da gerne se dine eksempler på relationelle databaser i skyen der fungerer på denne måde, f.eks. fungerer Amazons RDS på nogenlunde samme måde,
Nu har jeg ikke brugt RDS, men udfra den beskrivelse de selv giver, så fungerer RDS ikke på den måde.
Beskrivelsen siger at du har et variabelt antal database instanser med et variabelt antal resourcer.
Men det er rigtigt at det er en federated og ikke en distributed løsning.
intellectdk (27) skrev:Men præsentationen har i høj grad været et modspil mod den noget ensidige information der har været fra Microsoft som f.eks:
"It provides a highly available, scalable, multi-tenant database service hosted by Microsoft in the cloud."
"Customers can use existing knowledge in T-SQL development and a familiar relational data model for symmetry with existing on-premises databases"
Og ting som:
"Consolidate multiple data sources in the Cloud and enable secure access from multiple locations, desktop and/or devices"
som viser sig sjældent at være praktiske pga ekstrem høj latency.
"Integration with SQL Server and tooling including Visual Studio"
Hvilket også viser sig ikke at være den fulde historie.
"Scale databases up or down based on business needs"
Det er jo så den helt ægte total gennemførte bullshit.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund