Wir erstellen eine iOS-App mit Parse.com, können aber immer noch nicht den richtigen Weg finden, Daten effizient zu sichern.Realistische Datensicherungsmethode für Parse.com
Als Prämisse haben wir und werden eine Menge von Datenspeicher Reihen haben. Nehmen wir an, wir haben eine Klasse mit 1 Millionen Zeilen, nehmen an, dass wir sie gesichert haben, und dann nach einer gefährlichen Situation (wie Datenverlust bei der Produktion) zurück zu Parse bringen wollen.
Die wenigen Lösungen, die wir in Betracht gezogen haben, sind folgende:
1) Verwenden Sie externe Server für Backup
BackUp: - die REST-API verwenden, ständig Daten zu einem entfernten MySQL-Server zu sichern (wir wählten MySQL für kundenspezifische Analysezwecke, da es viel schneller und einfacher ist, Daten mit MySQL für uns zu handhaben)
ImportBack: a) - erstellen Sie JSON-Objekte aus der MySQL-Sicherung und verwenden Sie die REST-API zum Zurücksenden an Parse. Angenommen, wir verwenden die Batch-Operation, die die gleichzeitige Erstellung von 50 Objekten mit einer Abfrage ermöglicht, und nehmen an, dass sie für jede Abfrage 1 Sekunde dauert. 1 Million Datensätze benötigen 5,5 Stunden für die Übertragung nach Parse.
b) - eine Datei von JSON MySQL Backup nachzubilden und das Armaturenbrett verwenden, um Daten manuell zu importieren. Wir haben gerade versucht mit 700.000 Datensätze Datei mit dieser Methode: Es dauerte etwa 2 Stunden für die Ladeanzeige zu stoppen und zeigen die Anzahl der Zeilen im linken Bereich, aber jetzt wird es nie im rechten Fensterbereich geöffnet (es heißt "Betriebszeit ") und es ist über 6 Stunden seit dem Upload gestartet.
Also können wir uns nicht auf 1.b verlassen, und 1.a scheint zu lange zu brauchen, um sich von einer Katastrophe zu erholen (wenn wir 10 Millionen Datensätze haben, wird es wie 55 Stunden = 2,2 Tage sein).
Jetzt denken wir über die folgenden:
2) Ständig Daten an eine andere App
folgendes in Parse erstellen replizieren: - Produktion App: Ein - Replizierung App: B So, während A in Produktion ist, wird jede einzelne Abfrage zu B dupliziert (unter Verwendung des Hintergrundjobs ständig). Der Nachteil ist natürlich, dass es das Burst-Limit von A auffressen wird, da es die Menge der Abfrage einfach verdoppeln wird. Also nicht ideal, wenn man sich vergrößert.
Was wir wollen, ist so etwas wie AWS RDS, die eine Option gibt, um automatisch Backup täglich. Ich frage mich, wie dies für Parse schwierig sein könnte, da es auf AWS infra basiert.
Bitte lassen Sie mich wissen, wenn Sie auf diese eine Idee haben, werden glücklich sein Know-hows zu teilen.
P. S .:
Wir haben einen wichtigen Fehler in der obigen 2) Idee bemerkt.
Wenn wir REST API replizieren verwenden, alle objectIds aller Klassen wird geändert, so alle 1to1 oder 1toMany Beziehungen gebrochen wird.
Also denken wir darüber nach, eine UUID für jede Objektklasse zu setzen.
Gibt es ein Problem mit dieser Methode? Eine Sache, die wir erreichen wollen, ist query.include („ObjektName“) (oder in Obj-C „includeKey“), aber ich nehme an, dass nicht möglich sein wird, wenn wir auf objectId unserer App Logik stützen nicht .
Auf der Suche nach einer Arbeit für dieses Problem; aber wird die UUID-basierte Verwaltung unter der Datastore-Logik von Parse funktionieren?
Die Tatsache, dass Sie noch nie Daten verloren haben, bedeutet nicht, dass Sie nie Daten verlieren werden. –
Wir machen auch Backups, falls das jemals passiert. Es wäre nicht an Ihnen, in dieser Instanz wiederherzustellen (aber es ist immer noch gut, Backups zu behalten, auch wenn nur für andere Zwecke, wie das Laden/Arbeiten mit den Daten woanders.) – Fosco
Hallo Fosco, danke für dein Follow-up. Bitte klären Sie Folgendes: Sollten wir unsere Daten über den Parse DataStore (durch menschliche Fehler oder Hackerangriffe oder aus einem anderen Grund) verlieren, könnten wir Sie beispielsweise per E-Mail/Anruf kontaktieren und um sofortige Wiederherstellung Ihrer Backups bitten? Wie oft sichern Sie Daten im DataStore (wie alt wäre der wiederhergestellte Datensatz?). Wenn wir diese nicht kennen, glaube ich nicht, dass Entwickler darauf vertrauen können. – dcc