parse.com - gcloud datastore export
Método de copia de seguridad de datos realista para Parse.com (5)
Estamos construyendo una aplicación iOS con Parse.com, pero aún no podemos encontrar la manera correcta de hacer una copia de seguridad de los datos de manera eficiente.
Como premisa, tenemos y tendremos MUCHAS filas de almacenes de datos. Supongamos que tenemos una clase con 1 millón de filas, supongamos que tenemos una copia de seguridad, luego queremos devolverla a Parse, después de una situación peligrosa (como la pérdida de datos en la producción).
Las pocas soluciones que hemos considerado son las siguientes:
1) Utilizar servidor externo para copia de seguridad.
BackUp: use la API REST para realizar una copia de seguridad constante de los datos en un servidor MySQL remoto (elegimos MySQL para fines de análisis personalizados, ya que es mucho más rápido y fácil de manejar con MySQL para nosotros)
ImportBack: a): recrea los objetos JSON a partir de la copia de seguridad de MySQL y usa la API REST para enviar a Parse. Supongamos que usamos la operación por lotes que permite crear 50 objetos simultáneos con 1 consulta, y supongamos que toma 1 segundo por cada consulta, 1 millón de conjuntos de datos tomará 5.5 horas para transferirlos a Parse.
b): vuelva a crear un archivo JSON desde la copia de seguridad de MySQL y use el Tablero para importar datos manualmente. Acabamos de probar con el archivo de 700,000 registros con este método: el indicador de carga tardó aproximadamente 2 horas en detenerse y mostrar el número de filas en el panel izquierdo, pero ahora nunca se abre en el panel derecho (dice "tiempo de espera de operación" ) y han pasado 6 horas desde que comenzó la carga.
Entonces, no podemos confiar en 1.b, y 1.a parece tardar mucho en recuperarse de un desastre (si tenemos 10 millones de registros, serán como 55 horas = 2.2 días).
Ahora estamos pensando en lo siguiente:
2) Constantemente replicar datos a otra aplicación
Cree lo siguiente en Parse: - Aplicación de producción: A - Aplicación de replicación: B Entonces, mientras A está en producción, todas las consultas se duplicarán en B (utilizando el trabajo en segundo plano constantemente). La desventaja es, por supuesto, que consumirá el límite de ráfaga de A, ya que simplemente duplicará la cantidad de consultas. Así que no es ideal pensar en ampliar.
Lo que queremos es algo como AWS RDS, que ofrece la opción de realizar copias de seguridad automáticas diarias. Me pregunto cómo podría ser difícil para Parse, ya que está basado en la infraestructura de AWS.
Por favor, avíseme si tiene alguna idea al respecto, estaré encantado de compartir nuestros conocimientos.
PD:
Hemos notado una falla importante en la idea anterior 2).
Si replicamos usando la API REST, todos los ObjectIds de todas las clases se cambiarán, por lo que cada relación 1to1 o 1 toMany se romperá.
Así que pensamos en poner un uuid para cada clase de objeto.
¿Hay algún problema con este método? Una cosa que queremos lograr es query.include (“ObjectName”) (o en Obj-C “includeKey”), pero supongo que eso no será posible si no basamos nuestra lógica de aplicación en objectId.
Buscando una solución para este problema; ¿pero la administración basada en uuid será funcional bajo la lógica del almacén de datos de Parse?
En diciembre de 2015, parse.com lanzó un nuevo panel con una función de exportación mejorada. Simplemente seleccione su aplicación, haga clic en "Configuración de la aplicación" -> "General" -> "Exportar datos de la aplicación". Parse genera un archivo json para cada clase en su aplicación y le envía un correo electrónico, si se realiza el progreso de exportación.
ACTUALIZAR:
Triste pero cierto, parse.com se está reduciendo: http://blog.parse.com/announcements/moving-on/
Para eliminaciones accidentales, escribir una función de nube ''antes'' eliminará la copia de seguridad de la fila actual a otra clase funcionaría.
Para copias de seguridad regulares, la exportación manual de registros modificados (filtro de uso) será útil. Para la recuperación, esto requiere que escriba scripts / use la opción de importación (no tan seguro) en el navegador de datos. También puede escribir una función de nube replicar datos en su servidor de respaldo (no lo he intentado todavía).
Sin embargo, hay algunas limitaciones al código de la nube que debe considerar antes de aventurarse en él: https://parse.com/docs/cloud_code_guide#functions-resource
Parse nunca ha perdido datos de producción. Si bien actualmente no ofrecemos copias de seguridad automáticas, puede solicitar una en cualquier momento que desee, y estamos trabajando para que todo esto sea aún mejor. Además, en la mayoría de los casos es más fácil importar el archivo de exportación JSON a través del navegador de datos en lugar de usar el lote REST.
Puedo confirmar que hoy, Parse perdió mis datos. O al menos eso parecía ser así.
Después de varios errores detectados en varias aplicaciones (de acuerdo con la cuenta de Twitter de Parse Status), no pudimos recuperar los datos de una aplicación sin ningún error.
Se debió a que una columna completa de una de nuestra clase (puntero de tipo) desapareció y los datos ya no estaban presentes en el panel.
Estamos utilizando esta columna de puntero para filtrar / recuperar datos, por lo que las consultas y colecciones devueltas estaban vacías.
Así que decidimos recrear la columna manualmente. Por casualidad, al recrear la columna, con el mismo nombre y tipo, se resolvió el problema y los datos aún estaban allí ... No puedo explicarlo, pero realmente pensé, y la aplicación reaccionó como si se hubieran perdido los datos.
Por lo tanto, una opción automatizada de copia de seguridad y restauración es obligatoria, no es una opción.
Tuve el mismo problema de hacer una copia de seguridad de los datos del servidor de análisis. Como el servidor Parse usa mongodb, es por eso que la copia de seguridad de los datos no es un problema, solo he hecho una cosa simple. descargado la copia de seguridad mongodb desde el servidor. Y luego lo restauró usando
mongorestore /path-to-mongodump (archivos extraídos)
Como el análisis se ha convertido en código abierto. Por lo tanto, podemos adoptar esta técnica.