Question

我正在尝试一些不同的选项来在RavenDB中以有效的方式设计和存储文档结构。

我正在处理用户的结构是会话和活动跟踪信息。

当用户登录系统并开始创建活动时，将启动会话。每个会话可能有数百个活动。当用户关闭/注销时，会话结束。

使场景稍微复杂化的一个因素是会话实时显示在门户网站中。换句话说：我需要跟踪会话和活动并将它们关联起来，以便能够确定它们是否正在进行（以及它们已经运行了多长时间），或者它们是否已完成。

你也可以在历史中挖掘。

我做了一些研究，发现堆栈溢出的两个相关问题，但没有一个真正帮助我： Document structure for RavenDB Activity stream design with RavenDb

我成功飙升的两个选项是:(简化结构）

1：

{
  "User": "User1",
  "Machine": "machinename",
  "StartTime": "2012-02-13T13:11:52.0000000",
  "EndTime": "2012-02-13T13:13:54.0000000",
  "Activities": [
    {
      "Text": "Loaded Function X",
      "StartTime": "2012-02-13T13:12:10.0000000",
      "EndTime": "2012-02-13T13:12:10.0000000"
    },
    {
      "Text": "Executed action Z",
      "StartTime": "2012-02-13T13:12:10.0000000",
      "EndTime": "2012-02-13T13:12:10.0000000"
    }
}

2：

{
  "Session" : "SomeSessionId-1",
  "User": "User1",
  "Machine": "machinename",
  "Text": "Loaded Function X",
  "StartTime": "2012-02-13T13:12:10.0000000",
  "EndTime": "2012-02-13T13:12:10.0000000"
}

{
  "Session" : "SomeSessionId-1",
  "User": "User1",
  "Machine": "machinename",
  "Text": "Executed action Z",
  "StartTime": "2012-02-13T13:12:10.0000000",
  "EndTime": "2012-02-13T13:12:10.0000000"
}

替代方案1感觉更自然，来自关系背景，加载会话，添加事件和存储非常简单。每次加载Session对象和附加事件的开销对插入性能都非常不利。

替代方案2感觉更有效率，我可以简单地追加事件（几乎像事件采购）。但是，在事件中挖掘并在每个会话中显示它们时的选择会变得更复杂。

是否还有第三种更好的选择？解决方案是否可以分离事件并创建另一个读取模型？我是否过分复杂了这个问题？

Answer 1

看起来您只需要一个用户文档和一个会话文档。为“User”和“Session”创建两个模型。会话doc将userid作为一个属性。会话也将嵌套“活动”属性。在这种情况下，很容易显示实时用户 - 会话 - 活动。在不了解更多细节的情况下，我过度简化了课程。

编辑：

//Sample User Document

{
  UserId:"ABC01",
  HomeMachine:"xxxx",
  DateCreated:"12/12/2011"
}


//Sample Session Document

{
  UserId:"ABC01",
  Activities
    {
      Activity 1 properties
    }
    {
      Activity 2 properties
    }
    ...
    ...
    etc..

}

Answer 2

我绝对认为你应该使用选项2的一些变体。选项1中的文档是否会变得非常大？这可能会使插入非常慢。我真的不明白为什么每个会话的显示事件在选项2中比在选项1中更复杂，你可以通过会话选择事件

session.Query<Event>().Where(x => x.Session == sessionId)

并且RavenDB会自动为它创建索引。如果你想制作更复杂的查询，你总是可以为它创建更专业的索引。

文件设计

2 个答案: