отличное решение спасибо. надеюсь на mangoose подойдет, и не сильно будет тормозить базу

Будет тормозить

Будет тормозить

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

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

Думаю снимет часть вопросов https://docs.mongodb.com/manual/tutorial/model-tree-structures-with-materialized-paths/

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

А почему родительский урл может поменяться?

Думаю снимет часть вопросов https://docs.mongodb.com/manual/tutorial/model-tree-structures-with-materialized-paths/

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

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

Тут трейдофы хранения деревьев, либо путь фиксируете и простая выборка, но дорогое обновление, либо собираете путь как у вас, тогда дорого собирать, но просто обновлять

Ребята, доброй ночи! А в mongo нельзя что ли навешивать индексы на поля, находяющиеся в коллекциях с большим уровнем вложенности?

то есть { "_id" : ObjectId("5da4dc23c242bd7de49a31de"), "is_personal" : true, "translations" : [ ], "add_date" : ISODate("2019-10-14T20:35:47.497Z"), "words" : [ { "words" : [ { "word" : "a cat", "language" : "english" }, { "word" : "кошка", "language" : "russian" } ], "add_date" : ISODate("2019-10-14T20:36:51.497Z") } ] }

Индекс типа words.words.word: text. не работает(

И это не только типа text касается

Индекс типа words.words.word: text. не работает(

а в чем выражается, что не работает?

а в чем выражается, что не работает?

Не используется индекс при нахождении. Если говорить про text-индекс, то по идее при фильтре "words.words.word": "cat". должно было найтись слово. Так как я текстовый индекс и использую для того, чтоб он обрабатывал всякие артикли при поиске)

Не используется индекс при нахождении. Если говорить про text-индекс, то по идее при фильтре "words.words.word": "cat". должно было найтись слово. Так как я текстовый индекс и использую для того, чтоб он обрабатывал всякие артикли при поиске)

а как ищете?

Примерно та же самая ситуация у меня была и при обычном индексе (но там уже другой набор данных)

Сейчас не за компом, но искал примерно так: db.coll.findOne({"words.words.word": "cat"})

Пустой результат был, но судя по эксплейну индекс вроде использовался

Но я так понимаю, что подобного ограничения в монге нет. И скорее всего, я что-то делаю не так?

по полной фразе ищется, а вот текстовый да чтото не то, над поразбираться

Но я так понимаю, что подобного ограничения в монге нет. И скорее всего, я что-то делаю не так?

db.getCollection('sts').find({$text: { $search:"cat"}})

чет совсем позабыл что там по другому

https://docs.mongodb.com/manual/reference/operator/query/text/

db.getCollection('sts').find({$text: { $search:"cat"}})

Это рабочий вариант? Спасибо!

да, тестанул

Но у меня похожая проблема есть и с обычным btree-индексом. Индекс используется, а результатов нет. Могу толтко днем завтра прислать подробности.

Сегодня*

кидайте, поразбираемся

Всем доброе, кто может подсказать, не может же быть такого что коллекции самопроизвольно дропаются?

При входе в mongo I STORAGE [initandlisten]

кидайте, поразбираемся

Ан нет. Сейчас посмотрел на эксплейн запроса: IXSCAN режим используется. Значит, я раньше ошибался (фильтр неверно указывал наверное)

Всем доброе, кто может подсказать, не может же быть такого что коллекции самопроизвольно дропаются?

Если выставлены в интернет - легко дропаются при кривой безопасности

как заставить $lookup работать с array, гугл показывает решения через костыли

Добрый день. Как строить взаимосвязи, на примере категорий/тегов? Имеем стандартную структуру контента сайта: посты, категории, теги. Ранее я делал так: сохраняю пост, в его поле "категорий/тегов" указываю айди соответсвующей категории/тега, а потом в саму категорию/тег в поле "посты" пушу айдишник поста. Все было вроде ок. Было удобно например заходить в категорию, и делать лейзи лоад проходя по массиву постов. Но, теперь я столкнулся с ситуацией, когда у меня 1 миллион постов. Соответсвено я в ступоре, ведь это выглядит бессмысленно иметь массив с миллионом айтемов. Раньше я его сразу получал на клиент, когда фетчил категорию/тег, но тогда там было максимум пару сотен постов, это было дешево... Как строить БД в таком случае? Просто делать ссылку в соответствующем посте на категорию, а в самой категории вообще не хранить ничего? Какие варианты есть и как делать в таких ситуациях?

Подскажите, картинки только через Grid хранить?

как заставить $lookup работать с array, гугл показывает решения через костыли

$unwind

Подскажите, картинки только через Grid хранить?

да

Добрый день. Как строить взаимосвязи, на примере категорий/тегов? Имеем стандартную структуру контента сайта: посты, категории, теги. Ранее я делал так: сохраняю пост, в его поле "категорий/тегов" указываю айди соответсвующей категории/тега, а потом в саму категорию/тег в поле "посты" пушу айдишник поста. Все было вроде ок. Было удобно например заходить в категорию, и делать лейзи лоад проходя по массиву постов. Но, теперь я столкнулся с ситуацией, когда у меня 1 миллион постов. Соответсвено я в ступоре, ведь это выглядит бессмысленно иметь массив с миллионом айтемов. Раньше я его сразу получал на клиент, когда фетчил категорию/тег, но тогда там было максимум пару сотен постов, это было дешево... Как строить БД в таком случае? Просто делать ссылку в соответствующем посте на категорию, а в самой категории вообще не хранить ничего? Какие варианты есть и как делать в таких ситуациях?

> а потом в саму категорию/тег в поле "посты" пушу айдишник поста избавиться от этого, в посте добавить индекс по полям с категориями и тегами и выбирать по этому поля

особого смысла хранить рефлексию отношения в данном случае нет

> в посте добавить индекс по полям с категориями и тегами и выбирать по этому поля хранить лучше айдишник категории/тега или можно по названию (уникальное)? и дальше вообщем просто выбирать по нему просто среди постов?

я за id

архитектурно лучше иметь явную сущность, чем эфемерную

плюс когда надо будет исправить опечатку, локализовать или объеденить теги/категории это будет легко

о да, это аргумент. благодарю

и задача «показать все теги» будет решаться ощуимо проще

архитектурно лучше иметь явную сущность, чем эфемерную

Слова не юноши, но мужа 🤣

Здравствуйте. Подскажите пожалуйста, можно ли как-то отобразить текстом запросы, поступающие к базе из GUI Compass'а?

Здравствуйте. Подскажите пожалуйста, можно ли как-то отобразить текстом запросы, поступающие к базе из GUI Compass'а?

из компаса не знаю, а вообще если есть возможность формировать запросы через shell, то так например: db.setProfilingLevel(2); db.system.profile.find({ "ns": "namespace.collection_name", "ts": {$gte: ISODate("2019-10-15 00:00:00")}, "op": "update" }).limit(10).sort( { ts : 1 } ).pretty();

я пользую бесплатную версию nosqlbooster

Попробую, спасибо 👍

Ребят привет! Как сделать agregate сразу после save() по новому созданному элементу?

Ребят привет! Как сделать agregate сразу после save() по новому созданному элементу?

Зачем? У вас уже есть этот объект

чтобы дополнить $lookup ом два профиля)

у меня получение истории Message.aggregate([ { $match: query }, { $sort: { 'create_at': -1} }, { $limit: per_page }, { $skip: skip }, { $lookup: { from: User.collection.name, localField: 'send_to', foreignField: 'id', as: 'user_to_profile' } }, { $unwind: { path :'$user_to_profile', preserveNullAndEmptyArrays: true } }, { $lookup: { from: User.collection.name, localField: 'username', foreignField: 'id', as: 'user_from_profile' } }, { $unwind: { path :'$user_from_profile', preserveNullAndEmptyArrays: true } }, { $replaceRoot: { newRoot: { _id: "$_id", userto: "$user_to_profile", userfrom: "$user_from_profile" , message:"$message",create_at:"$create_at"} } } ]).exec(function(err, users){....

теперь при добавлении сообщения надо возвращать такую же структуру

чтобы дополнить $lookup ом два профиля)

Тогда делайте просто второй запрос в колбеке сейва либо помле евейта

В базе миллион записей. Сейчас для постов указаны теги в виде названия (строка), хочу поменять строку на айдишник( то что обсуждали выше). Для этого прохожусь циклом по каждому документу и выполняю js await videos.findOneAndUpdate( { _id: video._id }, { $addToSet: { tags: tagId, }, } ); await videos.findOneAndUpdate( { _id: video._id }, { $pull: { tags: tag, }, } ); В итоге Монга выжрала всю память и свап. Это можно как-то оптимизировать?

как правильно делать такие массовые апдейты?

Bulk?

Если все документы из одной коллекции то можно обойтись bulk ом

Вместо того чтоб фигачить кучу запросов в базу , можно обойтись одним

Почитай документацию к своему драйверу

В базе миллион записей. Сейчас для постов указаны теги в виде названия (строка), хочу поменять строку на айдишник( то что обсуждали выше). Для этого прохожусь циклом по каждому документу и выполняю js await videos.findOneAndUpdate( { _id: video._id }, { $addToSet: { tags: tagId, }, } ); await videos.findOneAndUpdate( { _id: video._id }, { $pull: { tags: tag, }, } ); В итоге Монга выжрала всю память и свап. Это можно как-то оптимизировать?

сделать так, чтоб клиенты временно не могли менять теги, выбрать уникальные теги через AF, на каждый тег создать по документу, мемоизировать отношение tag <-> _id, на каждый тег сделать findAndModify с multi где $push в поле tag_ids

опционально удалить поле tags

выключить своп

Bulk?

нет

Если все документы из одной коллекции то можно обойтись bulk ом

точнее каким балком?

точнее каким балком?

не нужно

вы выбрали стратегию, где вы документы по одному таскаете между клиентом и сервером, а потом ещё делаете апдейты

сделайте массовый апдейт с условием по каждому тегу

чтоб не таскать ничего на клиента

> на каждый тег создать по документу, мемоизировать отношение tag <-> _id, на каждый тег сделать findAndModify с multi где $push в поле tag_ids вот эти пункты можно подробнее? 1. документы уже созданы. на каждый уникальный тег 2. что значит "мемоизировать отношение"? 3. зачем мне делать findAndModify на теге, если мне надо посты изменить?

какой клиент и сервры, о чем речь?

ни словом не упоминал ни о каких клиентах

В базе миллион записей. Сейчас для постов указаны теги в виде названия (строка), хочу поменять строку на айдишник( то что обсуждали выше). Для этого прохожусь циклом по каждому документу и выполняю js await videos.findOneAndUpdate( { _id: video._id }, { $addToSet: { tags: tagId, }, } ); await videos.findOneAndUpdate( { _id: video._id }, { $pull: { tags: tag, }, } ); В итоге Монга выжрала всю память и свап. Это можно как-то оптимизировать?

клиент это любое ПО которое общается с монгой, сервер это монга 1 и 2 значит что вам надо в вашем языке програмирования сделать так, чтоб вы _один раз_ выбрали список тегов и их _id 3 значит что вам надо не каждый пост по отдельности обновлять, что потребует миллион запросов, а использовать multi document апдейт. самый простой вариант — сделать столько апдейтов, сколько у вас уникальных тегов. var tags = find_all_tags(); tags.forEach(function(tag) { videos.findAndUpdate( { tags: tag.name }, { $addToSet: { tag_ids: tag._id, } }, { multi: true } ); });

про multi: true не знал, сейчас посмотрю. неужели так просто

и да, по tags просто жизненно необходимо иметь индекс

я не разбираюсь в js драйвере, ищите что там придумали

findMany или ещё какое имя

и да, по tags просто жизненно необходимо иметь индекс

в смысле на самих постах индекс делать?

да

ребят я чет упоролься, почему монго меняет допустим название колекции с category на categories?