супер, пасябки

Гайс! А кто-то платным софтом монго бэкапит? расскажите пожалуйста подробнее про процесс, результаты

Почему выдает ошибку? const patients = await this.patientModel.find({ }).project({ "dateOfDeactivation": 1 }).exec();

TypeError: this.patientModel.find(...).project is not a function

Гайс! А кто-то платным софтом монго бэкапит? расскажите пожалуйста подробнее про процесс, результаты

О каком софте идёт речь?

CastError: Cast to ObjectId failed for value "{ dateOfDeactivation: { '$exists': true } }" at path "user" for model "Patient"

Народ. Подскажите как выбрать юзеров по айдишкам из такой структуры? https://mongoplayground.net/p/FHZBuTFRHrk При условии что я не знаю custom:key у обьектов

Изменить схему таким образом, чтоб в пути до искомого ключа небыло неизвестных ключей, например [ { "type": "limit", "key": "custom:key:c", "role": "user", "user_id": "user:3" } … ] В обратном случае это будет очень дорогой поиск, в вашем случае вероятно через агрегацию и $objectToArray

Народ. Подскажите как выбрать юзеров по айдишкам из такой структуры? https://mongoplayground.net/p/FHZBuTFRHrk При условии что я не знаю custom:key у обьектов

Ну не игнорьте) Помогите начинающему Я кажется продвинулся https://mongoplayground.net/p/YYeogplv7qL но как теперь отфильтровать limit.v.user_id: "user:2"

const patients = await this.patientModel.find({"user": {"dateOfDeactivation": {$exists: true}}}).exec(); вот запрос что не так?

const patients = await this.patientModel.find({"user": {"dateOfDeactivation": {$exists: true}}}).exec(); вот запрос что не так?

Не видя вашей схемы сложно сказать, но судя по ошибке у вас user это ObjectId, а не объект

Ну не игнорьте) Помогите начинающему Я кажется продвинулся https://mongoplayground.net/p/YYeogplv7qL но как теперь отфильтровать limit.v.user_id: "user:2"

https://play.db-ai.co/m/Xr081H7kZQABtCMg

но это не очень удачное решение

О каком софте идёт речь?

Без разницы

но это не очень удачное решение

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

Изменить схему на что-то в духе: "limit": [ { "key": "custom:key:c", "role": "user", "user_id": "user:3" } … ] Уникальность обеспечивать уникальным индексом

всем привет. такой трабл. поднял 3 копии монго в реплсет режиме без аутентификации. провел rs.initiate со всеми нодами (1 - всегда праймери, 2 - приоритет 0, 3 - только арбитр) зашел на 1 ноду, создал юзера с правами root поставил во всех 3 нодах флаг —auth и перезапустил все монги теперь не могут подняться две ноды с ошибкой Member mongo2:27017 is now in state RS_UNKNOWN due to authentication issue. Unable to reach primary for set rs0 и основная имеет статус RECOVERING как можно это исправить?

Попробуйте сначала создать stand-alone ноду с аутентификацией и уже позже конвертировать её в реплику

И проверьте что у вас в конфигурации нет настройки cluster level аутентификации

была проблема что надо было создать ключ и пробросить на все ноды через keyFile

Ага, значит вы включили обе системы аутентификации: и пользовательскую и для кластера

4.2.6 (Apr 21) ◦ 4.0.18 (Apr 15) ◦ 4.4.0-rc5 (May 9) • Плейграунд для запросов • Документация • Официальные курсы (Бесплатно) Stable: 4.2.6 ◦ Bugfix: 4.0.18 Legacy: 3.6.18 (May 1) ◦ Beta: 4.4.0-rc5 По вопросам платной поддержки и покупки лицензий пишите @dd_bb ☠️: 3.4.23 (Jan ‘20), 3.2.21 (Dec ’18), 3.0.15 (May ’17)

https://play.db-ai.co/m/Xr081H7kZQABtCMg

А тут у вас два условия в $match и в cond, это для оптимизации? https://mongoplayground.net/p/f5OH6laHswT Такое выглядит более понятно, хотя предположу что оно преобразует всю таблицу и потом по трубе передаст в match

почему когда я делаю запрос такой > db.patients.find({ }, {_id: 1, 'user.updatedAt': 1}).count() или такой > db.patients.find({ }, {_id: 1, 'user.email': 1}).count() мне приходит один и тотже резулбтат если в бд они разные

