我们正在使用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的数据存储逻辑下是否有效?
https://stackoverflow.com/questions/24648784
复制相似问题