да но тогда почему обычный .count() занимает столько времени

написано, что DEPRECATED, попробуйте count_documents

он только недавно стал deprecated

да и какая разница говорю же из монго консоли то же самое

на js

надо на jira еще у них пошуршать

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

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

какого метода?

Курсор просто описывает запрос к бд, а выполнение всех действий курсора выполняется уже при соответствующем вызове

нашел https://jira.mongodb.org/browse/SERVER-3268?jql=text%20~%20%22cursor%20count%22

> c.count(true) 1000

вооо

так быстро работает

вообщем после .limit() если хочешь узнать сколько там элементов в курсоре нужно делать cursor.count(true)

только вот порос зчем вам каунт если вы его итак лимитировали 1000

а там может быть меньше / больше

больше не может, лимит же

cursor.count(with_limit_and_skip=True) в pymongo

1000 от балды значение вариативно

я не про это, суть count() посчитать количество доков подходящих под условие, которые лежат в бд

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

может опишите задачу которую вы решаете и я тогда пойму почему так а не иначе

https://docs.mongodb.com/manual/reference/method/cursor.count/

Counts the number of documents referenced by a cursor. Append the count() method to a find() query to return the number of matching documents.

решена задача уже

допустим решена, а как вы дальше используете полученное количество из count?

процессинг элементов из коллекции. берется 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? Единственный ли ограничивающий фактор у него производительность пайплайна который я передаю или есть еще что-то?