так при $eq идет полное совпадение, т.е. время полночь для сравнения просто даты

А как при таком формате отбирать доки за 1 день? Только с больше - меньше?

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

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

Если я в переменную кладу 2 слова через пробел для поиска, то он находит документы и с 1 словом Можно сделать чтобы искал только те документы где содержатся оба+ слова? const product = await collection.find({$text:{$search:name}}).toArray();

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

Такс вот сортировка по очкам интересно Это надо надо самому реализовать?

Добрый день. Подскажите пожалуйста, в чем мб причина, что индексы перестали работать при обновлении монги на 6 версию?

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

Запросы по времени прежние

тогда похоже на то что формат выдачи инфомрации по индексам или ее учета изменился

А есть какой-то, скажем, автокомпилятор схем Mongoose из типов TypeScript? На основе reflect-metadata или просто до компиляции, лишь бы TS не ругался...

Коллеги, возможно, задача покажется, кому-то глупой или из категории RTFM, но это реальная задача. Итак, имеется некторое количество объектов с неизвестными заранее характеристиками. Необходимо организовать поиск объектов, наиболее близко удовлетворяющих заявленным пользователем хорактеристикам. Как это организовать в mongodb? В SQL можно было бы динамически генерировать текст запроса и тем самым ршить проблему невестных наперед характеристик. А как быть в данном случае?

парсер ввода нормализация контекстное наполнение запроса через $or и $and

так чтобы через $or и $and нужно, чтобы характеристики были известны заранее, а этого нет

вы пишете, что "организовать поиск заявленным пользователем характеристикам". что значит они не известны?

на этапе разработки не известны. пользователь их сам вносит на этапе эксплуатации

а какая разница? решение все равно подходит. просто нужно будет хранить вводы пользователя, потом динамически расширять contextvars при исполнении, отдавать ошибку при отсутствии ну или как-то по-другому обрабатывать пример реализации: https://habr.com/ru/company/yandex/blog/526322/

Ребят, всем привет. Прошу совета опытных юзеров. Ситуация такая, для практики и изучения Монго рентавал VРS сервачек, развернул на нем Ubuntu 20.4 установил комьюнити версию Монго 4.4.2 Через шелл настроил пользователей, в конфиге включил ваторизацию и биндинг внешнего айпи адреса, также в фаервол добавил доступ к порту Монго. При попытке потключисься к нему с локальной машины через тот же Компас без указания SSH\Proxy с юзером системы соединение не идет. Собственно вопрос, можно ли как то подключиться без поднятия SSH тунеля на хост машину?

Да можно. Какую строку подключения указываете и что за ошибка?

Ошибка: connect ETIMEDOUT 104.254.247.201:27017 Cткока: mongodb://cvboard:password@1**.***.***.201:27017/?authMechanism=DEFAULT&authSource=cvboard

А тачка 104.254.247.201 с локали вообще пингуется?

Ребят, подскажите как лучше сделать, использую mongodb. Есть коллекция bot_users, в ней должны быть два поля npsList и alarmList. Вопрос, как лучше сделать, вынести npsList и alarmList в отдельную коллекцию или оставить таким образом: type bot_users = { _id: ObjectId telegramId: number botName: string username: string firstName: string lastName: string isAdmin: boolean date: string alarmList: [{ name_doctor: string name_template: string data: string status: boolean }] npsList: [{ _id: ObjectId value: number date: string }] } p.s. Написал на ts, чтобы было нагляднее

Ребят, подскажите как лучше сделать, использую mongodb. Есть коллекция bot_users, в ней должны быть два поля npsList и alarmList. Вопрос, как лучше сделать, вынести npsList и alarmList в отдельную коллекцию или оставить таким образом: type bot_users = { _id: ObjectId telegramId: number botName: string username: string firstName: string lastName: string isAdmin: boolean date: string alarmList: [{ name_doctor: string name_template: string data: string status: boolean }] npsList: [{ _id: ObjectId value: number date: string }] } p.s. Написал на ts, чтобы было нагляднее

Зависит от того что вы будете делать с содержимым массива. Если только наполнять и потом показывать то разделять смысла нет. Если планируется и добавлять и удалять из из списков да еще и менять данные внутри объектов в массиве то отдельная коллекция

Нет проблем удалять или изменять в массиве.

Вопрос про работу со списками. В одном поле лежит список словарей, размер которого нужно контролировать (он не должен быть более ~2КБ в качестве json) , это делает приложение. Сейчас я просто делаю update_one этого поля и присваиваю новый список. Интересует, есть ли более оптимальный вариант в плане скорости? Условного говоря push( 1 раз) и pop(1.. элементов) в одном флаконе? Без триггеров/функций. В Монго новичок

$addtoset прям недавно использовал, и так же есть $push & $pull на сколько помню из доки

$addtoset прям недавно использовал, и так же есть $push & $pull на сколько помню из доки

Не подходит, мне нужно и удалять, а это добавление в "множество"

если устроит просто замена, то можно через $set укзаывая какой элемент массива вы изменяете, но вам скорее всего нужно чтобы добавили в конец, а удалили из начала?

Да, да, почти так, список - Первый вошел-последний вышел, где начало, где конец разницы нет. Если из питона я делаю update $set (размер списка 2КБ) всего списка, то времени уходит 0.7 попугаев, если две команды подряд, update $push (размер элемента 0.2 КБ) и update $pop, то 1.2 попугая, сам найти не смог можно ли оптимальнее это делать без каких-либо ухищрений

Да, да, почти так, список - Первый вошел-последний вышел, где начало, где конец разницы нет. Если из питона я делаю update $set (размер списка 2КБ) всего списка, то времени уходит 0.7 попугаев, если две команды подряд, update $push (размер элемента 0.2 КБ) и update $pop, то 1.2 попугая, сам найти не смог можно ли оптимальнее это делать без каких-либо ухищрений

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

я предполгааю, что один $set, которые меняет элемент массива и индекс в цикличном буффере, будет быстрее чем добавить и удалить элемент. к тому же будет одна оперция а не две.

операции в любом случае 2, так как модифицируется 2 объекта. читай внимательно условие его задачи: "Первый вошел-последний вышел, где начало, где конец разницы нет" вот если бы у него было условие: "1 определённый удалён, вместо него добавлен другой на то же место", тогда да

Вопрос про работу со списками. В одном поле лежит список словарей, размер которого нужно контролировать (он не должен быть более ~2КБ в качестве json) , это делает приложение. Сейчас я просто делаю update_one этого поля и присваиваю новый список. Интересует, есть ли более оптимальный вариант в плане скорости? Условного говоря push( 1 раз) и pop(1.. элементов) в одном флаконе? Без триггеров/функций. В Монго новичок

Интересное требование про 2кб, что за задача что упирается именно в размер а не количество элементов списка?

У API ChatpGPT ограничение по объему присылаемой ему беседы 4096 токенов, это примерно 2 КБ текста на русском (скорее меньше). Это его память по контексту беседы. Мне нужно хранить текущий контекст, лишнее удалять. Юзер отправил в контекст сообщение, после расчета токенов, из диалога юзер+чат удаляется то, что не влезло в 4096 токенов, из начала беседы.

Про это даже не подумал)

Подскажите, а как лучше спроектировать БД в MongoDB где связь один-ко-многим? Допустим есть такие сущности: 1. Article 2. Tag 3. article_tag Соответственно тут у Article много Tag, и связь эта указывается через таблицу article_tag (article_id, tag_id) Нормально ли связи по такому принципу строить?