使用CKReference与CKRecord的CloudKit性能

时间:2016-07-06 17:51:11

标签: ios swift schema cloudkit

假设我有一个CKRecord recordType帖子。帖子保留一些值,如标题和描述。当帖子显示在应用程序中时,它会附有编写它的用户的姓名和个人资料图片(让我们称之为Writer)。我的问题是 - 将CKReference存储到Writer的配置文件(配置文件是另一种包含Writer详细信息的记录)会不会更好,或者在写入时直接将Writer的详细信息添加到Post中会更好它?

从数据库架构的角度来看,第一个选项非常有意义,但从性能角度来看,这似乎非常糟糕。在这个系统上有成千上万的用户,提取的数量和加载它们的时间似乎都是不合理的。

第一部分涉及加载所有帖子。

func loadPosts() {
    // ...Setup the query
    publicData.performQuery(query, inZoneWithID: nil) { (results: [CKRecord]?, error: NSError?) in
        if let posts = results {
            self.loadProfiles(posts)
        }
    }
}

完成了一个查询,现在我们调用了loadProfiles

func loadProfiles(posts: [CKRecord]) {
    // Get the reference IDs out of the Posts
    var referenceIDs = [CKRecordID]()
    for post in posts {
        // Get the reference from the post
        // Append the recordID to the referenceIDs array
    }

    // Perform the Profiles fetch
    let fetchOperation = CKFetchRecordsOperation(recordIDs: referenceIDs)
    fetchOperation.fetchRecordsCompletionBlock = { records, error in
        // ...Handle the fetched Profiles

        // Everything has been fetched, update the UI now
        dispatch_async(dispatch_get_main_queue(), {
            self.tableView.reloadData()
        })
    }
    CKContainer.defaultContainer().publicCloudDatabase.addOperation(fetchOperation)
}

在该功能中,我们花时间抓取referenceID。然后我们花时间做了Profile fetch。请注意,所有这一切都发生在原始的Post fetch之后!

...让人惊讶。即使使用某种缓存系统,原始获取也会很疯狂(特别是对于大量用户而言)。

那么,在写作时直接将Writer的详细信息添加到Post中会不会更好?优点:减少提取,加载更快。缺点:如果Writer更改了他们的个人资料详细信息,应用程序将必须遍历所有帖子并手动更新详细信息。

这种完全的困境令人厌恶你的毒药情景。有更好的方法吗?

1 个答案:

答案 0 :(得分:5)

您所描述的权衡术语是denormalization。这是你描述的两难境地。权衡权衡取决于底层技术以及应用领域和预期行为。

您已经描述了两个模型对象,一个帖子和一个配置文件,以及一个帖子上的个人资料的Writer引用。您还没有准确描述它们的使用方式,但我会假设在表格视图中使用列表中每个单元格的作者姓名和个人资料图片作为滚动列表。很明显,为什么你担心为每一个引用参考文献。

CloudKit的优先级是最小化到服务器的往返次数。但是,对帖子进行一次抓取和对链接的个人资料名称进行第二次抓取并不特别繁琐。 非常重要:在此处使用desiredKeys属性进行提取和查询,并尽可能使用。默认情况下,CloudKit会获取整个记录,您可能会通过网络传递无关的信息 - 这是获取用户和获取用户之间的区别。命名和获取用户'完整档案。

在文档中,尽可能使用desiredKeys的点与其优化的重要性以及实现的简单性相比并不足够。

但是,如果您担心在提取帖子时会有响应,例如,如果用户在您拉出更多内容时要等待,则可能需要进行非规范化。

我也会假设个人资料不会经常变化 - 这是一个关键的重点 - 但它可以改变,应用程序需要考虑到这一点。它实际上非常简单:通过帖子来更新它们并不理想,但这并不是什么大不了的事情,因为它是一次性的事情,你不会这样做#39期望经常发生。您应该可以使用一对CKQueryOperation / CKModifyRecordsOperation来完成它。

再一次,请务必使用desiredKeys - 特别是如果您只是想要更新每个帖子上的非规范化字段并且不打算展示其中的任何一个,那么就不要使用{39}。 ; t想要通过电线传递每个帖子的全部内容。

请注意,如果使用个人资料图片进行非规范化,您可能需要确保使用相同的CKAsset,这样就可以内置缓存,并且不会意外地上下相同的图像并存储一堆时间。请参阅有关CKAsset和本地缓存如何工作的警告;显然,如果你希望它保证在本地存储,你必须自己缓存它。

值得注意的是,所有这些CloudKit数据类型特别不应该用作应用中的模型对象,以及它将如何与该层交互影响你做出的任何选择。

CloudKit实际上很棒,但在我看来,它被非系统性的文档所阻碍。我很幸运今年去了WWDC(' 16)并且能够与一些CloudKit工程师交谈,这是其中一些信息的来源。希望这可以帮助。