1

问题

从 nosql 文档数据库开始，我发现了很多新的可能性，但是，我看到了一些陷阱，我想知道如何处理它们。

假设我有一个产品，这个产品可以在很多地区销售。每个区域都有一个负责人（可以访问 CMS）。每个负责人都会相应地修改产品的区域法律和规则。

由于在关系数据库中不支持加入功能，因此文档的设计方式应包含构建选择语句和选择结果所需的所有信息，以避免往返数据库。

所以我的第一个想法是设计一个或多或少遵循这种结构的文档：

{
   type : "product",
   id : "product_id",
   title : "title",
   allowedAge : 12,
   regions : {
      'TX' : {
         title : "overriden title",
         allowedAge : 13
      },
      'FL' : {
         title : "still another title"
      }
   }
}

但我的印象是，这种方法会在更新文档时产生冲突。假设我们有很多用户通过 CMS 更新大量文档。当更新同一个文档时，最后一次更新会覆盖之前所做的更新，即使用户也只能修改该文档的片段（在这种情况下，负责人应该只能修改区域数据）。

如何处理这种情况？

我想到的一种可能的解决方案是部分文档更新。正面：减少来自不同操作的数据覆盖，负面：如果对文档而不是此类片段进行锁定，则会失去乐观锁定功能。

有没有另一种方法来解决这个问题？

4

2 回答 2

5

在这种情况下，您可以使用 3 种解决方案：

  1. 保留当前文档结构并始终检查更新操作的 CAS 值。如果 CAS 不匹配 - 再次调用 store 函数。（但正如你所说，如果你有很多用户，它可能会很慢）。

  2. 将文档分成几个可以独立更新的部分，然后在应用端将它们组合在一起。这将导致视图调用增加（一个用于获取主文档，另一个用于获取 ie 区域等）。如果你有很多“部分”，它也会降低性能。

  3. 请参阅此文档。这是关于模拟 couchbase 中的连接。@Tug Grall也写了一个很好的例子。

于 2013-08-02T12:19:33.823 回答
1

如果您不限于使用 Couchbase（从您的问题中不清楚它是通用的还是特定的）- 也请查看 MongoDB。它支持文档的部分更新以及其他原子操作（如增量和数组操作），因此它可能更适合您的用例（在 mongo 上查看可能的更新操作 - http://docs.mongodb.org/manual/core/update / )

于 2013-08-05T14:13:03.007 回答