使用CKReference与CKRecord的CloudKit性能

Question

比方说,我有一个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更改了他们的个人资料详细信息,该应用程序将必须遍历所有帖子并手动更新详细信息.

这种完全的困境令人厌恶你的毒药情景.有一个更好的方法吗？

Answer 1

您所描述的权衡术语是非规范化.这是你描述的困境.权衡权衡取决于底层技术以及应用领域和预期行为.

您已经描述了两个模型对象,Post和Profile,以及对Post上的Profile的Writer引用.您还没有准确描述它们是如何被使用的,但是我将假设在表格视图中滚动列表的帖子,列表中每个单元格上的作者姓名和个人资料图片.很明显,为什么你担心为每一个提取引用.

CloudKit的首要任务是最大限度地减少到服务器的往返次数.但是,对帖子进行一次提取和对链接的配置文件名称进行第二次提取并不是特别麻烦.非常重要:desiredKeys在此处使用属性进行提取和查询,并且尽可能使用.默认情况下,CloudKit会获取整个记录,您可能会通过网络传递无关信息 - 这是获取用户名称和获取用户完整配置文件之间的区别.

desiredKeys在文档中,尽可能使用的点与其优化的重要性以及实现的简单性相比并未在家中得到足够的重视.

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

我也将假设一个配置文件不会经常更改 - 这是一个关键的重点 - 但它可以更改,应用程序需要考虑到这一点.它实际上非常简单:通过帖子来更新它们并不理想,但这并不是什么大不了的事情,因为它是一种一次性的事情,你不希望经常发生.您应该可以使用一对CKQueryOperation/CKModifyRecordsOperation来完成它.

再一次,一定要使用desiredKeys- 特别是如果你只是想要更新每个帖子上的非规范化字段并且不打算显示任何一个,你不想通过网络传递每个帖子的全部内容.

请注意,如果使用配置文件图片进行非规范化,则可能需要确保使用相同的CKAsset,因此内置缓存,并且不会意外地上下相同的图像并存储多次.请参阅有关CKAsset和本地缓存如何工作的警告; 显然,如果你希望它保证在本地存储,你必须自己缓存它.

值得注意的是,所有这些CloudKit数据类型都不应该被用作应用程序中的模型对象,以及它与该层交互的方式将影响您所做的任何选择.

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