使用CloudKit相对于CKRecord的CKReference性能

Question

假设我有一个CKRecord of recordType邮报。Post持有一些价值，如标题和描述。当Post显示在应用程序中时，它会附带写它的用户的名称和配置文件图片(让我们称他们为Writer)。我的问题是，- would更好地将一个CKReference存储到作者的配置文件中(配置文件是另一种保存作家详细信息的记录)，还是在他们编写它时直接将作者的详细信息添加到文章中会更好呢？

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

第一部分涉及所有岗位的加载。

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)
}

在这个函数中，我们花了时间获取引用In。然后，我们花时间进行概要文件的提取。请注意，所有这一切都是发生后，原来的邮政抓取！

...Yikes。即使有了某种缓存系统，原始的获取也会很疯狂(特别是对于很多用户)。

那么，在他们写文章的时候，直接把作者的细节添加到“邮报”上会更好吗？优点:抓取少，加载速度快。缺点:如果作者改变了他们的个人资料详细信息，应用程序将不得不循环遍历他们的所有帖子，并手动更新细节。

整个进退两难的局面都是你的毒药。有更好的方法吗？

Answer 1

您所描述的权衡的术语是去正规化。这就是你所描述的困境。权衡权衡取决于底层技术以及应用程序域和预期行为。

您已经描述了两个模型对象，一个Post和一个概要文件，其中一个Writer引用了一个Post上的配置文件。您还没有详细描述它们是如何使用的，但我将假设在表视图中滚动帖子列表，列表中的每个单元格上都有作者的名称和配置文件图片。这是很明显的，为什么你关心的是为每一个的引用。

CloudKit的优先级是尽量减少往返服务器的次数。但是，对posts进行一次提取和对链接的配置文件名称进行第二次提取并不特别繁琐。非常重要：在获取和查询时以及在可能的时候使用desiredKeys属性。默认情况下，CloudKit会获取整个记录，您可能会通过连线传递无关的信息--这是获取用户姓名和获取用户完整配置文件之间的区别。

在文档中，在可能的情况下使用desiredKeys的要点相对于其对优化的重要性和实现的简单性还不够。

但是，如果您担心在拉动帖子时是否响应，例如，如果用户将在您拉出更多时等待，您可能想要去造势。

我也会假设一个概要文件不会经常变化--这是一个关键的要点--但它可以改变，应用程序需要对此做出解释。这其实很简单:浏览帖子更新并不理想，但没什么大不了的，因为这是一件一次性的事情，你不希望经常发生。您应该能够使用一对CKQueryOperation/CKModifyRecordsOperation来完成这一任务。

同样，一定要使用desiredKeys --尤其是如果您只是为了更新每个帖子上的非规范化字段而不打算显示其中的任何一个，您不希望将每个帖子的全部内容传递给用户。

注意，如果您使用配置文件图片进行反美化，您可能希望确保您使用的是相同的CKAsset，这样您就可以在缓存中内置，并且不会意外地上下发送相同的图像，并存储大量时间。请参阅关于CKAsset和本地缓存工作方式的注意事项；显然，如果您希望保证本地存储它，您必须自己缓存它。

值得注意的是，所有这些CloudKit数据类型都不应该作为应用程序中的模型对象使用，这将如何与该层交互将影响您所做的任何选择。

CloudKit实际上很棒，但在我看来，它的不系统文档阻碍了它的发展。我很幸运，今年('16)去了WWDC，并能够与一些CloudKit工程师交谈，这就是其中一些信息的来源。希望这会有所帮助。