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

Question

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

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

Story:
 id
 title

User:
 id
 name

Vote:
  id
  story_id
  user_id

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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 все еще кажется таким эффективным и логичным, поэтому я останусь с ним до тех пор, пока проект не будет соответствовать соблазну.