AMAZON DYNAMODB → STACKIT
Amazon DynamoDB zu STACKIT migrieren
STACKIT bietet keinen DynamoDB-kompatiblen Dienst; der Umzug einer Tabelle ist also ein Redesign. StackToIT plant es klar: STACKIT MongoDB Flex als Ziel mit jeder Tabelle als Collection, Schlüssel und Indizes für Ihre Entwickler zugeordnet und PostgreSQL Flex mit JSONB als Alternative.
Eine DynamoDB-Tabelle mit globalem Sekundärindex
Aus dem veröffentlichten Lauf zu AWS Retail Store. Links die AWS-Quelle genau so, wie AWS sie veröffentlicht; rechts die Ressourcenblöcke, die StackToIT geschrieben hat; die Prüfkommentare über jedem Block in der Datei sind hier ausgelassen.
module "dynamodb_carts" {
source = "terraform-aws-modules/dynamodb-table/aws"
version = "3.3.0"
name = "${var.environment_name}-carts"
hash_key = "id"
attributes = [
{
name = "id"
type = "S"
},
{
name = "customerId"
type = "S"
}
]
global_secondary_indexes = [
{
name = "idx_global_customerId"
hash_key = "customerId"
projection_type = "ALL"
}
]
tags = var.tags
}resource "stackit_mongodbflex_instance" "dynamodb_tables" {
project_id = var.project_id
name = "dynamodb-tables"
acl = var.dynamodb_tables_allowed_cidrs
version = var.dynamodb_tables_version
flavor = {
cpu = var.dynamodb_tables_cpu
ram = var.dynamodb_tables_ram
}
replicas = 3
storage = {
class = var.mongodbflex_storage_class
size = var.dynamodb_tables_storage_gb
}
backup_schedule = "0 2 * * *"
options = {
type = "Replica"
point_in_time_window_hours = var.dynamodb_tables_pitr_hours
}
}Jede Tabelle wird eine Collection
Die Tabelle carts wird die Collection retail-store-ecs-carts auf einer MongoDB-Flex-Instanz.
Schlüssel und Indizes zugeordnet
Der Hash-Key id wird _id oder ein eindeutiger Index, und der globale Sekundärindex auf customerId wird ein Sekundärindex.
Redundanz bleibt in der Region
DynamoDB repliziert über Zonen; ein Replica Set mit drei Mitgliedern hält die Redundanz innerhalb der STACKIT-Region.
Größe und Backup als Eingaben
CPU, Speicher, Storage und das Point-in-Time-Fenster sind Variablen, und ein tägliches Backup ist als Ausgangspunkt gesetzt.
Was Ihre Entwickler einplanen
Datenzugriffsschicht
Die DynamoDB-Aufrufe der Anwendung werden gegen die MongoDB-API neu geschrieben.
Datenumzug
Export aus DynamoDB nach S3, dann Import mit mongoimport. Der Plan sagt das, denn nichts repliziert die Daten live.
Zu ersetzende Funktionen
Kapazitätsmodi, DynamoDB Streams und bedingte Schreibvorgänge werden als nicht übernommen benannt, mit dem, was stattdessen dient, etwa Change Streams oder ein Outbox-Muster.
Datenumzug in fünf Schritten
Aus dem Dokument zum Datenumzug, das der Lauf für die Tabelle carts geschrieben hat. StackToIT überträgt selbst keine Daten: Jeder Schritt ist für eine Person.
1 · Schreibstopp
Verantwortlich: Migration Owner. Schreibende auflisten, die Verbindungseinstellungen jedes Clients festhalten, dann die Schreiber stoppen. Die Quelle bleibt unberührt; der Rückweg braucht also nichts an der Quelle.
2 · Export
Verantwortlich: Data Architect. Die Tabelle innerhalb des Schreibstopps nach S3 exportieren. Der Export setzt Point-in-Time-Recovery voraus, und die Tabelle im Lauf nennt sie nicht, daher wird die Recovery zuerst eingeschaltet. Die manifest-summary.json aufbewahren; ihr itemCount speist den Abschlussvergleich.
3 · Konvertierung
Verantwortlich: Data Architect. Ein eigenes Skript entpackt die Typbeschreiber des DynamoDB-JSON in BSON-Werte und macht den Schlüssel id zum _id. Zahlen mit mehr als 34 signifikanten Stellen passen nicht in ein decimal128; daher behält das Skript sie als Strings oder meldet sie.
4 · Abschluss-Sync
Verantwortlich: Data Architect. Die Dokumente mit mongoimport oder einem Treiber-Skript laden, danach die Indizes bauen. Der Entwurf legt die Instanz leer an; Benutzer und Zugriffsliste der Instanz setzen Sie selbst.
5 · Abgleich
Verantwortlich: Data Architect. Die Dokumentzahl muss dem itemCount abzüglich der von der Konvertierung gemeldeten Einträge entsprechen, eine Stichprobe von Schlüsseln muss auf beiden Seiten dasselbe liefern, und die wichtigste Leseabfrage der Anwendung muss dieselbe Antwort liefern. Dann hält der Verantwortliche GO oder NO-GO fest.
Was die beiden Speicher unterscheidet
Sets werden zu Arrays
String-, Number- und Binary-Sets enthalten eindeutige Werte ohne Reihenfolge. Ein Array tut das nicht; Code, der sich auf Mengenoperationen stützt, ändert sich daher.
Konsistenz der Indizes
Ein Global Secondary Index ist letztendlich konsistent (eventually consistent). Ein MongoDB-Index wird mit dem Schreibvorgang aktualisiert.
Eintragsgröße
DynamoDB-Einträge fassen bis zu 400 KB, ein BSON-Dokument bis zu 16 MiB; in dieser Richtung ist keine Größenprüfung nötig.
Kapazität und Abrechnung
Der Abrechnungsmodus pay-per-request und die Index-Projektionen werden nicht übernommen. Die Instanzgröße wird als CPU, Arbeitsspeicher und Speicher gewählt.
Wiederherstellungsfenster
DynamoDB-Point-in-Time-Recovery deckt 1 bis 35 Tage ab. MongoDB Flex dokumentiert Point-in-Time-Restore für die letzten 30 Stunden; das ist der Standardwert 30 im Entwurf.
Backup-Rhythmus
MongoDB Flex sichert alle 6, 8, 12 oder 24 Stunden; die tägliche Snapshot-Aufbewahrung beträgt 3 bis 360 Tage.
Bewiesen an einer echten AWS-Umgebung
Die AWS Retail Store Sample App, ein öffentliches Terraform-Projekt von AWS, von StackToIT bewertet und vollständig veröffentlicht, genau so, wie der Lauf es geschrieben hat.
Fallstudie ansehen (Englisch)- 282
- Terraform-Ressourcendefinitionen analysiert
- 44
- Migrationseinheiten identifiziert
- 38
- Zieleinheiten erzeugt, von 52 betrachteten
- 331
- Planschritte erstellt
Fragen aus der Entwicklung
Gibt es auf STACKIT einen DynamoDB-kompatiblen Dienst?
Nein. Deshalb klassifiziert StackToIT eine DynamoDB-Tabelle als Redesign und entwirft MongoDB Flex als Alternative, nicht als Entsprechung.
MongoDB Flex oder PostgreSQL Flex?
Beide werden im Ergebnis benannt. MongoDB Flex bleibt dem Dokumentmodell am nächsten; PostgreSQL Flex mit JSONB passt zu einem Team, das eine einzige relationale Engine möchte.
Schreibt StackToIT Anwendungscode um?
Nein. StackToIT schreibt die Infrastruktur, die Zuordnung von Schlüsseln und Indizes und die Migrationsschritte; Ihre Entwickler schreiben die Datenzugriffsschicht neu.
Wie lange dauert der Schreibstopp?
Der Plan nennt keine Zahl. Der Stopp dauert mindestens so lange wie Export, Konvertierung und Import zusammen, und der Lauf vermerkt, dass AWS für einen Export keine Fertigstellungszeit zusagt. Proben Sie die Übernahme an einer Kopie, um sie zu messen.
Können wir nach dem Cutover zurück?
Bis zum ersten Schreibvorgang, den die neue Collection annimmt, setzt ein Rollback nur die Verbindungseinstellungen zurück. Danach hält die Collection Daten, die nur dort existieren; Sie kopieren sie mit einem vor dem Fenster erprobten Verfahren zurück oder nehmen den Verlust hin. Ist die DynamoDB-Tabelle stillgelegt, gibt es nichts mehr, wohin Sie zurückkehren können; daher hält der Verantwortliche das Datum fest, bis zu dem sie aufbewahrt wird.
Wie belegen wir, dass die Kopie vollständig ist?
Der Abgleichsschritt vergleicht die Dokumentzahl mit dem itemCount des Exports, liest eine Stichprobe von Schlüsseln auf beiden Seiten (auf DynamoDB mit stark konsistentem Lesen) und führt eine echte Leseabfrage der Anwendung gegen beide Seiten aus.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.