процессинг элементов из коллекции. берется N документов, обрабатывается. Процесс стартует заново. Кол-во элементов в курсоре нужно для логов / чтобы не передавать лишнее (избыточное) значение между калбэками итд метод есть, почему бы не использовать.

а что мешает просто сделать счетчик на стороне приложения?

проблема была только в том после limit/skip нужно не забывать with_limit_and_skip ставить в .count()

это целый минус один запрос в базу на каждый такой запрос

а каждый запрос в бд на порядки дороже счетчика

уже сделал

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

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

wc -l не подойдёт?

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

Напиши скрипт который его развернет и проверит

Напиши скрипт который его развернет и проверит

большой бекап

большой бекап

Ну мы так и делаем на бекап сервере

Каждый раз скриптом разворачиваем на staging

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

Очень важно определится что такое «рабочий бэкап»

Очень важно определится что такое «рабочий бэкап»

рабочий бекап (это копия базы на момент сотворения бекапа)

Это очень плохое определение

Нужны конкретные признаки «рабочести»

Измеримые

Это очень плохое определение

а есть какая то теория бекапов ?

определяющая все эти понятия

Каждый раз скриптом разворачиваем на staging

. Не просто так на staging

Ибо если будет битый->тесты завалятся

а есть какая то теория бекапов ?

Ваша бизнес-логика :)

Проверка целостности данных — адски сложная штука

Нужно найти какие-то признаки, которые можно сверять.количество документов например. Или если вы храните заказы, то ещё и сумму.

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

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

Пустой бекап будет вполне себе доступен

А пустые бэкапы это очень частая проблема

можно проверять кодвозврата mongodump-а, размер бекапа /bin/mongodump --username "$DUMPUSER" --password "$DUMPPASS" --authenticationDatabase admin --out ${CURBACKUPDIR} --gzip 2> dump.log STATUS=$? ... SIZE=$(du -sb ${CURBACKUPDIR} | awk '{print $1}') zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -z ${ZABBIX_HOST} -p 10051 -k mongo.backup.status -s "$HOSTNAME" -o "$STATUS" zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -z ${ZABBIX_HOST} -p 10051 -k mongo.backup.size -s "$HOSTNAME" -o "$SIZE" zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -z ${ZABBIX_HOST} -p 10051 -k mongo.backup.path -s "$HOSTNAME" -o "${CURBACKUPDIR}" в мониторинге пиликать на нулевой статус, неприлично мелкий размер бекапа

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

Это косвенный показатель целостности

Бэкап может быть большим, но битым

опять же как и говорит @dd_bb нужно для себя явно обозначить критерий "целостности" иначе любые действия будут бесполезны

Тут вопрос, вы хотите бэкапы для галочки или для данных

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

Это уже можно назвать достаточно формальным признаком. Если этого достаточно, тогда импортировать и проверить код возврата процесса. Самоя простая и быстрая проверка — посмотреть размер файла бакапа или количество строк (wc -l). но она и самая не надежная. Самая надежная - произвести вычисления на боевой и восстановленной из бакапа базе (типа суммы, как предлагал yopp) но это и долго. Вот вам 2 крайности, выбирайте вариант внутри.

Это уже можно назвать достаточно формальным признаком. Если этого достаточно, тогда импортировать и проверить код возврата процесса. Самоя простая и быстрая проверка — посмотреть размер файла бакапа или количество строк (wc -l). но она и самая не надежная. Самая надежная - произвести вычисления на боевой и восстановленной из бакапа базе (типа суммы, как предлагал yopp) но это и долго. Вот вам 2 крайности, выбирайте вариант внутри.

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

Размер это не проверка

Даже контрольная сумма не проверка

Потому что по миллиону причин пока у вас может быть битый файл

И процесс завершится успешно

@yopp а можешь пример рассказать на какой то тестовой базе , так как пока что звучит сложно . не получается грамотно сказать что же является целым бекапом( для начала хочется чтобы он был не пустой хотябы)

{ _id: "...", Data: { "key1": "value1", "key2": "value2" } } Нужно поменять значение value2 на value3 update({ "Data.key2": "value2" }, { $set: { "Data.key2": "value3" } }) Правильно?

{ _id: "...", Data: { "key1": "value1", "key2": "value2" } } Нужно поменять значение value2 на value3 update({ "Data.key2": "value2" }, { $set: { "Data.key2": "value3" } }) Правильно?

updateOne undateMany or update multi true

updateOne undateMany or update multi true

Та не суть, мне главное json

{ _id: "...", Data: { "key1": "value1", "key2": "value2" } } Нужно поменять значение value2 на value3 update({ "Data.key2": "value2" }, { $set: { "Data.key2": "value3" } }) Правильно?

Правильно

Правильно

Danke

Как можно найти все документы, где status = "progress" или "finished"? .findOne({ status: "progress" })

{status: { $in: ["progress", "finished"] }}

Спасибо

Приветы. А насколько плохая идея использовать aggregation framework для обычных регулярных запросов? Понятно, что нереляционность, документо-ориентированность и вот это всё. Но тем не менее случилось страшное - надо джойнить данные две колекции и фильтровать одну на основе полей других. Фактически есть еще путь с хранением избыточных данных. Но интересно попробовать aggregation.

{boys:{ Max:{...}, John:{...}} Как найти документы, у которых в объекте boys есть объект Max? через $in?

$exists

Благодарю

Приветы. А насколько плохая идея использовать aggregation framework для обычных регулярных запросов? Понятно, что нереляционность, документо-ориентированность и вот это всё. Но тем не менее случилось страшное - надо джойнить данные две колекции и фильтровать одну на основе полей других. Фактически есть еще путь с хранением избыточных данных. Но интересно попробовать aggregation.

Не бывает хороших или плохих идей. Возьмите срез ваших данных и моделируйте запросы

Не бывает хороших или плохих идей. Возьмите срез ваших данных и моделируйте запросы

А я вот нигде не найду никаких данных о его произодительности. Знаю, что встроенный map-reduce раньше был однопоточный. А aggregation? Единственный ли ограничивающий фактор у него производительность пайплайна который я передаю или есть еще что-то?

Я же вам говорю: лучший способ получить ответы на все ваши вопросы — моделирование на реальных данных

AF во многих моментах сильно лучше чем M/R. Но это тоже не серебрянная пуля. Если вы решите в шарде отсортировать 100Тб коллекцию по неиндексируемому полю, то это однинаково не будет работать как с find так и с AF

Я же вам говорю: лучший способ получить ответы на все ваши вопросы — моделирование на реальных данных

Окай. Уже упражняюсь. Спасибо )

Задавай вопросы, если что-то будет не так идти

Ну и да, по полям по которым делают lookup индексы нужны

Иначе будет медленно, сканами коллекции

Вам в группу по js. Маловероятно что тут кто-то поможет с драйверами или ODM