olly - Fotolia
DynamoDB-Preise machen es zu einem Muss für Serverless Apps
Das Hinzufügen von On-Demand-Abrechnung und ACID-Transaktionen macht Amazon DynamoDB zu einer soliden Datenbankoption für Serverless-Anwendungen.
AWS Lambda-Anwendungen arbeiten seit Anfang an am besten mit Amazon DynamoDB zusammen. Zwei neue Funktionen helfen nun, einige Nachteile des Dienstes zu beheben.
Erstens musste ein Benutzer aufgrund des bisherigen DynamoDB-Preismodells die erwartete Nutzung genau planen und die Kapazität nach Bedarf skalieren. Amazon versuchte, dieses Problem mit Auto Scaling für einen bereitgestellten Durchsatz zu beheben, aber die Skalierung dauerte immer noch zu lange und bewältigte gelegentliche Traffic-Spitzen nicht sehr gut.
Darüber hinaus konnte ein Benutzer den Durchsatz nicht auf null reduzieren, wenn die Datenbank nicht in Gebrauch war. Aus diesen Gründen konnte DynamoDB nicht wirklich als Serverless angesehen werden.
Das hat sich mit DynamoDB On-Demand geändert. Die Funktion, die Benutzer ohne Ausfallzeiten zu bestehenden Produktionstabellen hinzufügen können, erhöht die Flexibilität durch On-Demand-Abrechnung und hohen Durchsatz ohne Provisionierung.
On-Demand auf Abruf erhalten
Mit dem neuen DynamoDB-Preismodell erübrigt sich die Kapazitätsplanung. Es gibt immer noch eine Gebühr für Speicherplatz, aber anstelle von stündlichen Lese-/Schreibraten gibt es eine Gebühr pro Anfrage von 1,25 Dollar pro eine Million Schreiboperationen und 0,25 Dollar pro eine Million Leseoperationen.
Hier ein Beispiel: Ein Anwender hatte eine Tabelle namens APIKeys, die auf einer Mindestkapazität von 100 Lesevorgängen pro Sekunde bleiben musste, da er oft eine Flut von Anfragen gleichzeitig erhielt. Diese Gesamtkapazität blieb weitgehend ungenutzt. Wenn es allerdings einen Anstieg von mehr als 150 API-Aufrufen auf einmal gab, wurden einige dieser Anfragen verzögert oder schlugen fehl.
Er benötigte außerdem 100 Schreiboperationen pro Sekunde, da er die letzte Anmeldezeit für jeden API-Schlüssel verfolgt hat. Die monatlichen Kosten lagen bei etwa 60 US-Dollar allein für den Zugriff auf API-Schlüssel, und er hatte weit unter eine Million Lese-/Schreibanfragen pro Monat abgeschlossen. Bei den On-Demand-Preisen liegen die neuen geschätzten Kosten für die APIKeys-Tabelle jedoch bei 1,50 Dollar pro Monat – eine Einsparung von 97 Prozent.
Wenn man jedoch einheitliche 100 Lese-/Schreiboperationen pro Sekunde hat, ist zu erwarten, dass man etwa 390 US-Dollar pro Monat mit den On-Demand-Preisen zahlt. Infolgedessen sollten sich Benutzer weiterhin für die traditionelle Bereitstellungsoption für Anwendungen mit konstanter und vorhersehbarer Aktivität entscheiden.
Wie Sie On-Demand-Abrechnungen schätzen können
Sie können Ihre monatlichen DynamoDB On-Demand-Preise über die CloudWatch-Konsole schätzen. Klicken Sie auf Metrics > DynamoDB > Table Metrics. Geben Sie im Feld Search den Text ConsumedWriteCapacity ein und wählen Sie dann alle zugehörigen Metriken aus. Wählen Sie über den Tab Graphed Metrics die Summe (sum) für die Statistik und 30 Tage (30 days) als Zeitraum.
Abbildung 1: Legen Sie einen Zeitrahmen für die Anzahl der Einheiten der Schreibkapazität fest.
Wählen Sie oben im Diagramm einen Zeitbereich von vier Wochen und stellen Sie den Diagrammtyp auf Nummer (number) ein. Dadurch werden für jede einzelne Tabelle die in den letzten vier Wochen verbrauchten Schreibkapazitätseinheiten aufgezählt.
Für das erstellte Beispiel zeigte es eine verbrauchte Schreibkapazität von etwa fünf Millionen Operationen pro vier Wochen an, was bedeutet, dass ungefähr 6,25 Dollar pro Monat für Schreibeinheiten zu zahlen sind. Um zu sehen, wieviel Ihre Lesekapazitätskosten betragen, suchen Sie stattdessen nach ConsumedReadCapacity und führen Sie dieselben Schritte aus.
Für unseren Workload erwies sich dies als eine Schätzung der DynamoDB-Kosten in Höhe von zehn Dollar pro Monat anstelle der 600 Dollar pro Monat, die wir derzeit für den bereitgestellten Durchsatz zahlen.
ACID-Transaktionen zu DynamoDB hinzugefügt
Ein zweiter Kritikpunkt gegenüber NoSQL-Datenbanken wie DynamoDB ist immer wieder der Mangel an Transaktionsunterstützung. Genauer gesagt, können diese Dienste eine Reihe von Änderungen nicht zurücksetzen, wenn nur eine Operation fehlschlägt – eine Funktion, die besonders häufig bei Finanztransaktionen verwendet wird, die erst abgeschlossen werden, wenn die Lieferung eines Produkts bestätigt wurde. Wenn die Lieferung fehlschlägt, ist ein Rollback der gesamten Transaktion erforderlich, um eine Rückerstattung zu generieren oder die Belastung zu stornieren.
Amazon hat versucht, dieses Problem mit ACID-Transaktionen für DynamoDB zu beheben. Diese Transaktionen ermöglichen es Entwicklern, bedingte Schreiboperationen für mehrere Datenbanken gleichzeitig durchzuführen.
Transaktionsoperationen ermöglichen zwei grundlegende Arten von Aktionen, um zu verhindern, dass mehrere Prozesse gleichzeitig ein Feld anfordern oder aktualisieren. Entwickler können TransactWriteItems mit Bedingungsanweisungen verwenden, um DynamoDB anzuweisen, entweder alle oder keine bestimmten Operationen auszuführen. Wenn der Vorgang erfolgreich war, wird die Transaktion geschrieben und eine erfolgreiche Nachricht zurückgegeben. Wenn der Vorgang fehlschlägt, muss der Benutzer erneut versuchen, die Transaktion abzuschließen.
Darüber hinaus kann die Operation TransactGetItems zur Konsistenz der Leseelemente verwendet werden und einen Fehler zurückgeben, wenn eine Transaktion für das fragliche Element aktiv verarbeitet wird. Wenn Ihre Anwendung beispielsweise ein Benutzerkonto belastet, können Sie den Aufruf der TransactGetItems-API verwenden, um ihre verbleibende Quote zuerst zurückzugeben, um sicherzustellen, dass sie nicht bereits belastet wird.
Transaktionen sind standardmäßig für alle lokalen Tabellen aktiviert, aber sie sind nicht vollständig ACID-konform für globale Tabellen. Das bedeutet, dass Anwendungen, die diese Funktion benötigen, sich an DynamoDB-Tabellen in einer Region halten sollten, um konsistente Lese-/Schreibvorgänge zu gewährleisten.
Außerdem scheint es zu diesem Zeitpunkt keine Möglichkeit zu geben, eine gesamte Transaktion manuell zurückzusetzen. DynamoDB unterstützt kein Sperren von Elementen, so dass die durch die Transaktionsfunktion aktualisierten Elemente noch aus anderen Operationen geschrieben werden können, bevor die Schreibtransaktion abgeschlossen ist. Wenn Benutzer beispielsweise versuchen, Informationen herunterzuladen, die ihre Quote in einer Transaktion verringern, und jemand anderes gleichzeitig versucht, zusätzliche Quoten zu kaufen, würde der transaktionale Schreibvorgang fehlschlagen, und Amazon DynamoDB würde keine Elemente in der Transaktion aktualisieren.
