Мне нужен совет по поводу NoSQL / MongoDB и структуры данных / моделей

Question

Недавно я изучаю базы данных NoSQL.Мне нужен совет о том, как хранить данные наиболее оптимальным и эффективным способом для данной проблемы.Теперь я нацелен на MongoDB.Однако то же самое должно быть и с CouchDB.

Допустим, у нас есть эти 3 Модели:

Story:
 id
 title

User:
 id
 name

Vote:
  id
  story_id
  user_id

Я хочу иметь возможность задавать базе данных эти вопросы:

• Кто проголосовал за эту Историю?
• За что проголосовал этот Пользователь?

Я выполняю простые объединения при работе с реляционной базой данных.Вопрос в том, как я должен хранить данные для этих объектов, чтобы быть наиболее эффективным.

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

Answer 1

Я бы предложил хранить голоса в виде списка историй _ids в каждом пользователе.Таким образом, вы можете узнать, за какие истории проголосовал пользователь, просто взглянув на список.Чтобы привлечь пользователей, проголосовавших за историю, вы можете сделать что-то вроде:

db.users.find({stories: story_id})

где story_id является ли _id из истории, о которой идет речь.Если вы создадите индекс на stories выполнение обоих этих запросов будет быстрым.

Answer 2

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

Как я буду про переключить разум на время забыть о всего в базе данных.В мире реляционных баз данных вам всегда приходится беспокоиться о нормализации данных и вашей структуре таблицы.Откажись от всего этого.Просто верстайте свою веб-страницу.Выложи их выложи все.А теперь посмотри на них.Твой уже 2/3 там.Если вы забыли понятие о том, что размер базы данных имеет значение и данные не должны дублироваться больше, чем ваши там 3/4, и вам даже не пришлось писать какой-либо код!Позвольте вашим взглядам определять ваши модели.Вы не должны принимать объекты и сделать их 2 больше объемными, как в реляционные мира.Теперь вы можете сохранять объекты, имеющие форму.

как-думать-в-хранилищах-данных-вместо-баз данных

Answer 3

Хорошо, вы не предоставили нормализованную модель данных, как вы сделали бы при настройке SQL.

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

Я никоим образом не эксперт в области NoSQL, но почему бы вам просто не следовать своим потребностям и не сохранить пользователя (идентификаторы), проголосовавшего за историю, в коллекции stories, а историю (идентификаторы), за которую проголосовал пользователь, в коллекции users?

Answer 4

В CouchDB это очень просто.Один вид излучает:

function(doc) {
 if(doc.type == "vote") {
   emit(doc.story_id, doc.user_id);
 }
}

Другой вид испускает:

function(doc) {
 if(doc.type == "vote") {
   emit(doc.user_id, doc.story_id);
 }
}

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

Answer 5

В последнее время я много изучал MongoDB и CouchDB, но мое понимание ограничено.Тем не менее, когда вы думаете о сохранении голосов внутри документа истории, вам, возможно, придется побеспокоиться о превышении предельного размера документа в 4 МБ.Даже если вы этого не сделаете, вы можете постоянно увеличивать размер документа настолько, чтобы вызвать его перемещение и, таким образом, замедлить запись (смотрите, как определяются размеры документов в MongoDB).

Что касается CouchDB, такого рода вещи довольно просты, элегантны и довольно быстры после вычисления индексов просмотра.Лично, однако, я не решался делать аналогичный проект в CouchDB из-за тестов, показывающих, что он постепенно замедляется в значительной степени по мере роста базы данных (и роста индексов просмотра).Мне бы хотелось увидеть несколько более свежих тестов, показывающих производительность CouchDB по мере увеличения размера базы данных.Я ХОЧУ попробовать MongoDB или CouchDB, но SQL по-прежнему кажется таким эффективным и логичным, поэтому я останусь с ним до тех пор, пока проект не будет соответствовать искушению в самый раз.