Ich habe einige Terabyte an Daten in unserem Altsystem, auf dem SQL Server läuft. Unsere neuere Version läuft auf MongoDB. Wir migrieren diese Daten zu MongoDB. Wir haben Python-Skripte geschrieben und überprüft, alle Datenbewegungen erfolgen ordnungsgemäß.
Wir haben dies auf einer kleineren Maschine mit 4 Kernen gemacht. Wenn wir es auf einer größeren Maschine machen, wird es sehr teuer. AWS Lambda hat eine Verarbeitungszeit von 15 Minuten, es dauert also mehr als 24 Stunden, bis eine Iteration abgeschlossen ist. AWS Step Functions verspricht dies, aber ich bin nicht sicher, ob es das Richtige ist.
Antwort1
Können Sie „mongoexport“ nicht lokal ausführen, nach S3 (oder einem physischen AWS Snowcone-Gerät) exportieren, eine EC2-Instanz für „mongoimport“ verwenden und dann Ihr Skript ausführen, um seit dem Dump alle Aktualisierungen durchzuführen?
Was die Ausführung betrifft, kommen Sie wahrscheinlich mit einer Spot-EC2-Instanz aus, insbesondere wenn Sie sie außerhalb der Spitzenzeiten der Region verwenden – beispielsweise an einem Wochenende. Wenn Ihr Job nicht unterbrochen werden kann, dann On-Demand-EC2. Ein m5.xlarge mit 4 Kernen/16 GB RAM kostet 0,20 $ pro Stunde, ein paar Tage davon kosten 10 $.
Ich möchte auch darauf hinweisen, dass das Senden von beispielsweise 3 TB bei 100 Mbit/s 2,6 Tage dauert, bei 800 Mbit/s jedoch 7 Stunden. Die Aufrechterhaltung dieser Bandbreite kann jedoch ohne DirectConnect schwierig sein. Am besten verwenden Sie einAWS SnowconeDabei handelt es sich um ein physisches Gerät, auf das Sie Daten kopieren und dann an AWS versenden.
Ich würde vorschlagen, den AWS Database Migration Service zu verwenden, umWandernvon MongoDB nachAWS DocumentDB, das ist ihre Version von MongoDB mit einem anderen Namen. DMS migriert die Daten, dann richten Sie Ihre Anwendung einfach auf die neue Instanz und schalten die alte aus.