dcc*_*dcc 19 backup datastore parse-platform
我们正在使用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的数据存储逻辑下运行？
Parse 从未丢失过生产数据.虽然我们并不目前提供自动备份,你可以要求一个你喜欢的任何时间,我们正在做这一切甚至更好的工作.此外,在大多数情况下,通过数据浏览器而不是使用REST批处理导入JSON导出文件更容易.
我可以确认，今天 Parse 确实丢失了我的数据。或者至少看起来是这样。
在多个应用程序上检测到几个错误（由 Parse Status twitter 帐户同意）后，我们无法检索应用程序的数据，没有任何错误。
这是因为我们的一个类（类型指针）的一整列消失了，仪表板中不再存在数据。
我们使用这个指针列来过滤/检索数据，所以返回的查询和集合是空的。
所以我们决定手动重新创建列。偶然地，重新创建具有相同名称和类型的列，解决了问题，数据仍然存在......我无法解释，但我真的想过，应用程序的反应就像数据丢失一样。
所以自动备份和恢复选项是强制性的，它不是一个选项。