问一种实用的Parse.com数据备份方法

EN

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

作为前提，我们已经并将拥有大量的数据存储行。假设我们有一个有100万行的类，假设我们已经备份了它，然后想要在发生危险情况(比如生产中的数据丢失)后将它带回Parse。

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

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

BackUp：-使用REST API不断地将数据备份到远程MySQL服务器(我们选择MySQL是为了进行自定义分析，因为对于我们来说，使用MySQL处理数据更快、更容易)

ImportBack: a) -从MySQL备份中重新创建JSON对象，并使用REST API发送回解析。假设我们使用批处理操作，允许使用一个查询同时创建50个对象，并假设每个查询需要1秒，100万个数据集将需要5.5小时才能传输到Parse。

b) -从MySQL备份中重新创建一个JSON文件，并使用仪表板手动导入数据。我们刚刚用这种方法尝试了700,000个记录文件:加载指示器大约花了2个小时才停止并显示左窗格中的行数，但现在它再也不会在右窗格中打开(它显示“操作超时”)，并且距离上传开始已经超过6个小时了。

所以我们不能依赖1.b，1.a似乎需要太长时间才能从灾难中恢复(如果我们有1000万条记录，就像55小时= 2.2天)。

现在我们考虑以下几点：

2)不断将数据复制到其他应用程序

在Parse中创建以下内容：- production App: A- Replication App: B因此，当A处于生产状态时，每个查询都会复制到B中(不断使用后台作业)。当然，缺点是它会消耗掉A的突发限制，因为它只会使查询量翻一番。所以扩大规模的想法并不理想。

我们想要的是像AWS RDS这样的东西，它提供了一个每天自动备份的选项。我想知道这对Parse来说有什么困难，因为它是基于AWS基础设施的。

请让我知道，如果你对此有任何想法，将很高兴分享技术诀窍。

附言：

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

如果我们使用REST API进行复制，那么所有类的所有objectIds都将被更改，因此每一个1to1或1toMany关系都会被破坏。

因此，我们考虑为每个对象类添加一个uuid。

这种方法有什么问题吗？我们想要实现的一件事是query.include(“ObjectName”)(或者在Obj-C中是“includeKey”)，但是我想如果我们不把应用程序逻辑建立在objectId之上，这是不可能的。

正在寻找解决此问题的方法；但基于uuid的管理在Parse的数据存储逻辑下是否有效？