Parse.com的现实数据备份方法

我们正在使用Parse.com构建iOS应用程序,但仍无法找到有效备份数据的正确方法.

作为前提,我们拥有并将拥有大量数据存储行.假设我们有一个100万行的类,假设我们备份它,然后想要在危险情况(如生产数据丢失)之后将其带回Parse.

我们考虑的几个解决方案如下:

1)使用外部服务器进行备份

备注: - 使用REST API不断将数据备份到远程MySQL服务器(我们选择MySQL进行自定义分析,因为使用MySQL处理数据的速度更快更容易)

ImportBack:a) - 从MySQL备份重新创建JSON对象,并使用REST API发送回Parse.假设我们使用批处理操作,允许使用1个查询创建50个同时对象,并假设每个查询需要1秒,1百万个数据集需要5.5小时才能转移到Parse.

b) - 从MySQL备份重新创建一个JSON文件,并使用仪表板手动导入数据.我们用这种方法尝试了700,000条记录文件:加载指示器停止并显示左侧窗格中的行数大约需要2小时,但现在它从未在右侧窗格中打开(它表示"操作超时" )自上传开始以来已超过6小时.

因此我们不能依赖1.b,而1.a似乎需要很长时间才能从灾难中恢复(如果我们有1000万条记录,那么它将像55小时= 2.2天).

现在我们考虑以下事项:

2)不断将数据复制到另一个应用程序

在Parse中创建以下内容: - 生产应用程序:A - 复制应用程序:B因此,当A处于生产阶段时,每个查询都将复制到B(不断使用后台作业).缺点当然是它会消耗A的突发限制,因为它只会使查询量增加一倍.所以不是理想的扩大规模.

我们想要的是类似AWS RDS的东西,它提供了每日自动备份的选项.我想知道这对Parse来说有多难,因为它基于AWS infra.

如果您对此有任何想法,请告诉我,很高兴分享诀窍.

PS:

我们已经注意到上述想法中的一个重要缺陷.

如果我们使用REST API进行复制,则所有类的所有objectIds都将被更改,因此每个1to1或1toMany关系都将被破坏.

所以我们考虑为每个对象类放置一个uuid.

这个方法有什么问题吗？我们想要实现的一件事是query.include("ObjectName")(或者在Obj-C"includeKey"中),但我想如果我们不将我们的app逻辑基于objectId,那将是不可能的.

寻找解决此问题的方法; 但是,基于uuid的管理能否在Parse的数据存储逻辑下运行？