ios - 使用 CKReference 与 CKRecord 的 CloudKit 性能

Question

假设我有一个 CKRecord 的 recordType 帖子。帖子包含一些值，例如标题和描述。当应用程序中显示帖子时，它会附有撰写该帖子的用户(我们称他们为作者)的姓名和头像。我的问题是 - 将 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)
}

在该函数中，我们花时间获取 referenceID。然后我们花时间进行配置文件获取。请注意，所有这些都是在原始 Post 获取之后发生的!

...哎呀。即使使用某种缓存系统，原始提取也会很疯狂(尤其是对于很多用户)。

那么，写文章的时候直接把Writer的详细信息添加到Post中会不会更好呢？这样做的优点:更少的获取，更快的加载。缺点:如果作者更改了他们的个人资料详细信息，应用程序将不得不遍历他们的所有帖子并手动更新详细信息。

这整个困境充满了挑毒场景的味道。有更好的方法吗？

Answer 1

您描述的权衡术语是 denormalization .这是你描述的困境。权衡取舍取决于底层技术以及应用程序领域和预期行为。

您已经描述了两个模型对象，一个 Post 和一个 Profile，Writer 引用了一个 Post 上的 Profile。您还没有确切描述它们的使用方式，但我将假定为滚动的帖子列表，在表格 View 中，列表中的每个单元格上都有作者姓名和个人资料图片。很明显为什么您担心为每个人提取引用。

CloudKit 的首要任务是尽量减少到服务器的往返次数。但是，一次获取帖子和第二次获取链接的个人资料名称并不是特别繁重。 非常重要:在可能的情况下，尽可能在获取和查询时使用 desiredKeys 属性。 CloudKit 默认获取整个记录，您可能会通过线路传递无关信息——这是获取用户姓名和获取用户完整配置文件之间的区别。

尽可能使用 desiredKeys 的要点在文档中没有充分强调其优化的重要性和实现的简单性。

但是，如果您担心拉取帖子时的响应性，例如，如果用户在您拉取更多帖子时会等待，您可能需要非规范化。

我还假设配置文件不会经常更改——这是一个关键要点——但它可以更改并且应用程序需要考虑到这一点。这实际上非常简单:循环浏览帖子来更新它们并不理想，但这没什么大不了的，因为这是一次性的事情，您不希望经常发生。您应该能够使用一对 CKQueryOperation/CKModifyRecordsOperation 来完成它。

同样，一定要使用 desiredKeys——尤其是如果您只是获取更新每个帖子上的非规范化字段并且不打算显示其中的任何一个，您不希望通过网络传递每个帖子的全部内容。

请注意，如果您使用个人资料图片进行非规范化，您可能希望确保您使用的是相同的 CKAsset，这样您就可以使用内置缓存，并且不会不小心上下发送相同的图像并存储多次.查看有关 CKAsset 和本地缓存如何工作的警告；显然，如果您希望它保证存储在本地，您必须自己缓存它。

值得注意的是，所有这些 CloudKit 数据类型特别不应该用作您应用中的模型对象，并且它与该层的交互方式将影响任何选择你做。

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