Эти два запроса возвращают одинаковый набор документов, в данном случае все, такак фильтр пустой ({}). Вторым аргументом указывается проекция, т.е. список полей которые будут возвращаены в резульате и не влияет количество возвращённых в результате выборки документов

Эти два запроса возвращают одинаковый набор документов, в данном случае все, такак фильтр пустой ({}). Вторым аргументом указывается проекция, т.е. список полей которые будут возвращаены в резульате и не влияет количество возвращённых в результате выборки документов

Мне просто надо, отобрать все записи у которые есть определенное поле

Мне просто надо, отобрать все записи у которые есть определенное поле

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

Mongo World в 2020 году будет проходить 9 и 10 июня в онлайн формате под названием «Mongo.LIVE», а участие абсолютно бесплатное. Регистрация: https://www.mongodb.com/world Апрельские обновления: * Stable: 4.2.6 (Apr 21) * Bugfix: 4.0.18 (Apr 15) * Beta: 4.4.0-rc5 (May 9) Вероятно релиз версии 4.4.0 анонсируют на Mongo.LIVE, так что ждать осталось совсем недолго

А тут у вас два условия в $match и в cond, это для оптимизации? https://mongoplayground.net/p/f5OH6laHswT Такое выглядит более понятно, хотя предположу что оно преобразует всю таблицу и потом по трубе передаст в match

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

да, оно преобразует все документы и выборка будет не эффективной

Суть: в коллекции 8.8 млн записей, 5 ГБ. В каждой записи по 15 полей, нужно производить поиск по 6 из них (по одному, по нескольким или по всем). Сервер - DigitalOcean $5 Droplet. Создавал индексы по 6 полям отдельно, соответственно по одному любому полю поиск 80-140мс. Мульти-индекс работает, но только с опцией sparse и только с определенным кол-вом полей (от 3 до 6). Создать десятки индексов на все случаи жизни считаю костылём, надеюсь - это не не офф решение монго. Вопрос: как сделать правильный индекс, чтобы можно было фильтровать 9 млн записей за 80-140 мс при любой выборке, будь то 1 поле или сразу 6?

Привет, хочу про архитектуру спросить. Делаю мобильное приложение знакомства, сделал с firebase базу там абонентов, но с очень урезаными возможностями делать выборки, приходиться много лишних действий делать, даже onSnapshot не помогает когда данных много. Есть колекция юзеров и есть коллекция кто кого лайкнул, чтобы повторно не предлогать лайкать. Перехожу на GraphQL, там чище выборки и подписки есть. Теперь думаю про бд, остановился на монго. Но чет не знаю как лучше архитектуру. Мож есть идеи как правильно хранить?

Суть: в коллекции 8.8 млн записей, 5 ГБ. В каждой записи по 15 полей, нужно производить поиск по 6 из них (по одному, по нескольким или по всем). Сервер - DigitalOcean $5 Droplet. Создавал индексы по 6 полям отдельно, соответственно по одному любому полю поиск 80-140мс. Мульти-индекс работает, но только с опцией sparse и только с определенным кол-вом полей (от 3 до 6). Создать десятки индексов на все случаи жизни считаю костылём, надеюсь - это не не офф решение монго. Вопрос: как сделать правильный индекс, чтобы можно было фильтровать 9 млн записей за 80-140 мс при любой выборке, будь то 1 поле или сразу 6?

не вижу проблемы, чтото не устраивает в производительности на 6 отдельных индексах?

не вижу проблемы, чтото не устраивает в производительности на 6 отдельных индексах?

Да, если брать два поля, выборка использует один индекс, а по второму полю производит сканирование, а это занимает может занимать минуты

Суть: в коллекции 8.8 млн записей, 5 ГБ. В каждой записи по 15 полей, нужно производить поиск по 6 из них (по одному, по нескольким или по всем). Сервер - DigitalOcean $5 Droplet. Создавал индексы по 6 полям отдельно, соответственно по одному любому полю поиск 80-140мс. Мульти-индекс работает, но только с опцией sparse и только с определенным кол-вом полей (от 3 до 6). Создать десятки индексов на все случаи жизни считаю костылём, надеюсь - это не не офф решение монго. Вопрос: как сделать правильный индекс, чтобы можно было фильтровать 9 млн записей за 80-140 мс при любой выборке, будь то 1 поле или сразу 6?

