Ilya
ответ со СО The uniqueness constraint for _id is per collection, so yes - one and the same ID can occur once per Collection. It's however very unlikely, if not impossible, for the same ID to be generated twice. So in order for this to happen you would have to manually insert duplicate IDs.
Ilya
возможно но очень маловероятно
Ilya
возможно но очень маловероятно
Суть в том, что я хочу перенести некоторые записи из одной коллекции в другую И думал удалить у переносимой записи I'd и при течение он назначится Или можно просто тупо скопировать из одной коллекции в другую, но как-то мне не очень такой подход
Ilya
а какой объем данных?
Ilya
вообще если нет завязки на _id в другиг коллекциях то можно и не парица и пересоздать
Ilya
но это мое мнение оно не экспертное ниразу)))
Daniil
для чего?
Daniil
если он используется где то в бизнес логике, то можно добавить новым документам поле oldId например и там хранить идентификатор из коллекции А
Ilya
если он используется где то в бизнес логике, то можно добавить новым документам поле oldId например и там хранить идентификатор из коллекции А
да, так и сделал еще сейчас допиливаю пару проверок и все просто не хотел заморачиваться, а все таки пришлось
Гена
Коллеги, у меня вопрос. В шардированную коллекцию идут одинаковые запросы, идентичные по структуре. НО бывают пики во времени ответа. По логам монги видно что то запрос бежит 100мс то 2с С чем это может быть связано?
Гена
куда копать?
yopp
День добрый, вопрос: Повторяется ли монго id в разных коллекциях?
Можно считать что нет. Шанс коллизии мизерный, особенно если в коллекции не часто пишут (<100...1к вставок в секунду). А если коллизия и будет, вы получите ошибку при вставке и такую ситуацию можно будет разрешить руками.
yopp
куда копать?
Смотреть в профайлер и observability
Гена
профайлер не был включен. Пик произошел спонтанно
yopp
Профайлер оставьте включённым c таким трешхолдом по времени, который будет ловить запросы которые не укладываются в ваш QoS
Гена
ну по логам видно что запросы по структуре одинаковые, но некоторые подскакивают до 2-3с а некоторые нормально бегут в 100мс
Гена
в профайлере не будет информации по причине такого поведения
yopp
В профайлере будет видно по каким именно ключам это происходит
yopp
Одинаковые по структуре запросы могут задевать разве объемы данных
yopp
Но если вы так и не вкрутили систему, которая позволяет вам ретроспективно получать объективные данные о происходящем в всем кластеру, к сожалению, ответа на ваш вопрос не будет. Потому что это может быть всё что угодно
Гена
понял. Спасибо)
Гена
еще вопрос - может быть проблема в том что из-за сетевого лага между сервером монгоса и шарда время ответа увеличилось?
Гена
@dd_bb
yopp
Конечно. Монгос это прокси до кластера
Гена
Спасибо
Yehor
добрый день, подскажите пожалуйста можно ли сделать запрос в монгу, где структуру приблизительно следующая { _id: '...' data: { id: '...', name: '...', symbol: '...' } } db.collection.find({ id: '..' }, { data: 1 }); второй аргумент указывает, что достать нужно только поле data, а можно ли достать еще из него только поля name и symbol без id?
Гена
Конечно. Монгос это прокси до кластера
То есть получается такой сценарий 1. запрос с приложения попал в монгос 2. Монгос отправил его на нужный шард 3. Шард вернул вывод в теории если в 1 или 2 (а может и в 1 и 2) случае был сетевой лаг, то монга запишет время ответа в лог с учетом этого лага, верно?
yopp
Экспортируйте время со стороны приложения и сравнивайтесь со временем в монге
yopp
Если дельта большая, то вероятно проблемы с сетью
Гена
Экспортируйте время со стороны приложения и сравнивайтесь со временем в монге
по метрикам приложений из графаны видно что время ответа подскочило, это и наблюдается и в логах монгод шардов. Адекватных причин, кроме сетевого лага, я не могу найти. Так как запрос, а именно фильтр по запросу find одинаковый, не идентичный, но структура одна.
Гена
Проверьте руками запрос
экспелейн на него?
yopp
Да
Гена
сейчас, секунду
yopp
Но ещё может так быть, что запрос задел большой объём холодных данных и монга поехала на диск
Гена
проверил через sar -d, диск не были нагружены
yopp
Им не надо быть нагружённым
yopp
У вас ssd/nvme или hdd?
Гена
сейчас уточню у инфры
Гена
не думаю что это возможно
Андрей
Есть такой кейс: 3 фотоальбома, в альбоме могут быть фотосерии, фотосерия это сет из 10-30 картинок. Нужно будет делать crud над фотосериями Можно сделать так что создать модель серии и клепать документы { name: 'Some name', images: [1.jpeg, 2.jpeg, 3.jpeg], album: 'some album' } Этого будет достаточно? Я еще видел такой вариант что создаётся отдельно модель Image, но в каком случаи нужно создавать отдельно модель картинки и от нее создавать картинку и ложить документ в серию?
Андрей
Только не трольте плиз я начинающий
yopp
база маленькая, до 2гб
Если данные ранее не запрашивались, то вполне возможно
Гена
Если данные ранее не запрашивались, то вполне возможно
Ну как версия хорошая. Покопаю и там. Просто меня удивляет, что время ответа просто так подскочило. При этом в ресурсы ОС не упирается, диски не нагружены.
yopp
Разбор таких вещей без доступа к записям чёрных ящиков это крайне неэффективное занятие
yopp
Если это был один запрос, это doesn’t worth the effort
yopp
Стоит беспокоиться когда это станет системой
Гена
Если это был один запрос, это doesn’t worth the effort
Нет, это не один запрос. В том то и дело, что бывают всплески совершенно рандомно. Не часто но бывают
Гена
Ладно, рабочий день уже закончился)) всем хорошо отдохнуть)
yopp
Смотрите в explain
Гена
Смотрите в explain
Да, думал завтра этим и займусь) спасибо
yopp
Можно и так, да. Можно сложить в бакеты по группам или по датам
yopp
В монге проще всего проектировать схему по принципу «пишем так, как читаем»
yopp
Если вы показываете расписание для группы на дату, то можно складывать в бакет «группа, дата»
Dmitry
Всем привет! Подскажите плиз.. делаю запрос к mongodb из GO count, _ := collectionReq.CountDocuments(context.TODO(), bson.D{{ "request", bson.D{{ "$ne", nil, }}, }}) В таком виде все работает.. но мне нужно проверить на nil "request.object", если в запрос вместо "request" подставить "request.object" - то ничего не находит. Подскажите, как сформировать запрос.. чтобы проверить на nil "request.object"
Dmitry
пардон) все работает.. зацепился на ту базе где действительно нет таких записей
Dmitry
))
Zaff
Привет всем. Есть какой-то способ сделать следующее? Model.update( { someField: { $cond: { if: { $lt: [ '$someField', someValue ] }, then: someValue, else: '$someField' } } }, { $set: {...} } )
yopp
В 3.2 только через агрегацию и вывод данных в другую коллекцию через $out А 3.2 уже больше года не поддерживается, вам нужно запланировать обновление до 3.6, а ещё лучше до 4.2
yopp
Вы на выходе получите коллекцию с обновлённым документами. И дальше можете, например, переименовать оригинальную, и потом новую назвать по старому
yopp
Если это одноразовая штука, то вы можете просто в цикле перебрать все документы и обновить по одному
yopp
А, подождите, вы хотите просто обновить все документы, у которых значение меньше X?
Zaff
А, подождите, вы хотите просто обновить все документы, у которых значение меньше X?
если у филда А значение меньше Х, то надо считать, что его значение = Х (но не обновлять это значение в самом документе) и потом есть еще одно условие, после которого сам апдейт
Zaff
in each Doc if A < X let A2 = X where A2 == Y, set Doc.C = some value
yopp
Не вижу зависимости между x и y в условии
yopp
Если нужно выбрать A2 == Y, то это одна история