Question

我想使用DocumentDB构建异构元素的用户活动供稿。

我根据这个链接考虑了3个建模场景：

https://github.com/Azure/azure-content/blob/master/articles/documentdb/documentdb-modeling-data.md#when-not-to-embed

每个用户使用嵌套数组Feed元素的单个文档

{
"userId": "1",    
"feed": [
    {"id": 1, "author": "anon", "image": "https://image.com/y.jpg"},
    {"id": 2, "author": "bob", "status": "wisdom from the interwebs"},
    …
    {"id": 100001, "author": "jane", "quote": "and on we go ..."},
    …
    {"id": 1000000001, "author": "angry", "status": "blah angry blah angry"},
    …
    {"id": ∞ + 1, "author": "bored", "xxx": "oh man, will this ever end?"}
    ]
}

似乎不好的情况因为Document有一些大小限制，所以它不可扩展。

每个Feed元素一个文档

{
"userId": "1",    
"id": 1, 
"author": "anon", 
"image": "https://image.com/y.jpg"
},
{
"id": 2,
"author": "bob", 
"status": "wisdom from the interwebs"
},...

似乎很好的解决方案，但我觉得浪费了DocumentDB的潜力，太过平了？也许没有优化。

包含1个嵌套数组Feed元素的X文档

{
"userId": 1
"feed": [
    {"id": 4, "author": "anon", "image": "https://image.com/y.jpg"},
    {"id": 5, "author": "bob", "status": "tails from the field"},
    ...
    {"id": 99, "author": "angry", "status": "blah angry blah angry"}
]
},
{
"userId": 1
"feed": [
    {"id": 100, "author": "anon", "status": "yet more"},
    ...
    {"id": 199, "author": "bored", "xxx": "will this ever end?"}
]
}

似乎是最好的解决方案，但在代码中添加了很多复杂性（处理删除操作和分页，处理具有不同Feed类型的WHERE子句......）。我想在功能部分（分页）中加入存储架构。不太灵活。

显然，方案1不是一种选择。您如何看待方案2和3？

Answer 1

根据我的经验，使用DocumentDb（考虑当前的限制）保持简单的回报。场景2允许以最直接的方式管理CRUD操作，并保持代码简单。看来，使用第三种方法，您需要不断检查文档累积的大小，这也很麻烦。

话虽如此，如果要使用批量插入，请记住，对于它，您还需要对批处理中发送的记录数进行分区（即使使用方案2），因为存储的proc调用限制为512 kb同样。

根据我的经验，文档结构在DocumentDb中非常强大，只要它们可以描述一条信息作为一个整体来看待。如果你需要查看不同文档的嵌套部分 - 连接和存储过程可以帮助解决这个问题。

希望这个有用，尽管在这篇文章中有任何个人意见：）

如何建模DocumentDB中的元素列表？

1 个答案: