Как моделировать хэштеги с nodejs и mongodb

Существующая архитектура: nodejs-сервер с бэндом mongodb.

У меня есть строки, описывающие изображения, которые могут содержать #hashtags.

Я хочу извлечь хэштеги из строк, сохранить хэштеги и связать изображение с этим хэштегом.

Так, например, изображение загружается с потерей в #bandcamp #nyc

#bandcamp и #nyc .

  • Если они уже не существуют как hashtags, они создаются, и изображение связано с ними обоими.

  • Если они существуют, это распознается, и изображение связано с обоими.

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

Я новичок в nosql, я понимаю, что в реляционном я имел бы:

  • таблица hashtags
  • изображения таблиц
  • таблица imageshashtags

со многими отношениями. Изображение может иметь много хэш-тегов, а хэштег может иметь много изображений.

Какой подход подходит для монго? От чтения q & a вот так: https://stackoverflow.com/questions/8455685 /как к орудию-пост-тегов в-монго

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

Затем я мог бы использовать http://cookbook.mongodb.org/patterns/count_tags/ - map уменьшить?

Итак, в итоге:

коллекция изображений с подтекстом тэгов коллекции тегов

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

также создайте тег в коллекции тегов и запустите отображение карты.

Это звук? Я правильно понимаю вещи и разумен ли мой подход?

7 голосов | спросил Dave 16 MaramSat, 16 Mar 2013 07:41:08 +04002013-03-16T07:41:08+04:0007 2013, 07:41:08

2 ответа


2

Сохранить хэштеги в массиве внутри документа.

Это преимущество наличия документов: вы можете просто их вложить. И в этом конкретном случае это тривиально:

{
    "_id": 123,
    "file": "c43a5f46-kitten.png",
    "description": "My kitten :3 #kittens #cute"
    "hashtags": ["kittens", "cute", "cat", "animals"]
}

(Я добавил несколько «синонимичных» тегов, это можно сделать автоматически, просмотрев какой-то другой документ.)

Это наиболее естественное решение для документированной базы данных:

  • Поиск документов по hashtags является тривиальным, если вы просто добавляете индекс, а также вставляете, обновляете и удаляете хэштеги на случайных документах также тривиально.
  • Массивная вставка, обновление и удаление немного сложнее, потому что вы, вероятно, захотите разделить такие операции на несколько «партий», но все же это управляемо и не сложно реализовать
  • Сложные агрегации могут выполняться с помощью стандартного конвейера агрегации или уменьшения карты.

С другой стороны, если вы перейдете к реляционному стилю, у вас возникнут большие проблемы при повторном внедрении SQL JOIN в вашем коде приложения. Это один из самых распространенных анти-моделей использования MongoDB (и таких). Вот очень типичный псевдокод:

for (HashTag tag: mongodb.hashtags.find()) {
   for (Image img: mongodb.images.find(
           new Document("_id", new tag.getImageId()))) {
       // ...
   }
}

Это неэффективно, не масштабируется, и вы просто изобретаете колесо. Используя это, вы, вероятно, столкнетесь со сложностью O(N*M) из-за циклов внутри вашего кода. Если вместо этого вы выбрали SQL с иностранными ключами, у вас будет что-то вроде O(N*log(M)) или даже O(N+M)

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

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

ответил scriptin 14 62015vEurope/Moscow11bEurope/MoscowSat, 14 Nov 2015 23:40:50 +0300 2015, 23:40:50
-1

Я бы создал две таблицы. MongoDB очень гибкий. Я говорю только две таблицы вместо одной таблицы с двумя полями: «картинка» и «массив хеш-тегов», потому что это затрудняет запрос к хэш-тегам.

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

Две таблицы должны быть:

  1. одно поле, просто изображения, (mongo автоматически создает уникальный идентификатор для каждой записи (_id))

  2. База данных с двумя полями, «строки тэгов #hash» и «массив соответствующих уникальных идентификаторов для изображений в таблице изображений.

После получения изображения проанализируйте хэш-теги и сохраните строки в локальной переменной. Вставьте изображение в первую таблицу и верните уникальный идентификатор (_id) для изображения.

Выполните повторение второй таблицы для каждого тэга #hash и поднимите его с идентификатором изображения (_id), к которому он принадлежит. [поле идентификатора изображения будет массивом] (upsert будет искать совпадение _id и создать новый документ, если он не существует. Для него требуется jquery.)

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

  1. Он хранит только одну копию каждого изображения.

  2. Он настроил вас на то, чтобы упростить запросы к конкретным тэгам #hash.

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

ответил Steven 19 MaramTue, 19 Mar 2013 01:16:54 +04002013-03-19T01:16:54+04:0001 2013, 01:16:54

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132