Точнее, есть составной _id, что должен покрывать _id.c

Точнее, есть составной _id, что должен покрывать _id.c

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

Привет, коллеги. Есть два сервера. Нужно отказоустоичивый кластер mongo. Хочу сделать replicaset. Подскажите арбитр где лучше располагать на мастере или слейве?

А какие проблемы? С учетом, что подразумевается, например вставка, будет только уникальных. И как раз уникальность по 2 полям составного _id. Что может, потому что «переезжаю» сам на такой вариант.

проблемы косвенные: 1. размер индекса больше, т.к. содержит весь объект 2. раньше было ограничение на размер индексируемого поля и требовало дополнительного контроля при работе с объектами 3. необходимость строго следовать порядку и набору полей в объекте для корректного поиска. Например переход на другую json либу, которая вдруг начнет менять порядок полей в запросе вам гарантирвоанно сломает работу. 4. к 3 изменение полей в таком _id выливается в определенный прикол 5. невозможность пользоваться индексом для поиска по отдельным полям как в случае выше, что выливается в добавлении еще одного индекса - что можно было бы сразу и сделать 6. если данные из этой коллекции надо кудато лить, то работа с _id как уникальным ключом на стороне приемника тоже становится увлекательным занятием

Про порядок и json либу, да, соглашусь, но с таким не сталкивался. А Если логикой как раз и нужна уникальность пары значений в полях, то к индексу по _id прибавляется индекс по объекту, пусть - v с этими полями, и при объемах в(от) млрд, уже индекс просто по _id прям напрягает, когда он только для аыгрузки данных, и никакого смысла более не несет, почему бы это “v” не заменить на _id?

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

Да, но нужно искать по 1 из 3 вынутоеннихполей. Поэтому и уникальность 3-ки при вставке, избегаем дублирование и остается возможность искать по 1 из составляющих.

Да, но нужно искать по 1 из 3 вынутоеннихполей. Поэтому и уникальность 3-ки при вставке, избегаем дублирование и остается возможность искать по 1 из составляющих.

ну вот вам опять нужен еще один индекс

Так уникальность тоже нужна, это все равно будет составной, но на другое поле, пусть v. А сворачивать в условных бинарь, это означает терять, 2 других значения, верней не терять, или их просто отдельно хранить. Так я понял, то есть от них делать хэш - его писать в _id, и их хранит отдельно по полям? Но ведь база все равно их во что то условно «хэширует» ?

Так уникальность тоже нужна, это все равно будет составной, но на другое поле, пусть v. А сворачивать в условных бинарь, это означает терять, 2 других значения, верней не терять, или их просто отдельно хранить. Так я понял, то есть от них делать хэш - его писать в _id, и их хранит отдельно по полям? Но ведь база все равно их во что то условно «хэширует» ?

Условно, если хэш - от этой уникальной n (пары , тройки …) - перевести в int64, а их значения хранить отдельно, это будет лучше если в поле _id просто их писать как поля со значениями?

имел в виду в _id пишем f(a,b,c), и c еще отдельным полем в сам док и индекс еще по нему для поиска

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

Да да я понял, интересно. А чего мы (в данном случае производительность?) добиваемся от «ограничения» на размер по полю _id. Ну ок, то есть гарантируем размер _id. Но ведь для может же быть так, они в сумме будет чаще давать, меньший размер, а мы всегда гарантируем 1 и тот же? Разве нет?

Да да я понял, интересно. А чего мы (в данном случае производительность?) добиваемся от «ограничения» на размер по полю _id. Ну ок, то есть гарантируем размер _id. Но ведь для может же быть так, они в сумме будет чаще давать, меньший размер, а мы всегда гарантируем 1 и тот же? Разве нет?

ребят, весь мозг сломал, сервак сразу ложится

В ошибке написано что пытаетесь массив к строке кастануть

не могу понять где я это пытаюсь сделать

Логи и дебагер вам в помощь, все гдето в коде

Кстати, может не везде есть history. поэтому быстро.

Попробоуй аггрегейшн сделать

может из-за доп.индекса?

Должно быть везде

ты юзаешь find. попробуй db.chats.aggregate([]) и там через match

Эээ, откровенно сложно понять, что вы тестировали и как, общие моменты только, а зачем вам skip?, вы типа «пагинацию» через skip реализовываете?

Хорошая работа по тестированию драйвера для питона, сходите ишью напишите, может доработают

из за этого приходится использовать $text $search но он не такой точный как tegexp

пагинация через скип + лимит, да есть другой способ лучше?

Привет! Debian 11, ставлю mongodb 7.0 по официальной инстукции. Устанавливается, но не стартует. В логах есть только такое: Started MongoDB Database Server. systemd[1]: mongod.service: Main process exited, code=killed, status=4/ILL systemd[1]: mongod.service: Failed with result 'signal'. kernel: [ 6736.315052] traps: mongod[55040] trap invalid opcode ip:560ef34c08fc sp:7fff6abcb6d0 error:0 in mongod[560eef305000+4286000] Где еще что можно посмотреть, в чем проблема? Устанавливал через http://repo.mongodb.org/apt/debian bullseye/mongodb-org/7.0 main

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

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

Создай индекс

создал, вот так не работает

создал, вот так не работает

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

1 минута

создал, вот так не работает

а что за данные, которые нужно хранить 15с?

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

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

Всем привет) Коллеги, кто знает, почему метод у Mongoose .findOneAndUpdate перезаписывает документ в базе? Через $set или просто положив целевые поля, метод перезаписывает документ, т.е.удаляет те поля, которые не обновляю. В доке подобное поведение не нашёл.

Всем привет) Коллеги, кто знает, почему метод у Mongoose .findOneAndUpdate перезаписывает документ в базе? Через $set или просто положив целевые поля, метод перезаписывает документ, т.е.удаляет те поля, которые не обновляю. В доке подобное поведение не нашёл.

меняет только то что сказано менять. Если будет использован $unset то тогда уберет указанные поля. Для полной замены документа нужно использовать replaceOne

Да вот тоже так думал, но этот код: .findOneAndUpdate( { _id }, { ...updatingData }, { new: true, runValidators: true } ); удаляет те поля, которые я не обновляю

это не надо new: true,

так это лишь для того, чтобы обновлённый док вернуть, это же не для логики обновления

updatingData тут что?

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

$set должно быть для обновления полей

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

удаляет поля, которые не обновляю

$set должно быть для обновления полей