Возможно подойдёт wildcard index, но в остальном, задача индекса — уменьшить объём данных для поиска. Если вы ищите по всему документу, то возможно либо у вас не эффективная схема, либо вам нужен другой инструмент

если это случай dynamic attribute, то вероятно схема attributes: [{ key: <string>, value: <string> }, … {}]и составной индекс по attrs.key. attrs.value будет эффективнее

Коллекция users и коллекцию likes, где храниться ид кто лайкнул и ид кого лайкнули. Мне нужно выбирать для конкретного юзера кого он еще не лайкал. В монго я новичек, может с учетом специфики я изначально архитектуру не правильно делаю. А так как юзеров может быть много и лайков еще больше, то делать бы это в одном запросе

Коллекция users и коллекцию likes, где храниться ид кто лайкнул и ид кого лайкнули. Мне нужно выбирать для конкретного юзера кого он еще не лайкал. В монго я новичек, может с учетом специфики я изначально архитектуру не правильно делаю. А так как юзеров может быть много и лайков еще больше, то делать бы это в одном запросе

В общем случае эта задача плохо решается, так как вы хотите огромное множество всех пользователей пересечь с небольшим множеством лайкнутых. Какой-то универсальной архитектуры тут нет. Если это не существующий сервис с миллионами пользователей, то наиболее эффективным будет собрать лайки пользователей в бакеты (https://www.mongodb.com/blog/post/building-with-patterns-the-bucket-pattern) и дальше просто пересекать с коллекцией пользователей через $nin оператор. Когда это перестанет работать, то можно исходя из паттернов использования сервиса попытаться найти более оптимальный способ

Привет, хочу про архитектуру спросить. Делаю мобильное приложение знакомства, сделал с firebase базу там абонентов, но с очень урезаными возможностями делать выборки, приходиться много лишних действий делать, даже onSnapshot не помогает когда данных много. Есть колекция юзеров и есть коллекция кто кого лайкнул, чтобы повторно не предлогать лайкать. Перехожу на GraphQL, там чище выборки и подписки есть. Теперь думаю про бд, остановился на монго. Но чет не знаю как лучше архитектуру. Мож есть идеи как правильно хранить?

Почему монга, а не графовая бд ?

В общем случае эта задача плохо решается, так как вы хотите огромное множество всех пользователей пересечь с небольшим множеством лайкнутых. Какой-то универсальной архитектуры тут нет. Если это не существующий сервис с миллионами пользователей, то наиболее эффективным будет собрать лайки пользователей в бакеты (https://www.mongodb.com/blog/post/building-with-patterns-the-bucket-pattern) и дальше просто пересекать с коллекцией пользователей через $nin оператор. Когда это перестанет работать, то можно исходя из паттернов использования сервиса попытаться найти более оптимальный способ

Спасибо почитаю про это

Почему монга, а не графовая бд ?

Графовая БД не поможет, так как количество связей для анализа всё равно будет в худшем случае равно количеству пользователей

Почему монга, а не графовая бд ?

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

Если лучше чтот другое использовать, подскажите что лучше будет

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

Графовая БД не поможет, так как количество связей для анализа всё равно будет в худшем случае равно количеству пользователей

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

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

Зачем тогда советовать? Без указания других задач смысла никакго сравнивать нет. Графовые БД эффективнее работают со сложными цепочками отношений.

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

По этому лучше использовать bucket паттерн

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

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

Зачем тогда советовать? Без указания других задач смысла никакго сравнивать нет. Графовые БД эффективнее работают со сложными цепочками отношений.

Я вроде бы ничего не советовал, а задал вопрос)

Просто само приложение это не новинка совсем, популярный кейс, хранить лайки и фильтровать, решения кажется уже должны быть

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

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

Окей, извиняюсь

Просто само приложение это не новинка совсем, популярный кейс, хранить лайки и фильтровать, решения кажется уже должны быть

Начните с чего-то работающего. Если у вас появятся проблемы с производительностью, то будет смысл искать более эффективное решение.

Make it work, make it right, make it fast

Спасибо, поищу про bucket

У меня в бд хранятся даты в строке, в формате: "Wed, 13 May 2020 20:45:56 UTC". При этом операции gte, sort и т п на них вроде как корректно работают. Так и должно быть? По какому принципу это вообще работает?

Или нужно все-таки делать преобразования какие-то?

Господа, а что лучше: mapreduce или агрегации?

Агрегации

У меня в бд хранятся даты в строке, в формате: "Wed, 13 May 2020 20:45:56 UTC". При этом операции gte, sort и т п на них вроде как корректно работают. Так и должно быть? По какому принципу это вообще работает?

Хранить в виде типа, который сериализуется в BSON UTC datetime (тег x09)

Вот я тоже написал ёба агрегации, подумал как это на мапредьюс переписать и не придумал. Вообще наверное лучше развернуть Atlas...

А как сделать populate из терминала? Чтобы обьелинить таблицы

В монге я имею введу

А как сделать populate из терминала? Чтобы обьелинить таблицы

https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/

Но ты скорее всего убьешься чем будешь делать это в терминале. Заюзай Mongo Compass. Там есть тулза для аггрегации

Но ты скорее всего убьешься чем будешь делать это в терминале. Заюзай Mongo Compass. Там есть тулза для аггрегации

Какая тулза?

Какая тулза?

https://docs.mongodb.com/compass/master/aggregation-pipeline-builder/

https://docs.mongodb.com/compass/master/aggregation-pipeline-builder/

Спасибо, посмотрю

а оператор $ne и с массивами работает? "likes": { "$ne": ObjectId(req.body.userId) } тоесть тут перебор всего массива будет?

_id:5d5fba2879571 firstName:"Первый" lastName:"Пациент" dateOfBirth:2019-08 gender:"male" dateOfRegistration:2019-08-23 hospital:5d5fbf7487956d user:5d5fba879570 patientStatus:"active" patientDiagnosis:5d190edd480 email: 123@gmail.com "pacic@mail.com"__v:0 nickname:"Первый Пациент" firstTimeAddGame:true achievement: 5d83b5f4b address:"asd" height:1 weight:1 _id:5d039c0d7c3475b password:"$2a$10FZC/fZ9l4wONuhMgXdkC" email:"123@mail.com" rolе: admin lang:"en" identifier:"6tPYcwd6dO" lastLoginDate updatedAt 2020-05-06 @bilyalov Как мне обьединить эти две таблицы?

В mongoose я могу как-нибудь инфу передать из pre хука в post? для update

всем привет

запустил индекс для поля в монге, а можно как-то смотреть процесс выполнения ?

запустил индекс для поля в монге, а можно как-то смотреть процесс выполнения ?

db.currentOp()

С логах тоже будут записи с процентами завершения

добрый вечер. подскажите, пожалуйста. есть два документа в документе Х хранятся (id, name etc ) в документе Х2 хранятся другие поля и поле id из Х. вопрос: как отдать с сервера документ Х2 в котором id будет равен полю name из документа Х?

У меня есть документы в коллекции с разными полями, включая массивы и численные поля, как бы мне правильно искать в этом всём? Просто в $match агрегаций впихивать регекспы, для полей массивов юзать $elemMatch? Насколько быстро вообще такой поиск будет работать, база на 500 мегабайт

У меня есть документы в коллекции с разными полями, включая массивы и численные поля, как бы мне правильно искать в этом всём? Просто в $match агрегаций впихивать регекспы, для полей массивов юзать $elemMatch? Насколько быстро вообще такой поиск будет работать, база на 500 мегабайт

Если вся база может поместиться в оперативную память с излишком, тогда можно даже не создавать индексы, потому что монго будет сканировать всю базу сразу. (теории и эксперименты*)

Если вся база может поместиться в оперативную память с излишком, тогда можно даже не создавать индексы, потому что монго будет сканировать всю базу сразу. (теории и эксперименты*)

Окей, спасибо. Вроде да, я когда-то парсил что-то, она спокойно 800 мб забивала (на моём старом компе с 3 гигами)

Парни, а вот есть у меня документ с полем `names: ["name1", "name2", "name3"] и нужно найти его имея ["name1", "name3"], при этом если искать ["name1", "name3", "nameXXX"] то этот документ чтобы не находило. То-есть поиск по подмножеству

Как таке сделать?