Всем спасибо за помощь, постараюсь протащить эту идею.

А я так _id использую, добавляю его вторым полем в индекс по нужному полю. Например, индекс есть на поле foo. Я делаю индекс {foo: 1, _id: 1}. Далее, если мне надо проитерироваться по коллекциюю по условию {foo: "ok"}, я итерируюсь с .limit(1000).sort({_id: 1}) и запоминаю послединий _id и далее использую его для того, чтобы вытащить вторую тысячу и т.д.

вам надо сначала округлить время до 30 минут, а это $mod и $div

не нужно ничего округлять

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

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

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

ну дальше уже логика какая ))

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

👍

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

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

уже было такое , но как-то решил это с createdAt & updatedAt

ну уже дальше по логике))

добрый день всем! вопрос по перформансу: насколько хорошо монго выдержит вложенные в сущность массивы по 5 тысяч элементов? все 5 тысяч - чисто строки

добрый день всем! вопрос по перформансу: насколько хорошо монго выдержит вложенные в сущность массивы по 5 тысяч элементов? все 5 тысяч - чисто строки

смотря что с ними делается

смотря что с ними делается

ничего, хранятся лишь, иногда дополняются

поиска по ним не будет точно

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

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

окей, хорошо, спасибо)

И больше 16мб не влезет.

Сейчас разбираю адовою легаси коллекцию

Кто может посоветовать, что почитать, по advanced filtering

Сейчас даже по фану пришлю снип

ничего, хранятся лишь, иногда дополняются

При обновлении документ будет обновляться целиком. Если latency при апдейтах не играет больший роли, то вполне ок.

https://paste.ubuntu.com/p/Z4tYjCSYrX/ ну не слишком адовая конечно, но страдать приходится хочу оптимизировать следующим образом - item.area.id перевести из string в int - cейчас ищу следующим образом: db.places.find({"item.type.id": "3"}) если id перекинуть в самое начало документа, тоесть db.places.find({"id": 3}) может ли мне это помочь ускорить поиск?

https://paste.ubuntu.com/p/Z4tYjCSYrX/ ну не слишком адовая конечно, но страдать приходится хочу оптимизировать следующим образом - item.area.id перевести из string в int - cейчас ищу следующим образом: db.places.find({"item.type.id": "3"}) если id перекинуть в самое начало документа, тоесть db.places.find({"id": 3}) может ли мне это помочь ускорить поиск?

а смысл

https://paste.ubuntu.com/p/Z4tYjCSYrX/ ну не слишком адовая конечно, но страдать приходится хочу оптимизировать следующим образом - item.area.id перевести из string в int - cейчас ищу следующим образом: db.places.find({"item.type.id": "3"}) если id перекинуть в самое начало документа, тоесть db.places.find({"id": 3}) может ли мне это помочь ускорить поиск?

Нет, не поможет

По item.type.id есть индекс?

По item.type.id есть индекс?

да, индекс есть

Покажите explain с execution stats

Покажите explain с execution stats

https://paste.ubuntu.com/p/3R4f4KHmXJ/ name, id - это маппинг к коллекции categories фронт также отправляет: page, items_per_page

Судя по explain у вас нет индекса

db.places.getIndexes() что показывает?

db.places.getIndexes() что показывает?

правильно ли понимаю, что нужно ручками проиндексировать item.type ?

item.type.id, да

сделал db.places.createIndex({"item.type.id": -1}) если не ошибаюсь стало быстрее) будьте, добры, подскажите, все правильно сделал?)

благодарю за интересную информацию

сделал db.places.createIndex({"item.type.id": -1}) если не ошибаюсь стало быстрее) будьте, добры, подскажите, все правильно сделал?)

Так посмотрите, изменилось ли что-то в explain()

всем привет. надо смигрировать данные из одной бд в другую. пишу скрипт. беру 50 записей из первой и хочу вставить в другую. есть метод insertMany, где просто вставляются записи. но мне надо предусмотреть случай когда запущена повторная миграция. поэтому я хочу чтобы массив записей или обновлялся или добавлялся. findOrUpdate. как это сделать?

всем привет. надо смигрировать данные из одной бд в другую. пишу скрипт. беру 50 записей из первой и хочу вставить в другую. есть метод insertMany, где просто вставляются записи. но мне надо предусмотреть случай когда запущена повторная миграция. поэтому я хочу чтобы массив записей или обновлялся или добавлялся. findOrUpdate. как это сделать?

mongodump/mongorestore

Так как _id сохраняется то повторная миграция свалится с ошибкой

mongodump/mongorestore

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

Так как _id сохраняется то повторная миграция свалится с ошибкой

поэтому я и хочу insertOrUpdate какой-то

Вставлять документы целиком с сохранением _id

Если нужна гарантия all or nothing, то внутри транзакции

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

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

хочу разбивать на несколько подходов

Нет смысл разбивать

mongorestore делает insert последовательно и все :)

ага, то есть mongorestore вообще поэлементно работает?)

прикольно

Возможно сейчас используется bulkWrite, так как есть сессии и возможность получить статусы конкретных операций, но до 3.4 просто insert

Разницы для монги нет

Bulk операции это сетевая оптимизация, экономия на ack

Ну и с появлением wire compression если документы похожие, то от сжатия выиграть можно немног

Bulk операции это сетевая оптимизация, экономия на ack

хотел сделать подобное const records = await dbSource .collection(coll.name) .find() .skip(i) .limit(limit) .toArray(); const promises = []; for (const rec of records) { promises.push({ updateOne: { update: rec, upsert: true, }, }); } await dbTarget .collection(coll.name) .bulkWrite({}, promises, { ordered: false });

Это будет очень медленно

Сделайте просто insert, передав _id оригинального документа

Этого будет более чем достаточно, так как повторная вставка будет нарушать unique constrain для _id

Это достаточная гарантия

const records = await dbSource .collection(coll.name) .find() .skip(i) .limit(limit) .toArray(); try { await dbTarget .collection(coll.name) .insertMany(records); } catch (err) { console.log('elements already migrated'); } тогда так и оставлю)

Не вижу смысла в skip/limit

но если на несколько миллионов  src коллекция

И ничего

с базой все норм будет?

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

skip/limit будет дороже

skip/limit будет дороже

но там же через ожидания работать будет. и будет по условно 200 элементов за раз вместо 2 млн

Skip дорого, потому что монге надо пропустить какое-то количество документов. А чтоб это сделать, надо в любом случае проехать как минимум по индексу

понял. хорошо а что делать с

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

.

Самый простой вариант остановить запись на время миграции

А в чём смысл миграции?

А в чём смысл миграции?

В предыдущей версии приложения сервис стучался в бд. В следующей меняем на другую и надо перенести все данные в новую

Нужно перенести данные на другой физический сервер?

Между авс инстансами Так что да Поэтому и пишу отдельный скрипт + доступа к сервакам с бд нет

Самый надежный вариант это поднять репликацию

Это вариант с минимальным временем отказа

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