Архитектура Couchdb: представления или документы?

Я пытаюсь изучить CouchDB, работая через простое веб-приложение для чтения RSS. Требования:

  • Разрешить каждому пользователю импортировать X каналов в свой список
  • Пользователь может добавлять теги к каждому каналу

  • Для каждого канала ведется список последних 50 статей в базе данных.

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

После прочтения различных руководств и Принципов моделирования документов CouchDB, который является отличным связанным вопросом здесь, как я себе это представляю:

  • Корма

    • Name
    • Последнее обновление

  • Статьи

    • FeedId
    • Заголовок
    • Текст

  • Пользователи

    • id
    • Каналы: [feed1, feed2]
    • Теги: {смешно: [article, article2]} // Может быть, новая база данных с #userid #articleid #tagname?

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

Я здесь на правильном пути? Как бы вы это структурировали?


database architecture couchdb database-design rss-reader
person Naren    schedule 12.05.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Как вы могли заметить, NoSQL - это компромисс, основанный на сценариях использования. В какой-то момент вам придется писать представления и запросы, а единого дизайна, подходящего для всех, не существует.

В вашем сценарии вы сказали, что каждый канал будет содержать только последние 50 статей, поэтому статьи быстро станут неактуальными (как и любые данные, связанные с ними). Таким образом, если вы храните теги в модели User, вам придется обновить объект пользователя три раза: 1, когда пользователь помечает статью, 2, когда пользователь удаляет тег, и 3, когда статья становится устаревшей и удаляется. 3 неизбежно.

Лучше хранить теги в статье, чтобы они удалялись вместе со статьей.

  • Корма

    • Name
    • Последнее обновление

  • Статьи

    • FeedId
    • Заголовок
    • Текст
    • Теги: {"tag-1": ["user1", "user2", ...], "tag2": ["user3", "user4", ...]}

  • Пользователи

    • id
    • Каналы: [feed1, feed2]

Как видите, я храню теги, сгруппированные по пользователям. Вы также можете сделать обратное { "user1" : "tag1", "user2" : "tag1", "user3" : "tag2", "user4" : "tag2", ... }, если считаете, что это помогает обработке (на основе ваших требований к фильтрации).

person Subhas    schedule 21.05.2013

arrow_upward
0
arrow_downward

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

Взаимодействия в модели чтения RSS фактически делают эту проблему не очень подходящей для CouchDB. Вы должны хранить индивидуальные теги, и вы (а) не хотите хранить их в пользовательском документе, потому что вам нужно постоянно обновлять пользовательский документ, и (б) не хотите хранить их в статье документы, потому что вам придется постоянно обновлять документы по статье.

Я думаю, что мое идеальное решение будет включать пользовательские базы данных; это сделало бы проблему легко разрешимой. У вас есть документы каналов и документы статей, и вы можете просто сохранить пользовательские теги в документах статей. Существует много дублирования (потому что вам нужно хранить статьи в каждой пользовательской базе данных), но, по крайней мере, это легко (и относительно быстро) запрашивать.

person djc    schedule 16.05.2013
comment
Я не думаю, что частое обновление документа CouchDB обязательно плохо, если вы не против сжатия базы данных и потери истории изменений. - person Teddy; 21.05.2013
comment
Это может привести к конфликтам документов, которые просто раздражает устранять. - person djc; 21.05.2013
comment
Я думаю, что базы данных для каждого пользователя - это излишек для этого. 50 статей на канал, и предположим, что в среднем пользователь подписывается на 10 каналов. Это 500 статей. Если статьи проиндексированы / разделены с помощью feed_id, запрос будет относительно недорогим. - person Subhas; 22.05.2013
comment
Ну что ж, я думаю, что я имею в виду дублирование документов статей для каждого пользователя. - person djc; 22.05.2013