Parse.com 的真实数据备份方法 [英] Realistic Data Backup method for Parse.com
问题描述
我们正在使用 Parse.com 构建一个 iOS 应用程序，但仍然无法找到有效备份数据的正确方法.
作为前提，我们有并将有很多数据存储行.假设我们有一个包含 100 万行的类，假设我们已经对其进行了备份，然后在出现危险情况(例如生产中的数据丢失)后想要将其带回 Parse.
我们考虑过的几个解决方案如下:
1) 使用外部服务器进行备份
备份:- 使用 REST API 不断地将数据备份到远程 MySQL 服务器(我们选择 MySQL 来进行自定义分析，因为它对我们来说使用 MySQL 处理数据更快、更容易)
导入返回:a) - 从 MySQL 备份重新创建 JSON 对象并使用 REST API 发送回 Parse.假设我们使用批处理操作，允许使用 1 个查询同时创建 50 个对象，并假设每个查询需要 1 秒，100 万个数据集将需要 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 基础设施.
如果您对此有任何想法，请告诉我，我们很乐意分享诀窍.
附:
我们注意到上述 2) 想法中的一个重要缺陷.
如果我们使用 REST API 进行复制，所有 Classes 的所有 objectIds 都会改变，因此每一个 1to1 或 1toMany 关系都会被破坏.
所以我们考虑为每个对象类放置一个 uuid.
这个方法有问题吗?我们想要实现的一件事是query.include(对象名称")(或在 Obj-C 中的includeKey")，但我想，如果我们的应用逻辑不基于 objectId，那这将是不可能的.
正在寻找解决此问题的方法；但是基于 uuid 的管理在 Parse 的 Datastore 逻辑下会起作用吗?
我可以确认，今天 Parse 确实丢失了我的数据.或者至少看起来是这样.
在多个应用程序上检测到多个错误(由 Parse Status 推特帐户同意)后，我们无法检索应用程序的数据，没有任何错误.
这是因为我们的一个类(类型指针)的一整列消失了，并且仪表板中不再存在数据.
我们使用这个指针列来过滤/检索数据，所以返回的查询和集合是空的.
因此我们决定手动重新创建该列.偶然地，重新创建具有相同名称和类型的列，解决了问题，数据仍然存在......我无法解释，但我真的想到了，应用程序的反应就像数据丢失一样.
因此自动备份和恢复选项是强制性的，它不是一个选项.
We are building an iOS app with Parse.com, but still can't figure out the right way to backup data efficiently.
As a premise, we have and will have a LOT of data store rows. Say we have a class with 1million rows, assume we have it backed up, then want to bring it back to Parse, after a hazardous situation (like data loss on production).
The few solutions we have considered are the following:
1) Use external server for backup
BackUp: - use the REST API to constantly back up data to a remote MySQL server (we chose MySQL for customized analytics purpose, since it's way faster and easier to handle data with MySQL for us)
ImportBack: a) - recreate JSON objects from MySQL backup and use the REST API to send back to Parse. Say we use the batch operation which permits 50 simultaneous objects to be created with 1 query, and assume it takes 1 sec for every query, 1million data sets will take 5.5hours to transfer to Parse.
b) - recreate one JSON file from MySQL backup and use the Dashboard to import data manually. We just tried with 700,000 records file with this method: it took about 2 hours for the loading indicator to stop and show the number of rows in the left pane, but now it never opens in the right pane (it says "operation time out") and it's over 6hours since the upload started.
So we can't rely on 1.b, and 1.a seems to take too long to recover from a disaster (if we have 10 million records, it'll be like 55 hours = 2.2 days).
Now we are thinking about the following:
2) Constantly replicate data to another app
Create the following in Parse: - Production App: A - Replication App: B So while A is in production, every single query will be duplicated to B (using background job constantly). The downside is of course that it'll eat up the burst limit of A as it'll simply double the amount of query. So not ideal thinking of scaling up.
What we want is something like AWS RDS which gives an option to automatically backup daily. I wonder how this could be difficult for Parse since it's based on AWS infra.
Please let me know if you have any idea on this, will be happy to share know-hows.
P.S.:
We’ve noticed an important flaw in the above 2) idea.
If we replicate using REST API, all the objectIds of all Classes will be changed, so every 1to1 or 1toMany relations will be broken.
So we think about putting a uuid for every object class.
Is there any problem about this method? One thing we want to achieve is query.include("ObjectName") ( or in Obj-C "includeKey"), but I suppose that won’t be possible if we don’t base our app logic on objectId.
Looking for a work around for this issue; but will uuid-based management be functional under Parse’s Datastore logic?
I can confirm that today, Parse did lost my data. Or at least it appeared to be so.
After several errors where detected on multiple apps (agreed by Parse Status twitter account), we could not retrieve data for an app, without any error.
It was because an entire column of one of our class (type pointer) disappeared and data was not present anymore in the dashboard.
We are using this pointer column to filter / retrieve data, so the returned queries and collections were empty.
So we decided to recreate the column manually. By chance, recreating the column, with the same name and type, solved the issue and the data was still there... I can't explain it but I really thought, and the app reacted as if, data were lost.
So an automated backup and restore option is mandatory, it is not an option.
这篇关于Parse.com 的真实数据备份方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
