sql >> Database teknologi >  >> RDS >> Database

Hvad jeg gerne vil se i Amazon EC2 for Database Management

Amazon EC2 (Amazon Elastic Compute Cloud) er en fabelagtig cloud computing-platform. Et flertal af internettet kører på Amazon AWS - når brugere henviser til "cloud computing", taler de implicit om Amazon AWS. Mit firma har kørt og administreret databaser på AWS i et par år nu, og vi har lært meget af vores erfaringer. Selvom AWS er ​​en nem platform at komme i gang med, er det ekstremt svært at køre store diskintensive arbejdsbelastninger på AWS. Jeg siger ikke, at det ikke kan lade sig gøre - men den nødvendige tid og ekspertise er længere end de fleste brugere. Her er et par ting, som jeg gerne vil se i Amazon EC2 for at gøre det nemmere at køre databaser på AWS.

  1. Ikke-efemere lokale diske

    Netværksbaseret EBS er praktisk til de fleste arbejdsbelastninger, men ydeevnen er afgrundsdyb for skrivetunge arbejdsbelastninger. Introduktionen af ​​klargjort IOPS letter dette problem en smule. Provisioned IOPS er dog ret dyre, og omkostningerne stiger, især når du kører en stor klynge med 10-20 maskiner. Som et alternativ vil det være fantastisk, hvis hårde diskbelastninger som databaser kunne løbe væk fra den lokale disk. Det er ikke en mulighed i dag, fordi de lokale diske er "efemere". Hvis du stopper og genstarter din maskine, kan den flytte til en anden vært, og du mister dine lokale data. Dette er ikke en acceptabel risiko, selv når der er flere kopier af data.

  2. Lavpris SSD

    Det ville være fantastisk, hvis Amazon kan tage et blad ud af DigitalOceans bog og introducere billige SSD'er til sine servere. Server-side computing bevæger sig langsomt til SSD, og ​​om et par år vil SSD-servere være den faktiske lagring for dine server-arbejdsbelastninger. Amazon tilbyder SSD'er i dag, men de er ret dyre og ikke en mulighed for de fleste arbejdsbelastninger. SSD-tilbuddet har også det samme "efemere" problem som lokale diske.

  3. Sikkerhedsgrupper på tværs af regioner

    Geo-distribuerede klynger er en realitet i vores tid. En række kunder har brug for at implementere servere på tværs af regioner af flere årsager lige fra tilgængelighed til partitionering. Den eneste måde at sikre disse implementeringer i dag er ved at bruge en IP-hvidliste, som er ekstremt vanskelig at vedligeholde. Sikkerhedsgrupper på tværs af regioner vil i høj grad lette byrden for kunder, der implementerer på tværs af flere regioner. i dag har Amazon meget lidt funktionalitet, der fungerer på tværs af regioner. De introducerede for nylig muligheden for at kopiere skabeloner på tværs af regioner, hvilket er meget nyttigt, og jeg håber, at de fortsætter med at tilføje flere funktioner, der er på tværs af regioner.

  4. Synkroniserede snapshots på tværs af flere enheder

    I nogle af vores større databaseklynger skal vi tage backup af flere servere samtidigt. For eksempel, I en shard MongoDB-klynge skal du sikkerhedskopiere en konsistent kopi af alle shards. Selvom der er teknikker til at gøre dette i dag, er de alle ret behårede og sårbare over for fiasko. En ideel måde at sikkerhedskopiere disse servere på er at starte et synkroniseret snapshot på tværs af flere volumener. Dette sikrer et ensartet øjebliksbillede på tværs af alle volumener.

  5. Bedre VPC-styring

    Jeg kan personligt ikke lide tanken om at udsætte produktionsdatabaser for internettet. Derfor er jeg en stor fan af Virtual Private Clouds (VPC). Teknologien er fantastisk, men administrationsgrænsefladen er ret kedelig. VPC og klassisk EC2 er meget ens, indtil de ikke er det. Du ender med at skifte frem og tilbage mellem EC2-konsollen og VPC-konsollen. Når du først administrerer 10+ servere, lægger det nuværende administrationsparadigme en stor byrde på brugeren. Jeg synes, der er plads til at forenkle koncepterne og gøre det nemmere at administrere.

Som altid, hvis du har spørgsmål, er du velkommen til at kontakte os [email protected].


  1. Hvad gør en transaktion omkring en enkelt erklæring?

  2. Sådan formateres måneden i romertal i Oracle

  3. COALESCE-funktion i TSQL

  4. Skal en databaseforbindelse forblive åben hele tiden eller kun åbnes, når det er nødvendigt?