Méthode de sauvegarde de données réaliste pour Parse.com

Question

Nous construisons une application iOS avec Parse.com, mais ne pouvons toujours pas trouver la bonne façon de sauvegarder efficacement les données. En tant que prémisse, nous avons et aurons beaucoup de rangées de magasins de données. Supposons que nous ayons une classe avec 1 million de lignes, supposons que nous l'ayons sauvegardée, puis que nous voulions la ramener à Parse, après une situation dangereuse (comme la perte de données sur la production).

Les quelques solutions que nous avons examinées sont les suivantes:

1) Utiliser un serveur externe pour la sauvegarde

BackUp: - utiliser l'API REST pour sauvegarder en permanence des données sur un serveur MySQL (nous avons choisi A) - recréer des objets JSON à partir de la sauvegarde MySQL et utiliser l'API REST pour renvoyer à Parse. Supposons que nous utilisions l'opération par lots qui permet de créer 50 objets simultanés avec une requête, et supposons que cela prend 1 seconde pour chaque requête, 1 million d'ensembles de données prendront 5,5 heures pour être transférés dans Parse. B) - recréer un fichier JSON à partir de la sauvegarde MySQL et utiliser le tableau de bord pour importer les données manuellement. Nous avons juste essayé avec 700 000 fichiers d'enregistrements avec cette méthode: il a fallu environ 2 heures pour que l'indicateur de chargement s'arrête et affiche le nombre de lignes dans le volet gauche, mais il ne s'ouvre plus dans le volet droit ") et il est plus de 6 heures depuis le début du téléchargement. Donc, nous ne pouvons pas compter sur 1.b, et 1.a semble prendre trop de temps à se remettre d'une catastrophe (si nous avons 10 millions d'enregistrements, ce sera comme 55 heures = 2,2 jours).

Maintenant, nous pensons à ce qui suit:

2) répliquent en permanence les données à une autre application

Créer ce qui suit dans Parse: - App Production: A - App réplication: B Ainsi, alors que A est en production, chaque requête sera dupliquée vers B (en utilisant constamment le job d'arrière-plan). L'inconvénient est bien sûr qu'il va manger jusqu'à la limite de rafale de A car il va simplement doubler la quantité de requête. Donc, pas idéal de penser à l'échelle. Ce que nous voulons, c'est quelque chose comme AWS RDS qui donne une option pour sauvegarder automatiquement tous les jours. Je me demande comment cela pourrait être difficile pour Parse car il est basé sur AWS infra.

S'il vous plaît laissez-moi savoir si vous avez une idée à ce sujet, sera heureux de partager savoir-comment.

P.S .:

Nous avons remarqué un défaut important dans l'idée 2) ci-dessus.

Si nous répliquons à l'aide de l'API REST, tous les objets de toutes les classes seront modifiés, de sorte que toutes les relations 1to1 ou 1toMany seront rompues. Nous pensons donc à mettre un uuid pour chaque classe d'objet.

Y a-t-il un problème avec cette méthode? Une chose que nous voulons atteindre est query.include ("ObjectName") (ou Obj-C "includeKey"), mais je suppose que ce ne sera pas possible si nous ne basons pas notre logique d'application sur objectId .

Vous cherchez un moyen de contourner ce problème; mais la gestion par uuid sera-t-elle fonctionnelle dans la logique de Parse's Datastore?

Answer 1

L'analyse a jamais perte de données de production. Bien que nous n'offrons pas actuellement de sauvegardes automatisées, vous pouvez en demander une quand vous le souhaitez, et nous travaillons à rendre tout cela encore plus agréable. En outre, il est plus facile dans la plupart des cas d'importer le fichier d'exportation JSON via le navigateur de données plutôt que d'utiliser le lot REST.

Answer 2

Je peux confirmer qu'aujourd'hui, Parse a perdu mes données. Ou du moins, il semblait l'être.

Après plusieurs erreurs détectées sur plusieurs applications (acceptées par le compte Twitter Parse Status), nous n'avons pas pu récupérer les données d'une application, sans aucune erreur. C'est parce qu'une colonne entière d'un de notre classe (pointeur de type) a disparu et que les données n'étaient plus présentes dans le tableau de bord.

Nous utilisons cette colonne de pointeur pour filtrer/extraire des données, donc les requêtes retournées et les collections étaient vides. Nous avons donc décidé de recréer la colonne manuellement.

Par chance, recréer la colonne, avec le même nom et le même type, a résolu le problème et les données étaient toujours là ... Je ne peux pas l'expliquer mais j'ai vraiment pensé, et l'application a réagi comme si les données étaient perdues.

Donc, une option de sauvegarde et de restauration automatique est obligatoire, ce n'est pas une option.

Answer 3

Pour les suppressions accidentelles, l'écriture d'une fonction de cloud «beforedelete» pour sauvegarder la ligne en cours dans une autre classe fonctionnerait.

Pour les sauvegardes régulières, l'exportation manuelle des enregistrements modifiés (filtre d'utilisation) sera utile. Pour la récupération cela vous oblige à écrire des scripts/utiliser l'option d'importation (pas si sûr) dans le navigateur de données. Vous pouvez également écrire une fonction de cloud réplique des données sur votre serveur de sauvegarde (ne l'avez pas encore essayé).

Cependant, il existe des limites à code nuage que vous devriez considérer avant de se lancer dans ce: https://parse.com/docs/cloud_code_guide#functions-resource

Answer 4

En Décembre a publié un parse.com ici à 2015 nouveau tableau de bord avec une fonction améliorée d'exportation. Il suffit de sélectionner votre application, cliquez sur "Paramètres de l'application" -> "Général" -> "Exporter les données de l'application". Parse génère un fichier json pour chaque classe de votre application et vous envoie un e-mail si la progression de l'exportation est terminée.

---

MISE À JOUR:

Triste mais vrai, parse.com tire à sa: http://blog.parse.com/announcements/moving-on/

Answer 5

J'ai eu la même question de la sauvegarde des données du serveur d'analyse syntaxique. Comme le serveur d'analyse utilise mongodb, c'est pourquoi la sauvegarde des données n'est pas un problème, je viens de faire une chose simple. téléchargé la sauvegarde de mongodb du serveur.Et puis restauré à l'aide

mongorestore /path-to-mongodump (fichiers extraits)

Comme Parse a été tourné pour ouvrir source.Therefore nous pouvons adopter cette technique.