Дизайн документа - PullRequest
Новая
       8

Дизайн документа

1 голос
/ 17 февраля 2012

Я пробую несколько различных вариантов для разработки и сохранения структуры документа эффективным способом в RavenDB.

Структура, с которой я работаю, это информация об отслеживании сеанса и активности.

Сессия запускается, когда пользователь входит в систему, и действия начинают создаваться. Там может быть сотни мероприятий за сеанс. Сеанс заканчивается, когда пользователь закрывается / выходит из системы.

Фактор, который немного усложняет сценарий, заключается в том, что сеансы отображаются на веб-портале в режиме реального времени. Другими словами: мне нужно следить за сессией и действиями и соотносить их, чтобы иметь возможность выяснить, продолжаются ли они (и как долго они выполняются), или они выполнены.

Вы также можете копаться в истории, конечно.

Я провел некоторое исследование и нашел здесь два важных вопроса о переполнении стека, но ни один из них не помог мне: Структура документа для RavenDB Проектирование потока активности с 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 кажется гораздо более эффективной, я могу просто добавлять события (почти как источники событий). Но выбор при копании в событиях и отображении их за сеанс становится немного сложнее.

Возможно, существует третья лучшая альтернатива? Может ли быть решение отделить события и создать другую модель чтения? Я слишком усложняю проблему?

Ответы [ 2 ]

0 голосов
/ 17 февраля 2012

Я определенно думаю, что вы должны пойти с некоторым вариантом варианта 2. Разве документы не станут очень большими в варианте 1? Это, вероятно, сделает вставки очень медленными. Я не могу понять, почему показ событий за сеанс был бы более сложным в варианте 2, чем в варианте 1, вы можете просто выбрать события по сеансу с помощью 

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

и RavenDB автоматически создаст для него индекс. И если вы хотите делать более сложные запросы, вы всегда можете создать более специализированные индексы для этого.

0 голосов
/ 17 февраля 2012

Похоже, вам просто нужен документ пользователя и документ сеанса. Создайте две модели для «Пользователь» и «Сессия». Документ сеанса будет иметь идентификатор пользователя в качестве одного свойства. Сессия также будет иметь вложенные свойства "активность". В этом случае будет легко показывать пользователям - сеансам - действия в реальном времени. Не зная больше деталей, я переборщил.

EDIT: 

//Sample User Document

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


//Sample Session Document

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

}
...