как мне найти все письма, где встречаются получатели с доменным именем, отличным от mail.ru ? оператор not {recipients: {$not: /mail.ru/}} не подходит, т.к. в данном примере mail.ru всё таки присутствует

С точки зрения производительности, чтобы проверить не пуста ли коллекция, лучше использовать count или findOne?

Всем привет! Подскажите плз, у меня две монговские базы. Если я содам документ в 1 базе такого вида: { _id: ObjectId('222') // Сгенерированный при создании базой name: 'offer', company: "id" // ObjectId Сгенерированный в другой коллекции базой } и потом через какое-то время отправлю его во вторую базу в таком виде { name: 'offer', company: "id" // ObjectId } может ли айдишник поля company, сгенерированный первой базой как-то получиться таким же у какой-нибудь записи во второй базе?

Ты ведь в любом случае делаешь запрос на получение дока, и тебе вернётся результат либо с пустым ответом, либо результат

Count возвращает сам документ? Точно?

Фраза - делаешь запрос на получения документа - может смущать.

Это супер микро оптимизация, разве нет?

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

Если мы делаем findOne, то если есть какой-то результат, то коллекция не пуста. Одну строку получили и успокоились. В случае с count, движок будет проходиться и считать количество, что, наверное, более ресурсозатратно. Вот что я имел ввиду.

Если мы делаем findOne, то если есть какой-то результат, то коллекция не пуста. Одну строку получили и успокоились. В случае с count, движок будет проходиться и считать количество, что, наверное, более ресурсозатратно. Вот что я имел ввиду.

Я про другое, что за дизайн и концепт в вашем сервисе, что вам надо знать, пустая коллекция или нет, при том, что еще стоит задумываться о производительность, у вас предполагается +100500 rps на коллекцию без документов, или +-100500 коллекций. Вот это странно.

Просто вопрос из интереса.

Просто вопрос из интереса.

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

Что лучше с точки зрения производительности, проверять, есть ли документ с уник. ключом перед вставкой, или пытаться вставить значение через try catch?

Друзья, поделитесь книгой "Mastering MongoDB 6.x" если есть у кого-то

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

Доброе утро, друзья. Замедляют ли уникальные составные ключи коллекцию?

в части записи как и любые индексыв

В mongodb, если поле уникально, то нельзя сделать, чтобы было много строчек со значением этого поля null как в MySQL. Может быть только одна строчка с null для unique поля. Верно?

можно сделать sparse или partial индексы

reIndex — дорогая операция?

Допустим, поле было null, а стало не null. Это разумно после изменения на не null обновить индексы?

Допустим, поле было null, а стало не null. Это разумно после изменения на не null обновить индексы?

reIndex — дорогая операция?

Всем добрый день. Работаю с mongoDb и nest js. Есть условные таблицы users и posts. При написании кода создания поста мы используем модель поста и создаем новую сущность. Для удобства (в специфичных кейсах) мы хотим добавить после создания поста к юзеру из таблицы users в поле posts ObjectId на новый пост. Есть ли более удобное для этого решение, кроме как использовать модель юзера и обновлять вручную ему его поле через findByIdAndUpdate? Возможно какая-то привязка, чтобы это выполнялось автоматически при создании и удалении сущности (поста в нашем случае)

https://github.com/mongodb-js/mongoose-autopopulate

можно сделать sparse или partial индексы

Сделал индекс в котором поле одновременно sparse + unique = ошибка при вставке — дубликат поля со значением null.

MongoServerError: E11000 duplicate key error collection: gift_app_db.actions index: target_action_id_1 dup key: { target_action_id: null }

Что я не так сделал?

https://stackoverflow.com/questions/24488143/mongodb-set-id-as-decreasing-index

Почему нельзя задать -1 индекс для id? Иначе как сделать аналог SELECT... DESC из SQL.

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

const latestRecord = await collection.find().sort({ timestamp: -1 }).limit(1).toArray();

Доброе утро, друзья. Как посчитать количество записей, которые идут до _id N. Грубо говоря, посчитать количество записей созданных до записи с _id N.

const count = await collection.countDocuments({ _id: { $lt: new ObjectId(myId) }, action_type: 1 }); Вот такой запрос посчитает записи у которых экшн тайп = 1 и _id меньше, т.е. записи были созданы раньше, так?

ты лучше на дату создания смотри

Я не храню её полем, т.к. есть _id

В _id же дата создания хранится.

удобно наверное каждый раз её туда сюда гонять

const count = await collection.countDocuments({ _id: { $lt: new ObjectId(myId) }, action_type: 1 }); Вот такой запрос посчитает записи у которых экшн тайп = 1 и _id меньше, т.е. записи были созданы раньше, так?

удобно наверное каждый раз её туда сюда гонять

Зачем хранить дату отдельным полем, если она хранится в id, и зачем она хранится в id, если ею не пользуются?

Кто нибудь играл в vectorSearch? Это правда что в монге это работает исключительно по всей коллекции и нет варианта предварительно отфильтровать?

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

Тоесть это не правда? То что нельзя избежать поиска по всей коллекции в случае vectorSearch?

Ну так кто подскажет? Или придётся всё же поле "дата" внедрять?

const count = await collection.countDocuments({ _id: { $lt: new ObjectId(myId) }, action_type: 1 }); Вот такой запрос посчитает записи у которых экшн тайп = 1 и _id меньше, т.е. записи были созданы раньше, так?

Зачем хранить дату отдельным полем, если она хранится в id, и зачем она хранится в id, если ею не пользуются?

Ребята, всем привет! Есть вопрос по планированию запроса и validate коллекции. Есть запрос: {"q":{"cn":"country_name","c_at":{"$lt":{"$date":"2024-11-18T10:21:50.001Z"}}},"limit":0} Есть используемый индекс: IXSCAN { cn: 1, uid: 1 } Кол-во документов, которые он просканил, много: "keysExamined": 145510823, "docsExamined": 145510823 Кол-во фильтраций: "ndeleted": 9648 Из 145 миллионов просмотренных документов удалено только 9648. Это говорит о том, что фильтрация неэффективна. Длительность запроса: "durationMillis": 353256 Окей, делаем новый индекс, более подходящий для нашего запроса: { key: { cn: 1, c_at: 1 }, name: 'cn_1_c_at_1' } Выполняем запрос, получаем тоже самое... "planSummary": "IXSCAN { cn: 1, uid: 1 }" используем не очень эффективный индекс.. Планировщик так решил: "replanned": true, "replanReason": "cached plan was less efficient than expected" Вопрос: может ли помочь просто дроп "неправильного" индекса или потребуется полный validate коллекции? Чтобы планировщик собрал полную и актуальную статистику по коллекции?

а сколько доков то в итоге подпадает под выборку?

nReturned: 4555, и на это мы тратим 353с

Здравствуйте. Хотел задать вопрос по поводу параллелизации. Есть удаленная коллекция базы mongodb. Она пусть будет 100 гигов. Вопрос в чем, хочется на pymongo сделать 5 потоков например, чтобы в каждом потоке скачивать данные параллельно. Посмотреть изменится ли скорость загрузки всей базы при этом. Но возникает вопрос здесь, как бы коллекцию разделять по умолчанию на 5 частей, чтобы каждый поток скачивал только свою часть. Так как хочется универсальное решение, то хотелось бы на основе генерируемого поля id. Есть ли какие нибудь функции, фильтры, которые бы позволяли это делать ? К примеру, как по функции mod(5) к числу bigint. Но только применительно к mongodb. Спасибо.

Ну хотелось какое то универсальное средство для разовой перекачки и для инкрементной. Просто если база например большая, то хочется максимально ускорить процесс переливки для случаев когда или сама база большая, или инкремент большой. Просто есть задача переливок из mongo в реляционки, а там каждая секунда на счету , чтобы в общий etl все наставлять. И именно на основе id, потому что оно всегда есть, а timestamp или какой другой идентификатор в каждой коллекции от случая к случаю