Zoals ik het begrijp, is IOPS met RDS-voorziening vrij duur in vergelijking met de standaard I/O-snelheid.

In de regio Tokio is het P-IOPS-tarief 0,15$/GB, 0,12$/IOP voor standaardimplementatie. (Verdubbel de prijs voor Multi-AZ-implementatie…)

Voor P-IOPS is de minimaal vereiste opslag 100 GB, IOP is 1000.
Daarom bedragen de startkosten voor P-IOPS 135 $ exclusief instantieprijzen.

In mijn geval kost het gebruik van P-IOPS ongeveer 100x meer dan het gebruik van de standaard I/O-snelheid.

Dit kan een zeer subjectieve vraag zijn, maar geef alstublieft uw mening.

Zouden de prestaties de prijs waard zijn in de meest geoptimaliseerde database voor RDS P-IOPS?

of

De AWS-sitegeeft inzicht in hoe P-IOPS de prestaties ten goede kan komen. Is er een echte benchmark?

ZELF ANTWOORD

Naast het antwoord dat zeroSkillz schreef, heb ik wat meer onderzoek gedaan. Houd er echter rekening mee dat ik geen expert ben in het lezen van database-benchmarks. Ook was de benchmark en het antwoord gebaseerd op EBS.

Volgens een artikelgeschreven door “Rodrigo Campos”, de prestaties verbeteren inderdaad aanzienlijk.

Van 1000 IOPS tot 2000 IOPS verdubbelen de lees-/schrijfprestaties (inclusief willekeurig lezen/schrijven). Van wat zeroSkillz zei, levert het standaard EBS-blok ongeveer 100 IOPS op. Stelt u zich de prestatieverbetering voor wanneer 100 IOPS oploopt tot 1000 IOPS (wat de minimale IOPS is voor P-IOPS-implementatie).

Conclusie

Volgens de benchmark lijken de prestaties/prijs redelijk. Voor prestatiekritieke situaties denk ik dat sommige mensen of bedrijven P-IOPS zouden moeten kiezen, zelfs als ze 100x meer in rekening worden gebracht.

Als ik echter een financieel adviseur in een klein of middelgroot bedrijf zou zijn, zou ik mijn RDS-instanties geleidelijk opschalen (zoals in CPU, geheugen) totdat de prestatie/prijs overeenkomt met P-IOPS.

Antwoord 1, autoriteit 100%

Ok. Dit is een slechte vraag omdat er geen melding wordt gemaakt van de grootte van de toegewezen opslagruimte of andere details van de installatie. We gebruiken RDS en het heeft zijn plussen en minnen. Ten eerste kun je een kortstondig opslagapparaat niet gebruiken met RDS. U kunt zelfs niet rechtstreeks toegang krijgen tot het opslagapparaat wanneer u de RDS-service gebruikt.

Dat gezegd hebbende – het opslagmedium voor RDS wordt verondersteld te zijn gebaseerd op een variant van EBS van amazon. Prestaties voor standaard IOPS zijn afhankelijk van de grootte van het volume en er zijn veel bronnen die stellen dat boven de 100 GB opslag ze EBS-volumes beginnen te “strippen”. Dit zorgt voor een betere gemiddelde toegang tot casusgegevens, zowel bij lezen als schrijven.

We hebben momenteel ongeveer 300 GB aan opslagtoewijzing en kunnen 2k schrijf-IOP en 1k IOP ongeveer 85% van de tijd krijgen over een periode van meerdere uren. We gebruiken datadog om dit te loggen, zodat we het echt kunnen zien. We hebben uitbarstingen van maximaal 4k schrijf-IOP’s gezien, maar niets hield zo stand.

Het belangrijkste symptoom dat we aan de kant van de applicatie zien, is vergrendelingsconflict als de IOPS om te schrijven niet voldoende is. Het aantal en de frequentie die u hiervan in uw toepassingslogboeken krijgt, geeft u symptomen voor het uitputten van de IOPS van standaard RDS. U kunt ook een service zoals datadog gebruiken om de IOPS te controleren.

Het probleem met ingerichte IOPS is dat ze uitgaan van stationaire schrijf-/leesvolumes om kosteneffectief te zijn. Dit is bijna nooit een realistische use-case en is de reden waarom Amazon cloudservices begon te repareren. De enige zekerheid die u krijgt met P-IOPS is dat u een maximale doorvoercapaciteit krijgt gereserveerd. Als je het niet gebruikt, betaal je er nog steeds voor.

Als je het goed vindt om replica’s uit te voeren, raden we je aan een alleen-lezen replica uit te voeren als een NIET-RDS-instantie en deze op een gewone EC2-instantie te plaatsen. U kunt betere lees-IOPS krijgen tegen een veel lagere prijs door de replica zelf te beheren. We zetten zelfs replica’s buiten AWS op met behulp van stunnel en plaatsen SSD-schijven als het primaire blokapparaat en we krijgen belachelijke leessnelheden voor onze rapportagesystemen – letterlijk 100 keer sneller dan we krijgen van RDS.

Ik hoop dat dit helpt om wat details uit de echte wereld te geven. Kortom, naar mijn mening – tenzij u een bepaald niveau van doorvoercapaciteit moet garanderen (of uw toepassing zal mislukken) op een constante basis (of op een bepaald punt), zijn er betere alternatieven voor ingerichte IOPS, inclusief lezen-schrijven splitsen met lezen -replica’s geheugencache enz.

Antwoord 2, autoriteit 89%

Dus ik heb net een gesprek gehad met een Amazon-systeemingenieur en hij had een aantal interessante inzichten met betrekking tot deze vraag. (d.w.z. dit is kennis uit de tweede hand.)

standaard EBS-blokken kunnen bursty-verkeer goed aan, maar zullen uiteindelijk afnemen tot ongeveer 100 iops. Er waren verschillende alternatieven die deze ingenieur voorstelde.

1. sommige klanten gebruiken meerdere kleine EBS-blokken en strippen deze. Dit zal de IOPS verbeteren en het meest kosteneffectief zijn. U hoeft zich geen zorgen te maken over spiegelen, omdat EBS achter de schermen wordt gespiegeld.

2. sommige klanten gebruiken de tijdelijke opslag op de EC2-instantie. (of RDS-instantie) en meerdere slaves hebben om de duurzaamheid te “verzekeren”. De kortstondige opslag is lokale opslag en veel sneller dan EBS. U kunt zelfs met SSD uitgeruste EC2-instanties gebruiken.

3. sommige klanten zullen de master configureren om ingerichte IOPS of tijdelijke SSD-opslag te gebruiken en vervolgens standaard EBS-opslag gebruiken voor de slave(s). De verwachte prestaties zijn goed, maar de failoverprestaties zijn verslechterd (maar nog steeds beschikbaar)

hoe dan ook, als je besluit een van deze strategieën te gebruiken, zou ik het opnieuw bij amazon navragen om er zeker van te zijn dat ik geen belangrijke stappen ben vergeten. Zoals ik al eerder zei, dit is kennis uit de tweede hand.