Дизайн документа CouchDB для ребер в направленном и взвешенном графе с отметками времени

Я немного борюсь с «лучшим» дизайном для хранения «графических» данных в Couchdb/pouchdb. У меня есть движения/трафик определенной суммы в определенное время между узлами, которые я хочу сохранить, поэтому это немного похоже на ориентированный и взвешенный график с временными метками.

Каждая часть данных имеет:

  • временная метка
  • количество
  • источник
  • цель

У меня есть вопросы, на которые я хочу ответить с помощью этих данных:

  • каковы последние движения X?
  • какие движения происходят на конкретном таймфрейме?
  • каков вход и выход узла N (в определенный период времени)?
  • что такое вход и выход в наборе узлов N, N1, .. (в конкретном таймфрейме)?

Итак, как хранить данные в CouchDB, чтобы я мог отвечать на вопросы и использовать большинство мощных функций и особенностей CouchDB?

С моей текущей точки зрения у меня есть два варианта: сохранить все, кроме суммы, в _id, или создать _id только с отметкой времени и использовать дополнительные значения для суммы, источника и цели.

Для первого решения можно было бы построить функции просмотра, как здесь, и документ может выглядеть так:

{
"_id":    "app:movement:at:20150517T154200:from:node:aaaa:to:node:bbbb",
"amount":  123456
},

для второго решения документы могут выглядеть так:

{
"_id":    "app:movement:at:20150517T154200", # maybe plus random value
"from":   "aaaa",
"to":     "bbbb",
"amount":  123456
}

функции представления не будут использовать регулярные выражения, как в первом примере, но будут иметь прямой доступ к значениям.

Что более "chouchdb-ish"? Что бы вы сделали? что более перспективно?

Спасибо за внимание.


couchdb pouchdb
person robert    schedule 17.05.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Я бы рекомендовал определить значения _id как UUID. Ваше решение имеет преимущества в одном единственном случае использования: когда вы хотите использовать первичный индекс _all_docs для запроса данных, например. по соображениям производительности. Но это сильно ограничит варианты использования для обработки ваших данных.

Примерная структура документа может быть

{
  "_id":    "", // UUID
  "from":   "",
  "to":     "",
  "amount":  ,
  "timestamp": "", // ISO8601
  "type": "movement"
}

Теперь вы хотите запросить данные:

каковы последние движения X?

С видом с doc.timestamp в качестве ключа вы можете спросить

_view/viewname?descending=true&limit=3

чтобы получить последние 3 движения.

какие движения происходят на конкретном таймфрейме?

С видом с doc.timestamp в качестве ключа вы можете спросить

_view/viewname?startkey=:timestamp1&endkey=:timestamp

чтобы получить движения в этот период времени.

каков вход и выход узла N (в определенный период времени)?

Это работает так же при обработке меток времени, но вам понадобится представление со сложным ключом. Ваше представление может генерировать номинальный пример:

emit([doc.from,doc.timestamp], null)
emit([doc.to,doc.timestamp], null)

Теперь вы можете добавить узел к запросам, отфильтрованным по таймфрейму.

что такое вход и выход в наборе узлов N, N1, .. (в конкретном таймфрейме)?

Это то же самое, что и предыдущий вариант использования. Но запрашивать данные нескольких узлов в одном запросе можно только тогда, когда имена узлов расположены в индексе бок о бок. В противном случае вам потребуется несколько запросов к CouchDB.

person Ingo Radatz    schedule 24.05.2015