在键值存储中保存带有修订的文档的最佳方法是什么？

Question

我是键值存储新手，需要您的推荐。我们正在开发一个管理文档及其修订的系统。有点像维基百科。我们正在考虑将这些数据保存在键值存储中。

请不要给我推荐您喜欢的数据库，因为我们想破解它，以便我们可以使用许多不同的键值数据库。我们使用node.js，因此我们可以轻松地使用json。

我的问题是：数据库的结构应该是什么样的？我们有每个文档的元数据（时间戳、最后文本、id、最新版本），并且我们有每个修订的数据（更改、作者、时间戳等）。那么，您推荐哪种键/值结构？

谢谢

Answer 1

摘自 MongoDB 群组。它有些特定于 MongoDB，但是非常通用。

大多数历史实现都分为两种常见策略。

策略 1：嵌入历史记录

理论上，您可以将文档的历史记录嵌入到文档本身中。这甚至可以原子地完成。

> db.docs.save( { _id : 1, text : "Original Text" } ) 
> var doc = db.docs.findOne() 
> db.docs.update( {_id: doc._id}, { $set : { text : 'New Text' }, $push : { hist : doc.text } } ) 
> db.docs.find() 
{ "_id" : 1, "hist" : [ "Original Text" ], "text" : "New Text" } 

策略 2：将历史记录写入单独的集合

> db.docs.save( { _id : 1, text : "Original Text" } ) 
> var doc = db.docs.findOne() 
> db.docs_hist.insert ( { orig_id : doc._id, ts : Math.round((new Date()).getTime() / 1000), data : doc } ) 
> db.docs.update( {_id:doc._id}, { $set : { text : 'New Text' }  } ) 

在这里您将看到我执行了两次写入。一件到大师收藏和
一份历史收藏。
要快速查找历史记录，只需获取原始 ID：

> db.docs_hist.ensureIndex( { orig_id : 1, ts : 1 }) 
> db.docs_hist.find( { orig_id : 1 } ).sort( { ts : -1 } )

---

• 两种策略都可以通过仅显示差异来增强
• 您可以通过添加从 历史集合 到 原始集合 的链接来进行混合

在键值存储中保存带有修订的文档的最佳方式是什么？

很难说有一个“最好的方法”。显然这里需要做出一些权衡。

嵌入：

• 单个文档的原子更改
• 可能会导致大型文档，可能会打破合理的大小限制，
• 可能必须增强代码以避免在不必要时返回完整的历史记录

单独集合：

• 更容易编写
• 非原子查询，需要两个操作（你有事务吗？）
• 更多的存储空间（原始文档上的额外索引）

Answer 2

我会在每个文档下保留真实数据的层次结构，并附加修订数据，例如：

{ 
  [
    {
      "timestamp" : "2011040711350621",
      "data" : { ... the real data here .... }
    },
    {
      "timestamp" : "2011040711350716",
      "data" : { ... the real data here .... }
    }
  ]
}

然后使用推送操作添加新版本并定期删除旧版本。您可以使用最后一个（或第一个）过滤器在任何给定时间仅获取最新副本。

Answer 3

我认为有多种方法，而且这个问题很老了，但我会给出我的两分钱，因为我今年早些时候正在研究这个问题。我一直在使用 MongoDB。

就我而言，我有一个用户帐户，然后在不同的社交网络上有个人资料。我们想要跟踪社交网络配置文件的更改并希望对其进行修改，因此我们创建了两个结构来进行测试。两种方法都有一个指向外来对象的 User 对象。我们不想从一开始就嵌入对象。

用户看起来像这样：

User {
  "tags"              : [Tags]
  "notes"             : "Notes"
  "facebook_profile"  : <combo_foreign_key>
  "linkedin_profile"  : <same as above>
}

然后，对于combo_foreign_key，我们使用了这种模式（为了简单起见，使用 Ruby 插值语法）

combo_foreign_key = "#{User.key}__#{new_profile.last_updated_at}"

facebook_profiles {
  combo_foreign_key: facebook_profile
  ... and you keep adding your foreign objects in this pattern
}

这为我们提供了 O(1) 查找用户的最新 FacebookProfile，但要求我们将最新的 FK 存储在用户对象。如果我们想要所有 FacebookProfiles，我们会要求 facebook_profiles 集合中带有“#{User.key}__”前缀的所有键，这是 O(N)...

我们尝试的第二个策略是存储一个数组用户对象上的那些 FacebookProfile 键，因此用户对象的结构从 更改为

  "facebook_profile"  : <combo_foreign_key>

这里

  "facebook_profile"  : [<combo_foreign_key>]

，当我们添加新的配置文件变体时，我们只需附加新的组合键。然后我们只需对“facebook_profile”属性进行快速排序，并在最大的属性上建立索引即可获取最新的个人资料副本。此方法必须对 M 个字符串进行排序，然后根据排序列表中最大的项目对 FacebookProfile 进行索引。获取最新副本的速度有点慢，但它给了我们一次性了解用户 FacebookProfile 的每个版本的优势，而且我们不必担心确保foreign_key确实是最新的配置文件对象。

起初，我们的修订次数非常少，而且效果都很好。我想我现在更喜欢第一个而不是第二个。

希望得到其他人关于解决这个问题的方法的意见。另一个答案中建议的 GIT 想法实际上对我来说听起来非常好，对于我们的用例来说会工作得很好......酷。