Псевдо, потому что внутри motor создаёт пул тредов для запуска соединений с mongodb, а треды - это не асинхронность. В каждом треде живёт одно соединение. Асинхронного драйвера для mongodb в питоне нет.

Кстати, если кому интересно. Раскопал драйвер для python, вроде асинхронный по-настоящему: https://github.com/ZeoAlliance/aiomongo. Внутри посмотрел асинхронное соединение прямо с сервером и никаких тредов. Пишут, что сильно производительнее motor. Но его, особо никто не использует почему-то. И вялый проект какой-то. Странно...

Кстати, если кому интересно. Раскопал драйвер для python, вроде асинхронный по-настоящему: https://github.com/ZeoAlliance/aiomongo. Внутри посмотрел асинхронное соединение прямо с сервером и никаких тредов. Пишут, что сильно производительнее motor. Но его, особо никто не использует почему-то. И вялый проект какой-то. Странно...

Спасибо, может пригодится. 25 звёздочек - это норм, имхо.

Я тоже потестирую на досуге... По фичам вроде всё основное есть.

только вот Python 3.5.2 or later нужен. Не у всех есть...

Как можно понять, был ли документ изменен, добавлен, или документ вообще не изменялся при update?

Как можно понять, был ли документ изменен, добавлен, или документ вообще не изменялся при update?

После выполнения операции в консоль возвращается сколько документов изменено

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

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

нет, если не измененено он пишет, что изменено 0

вот пример: rs0:PRIMARY> db.stat_tmp.update({status: 8}, {x: 1}) WriteResult({ "nMatched" : 0, "nUpserted" : 0, "nModified" : 0 })

а у меня возвращает nModified: 1 даже если документ совпадает

а у меня возвращает nModified: 1 даже если документ совпадает

Верьте, значит изменён. Может тип данных поменялся

тип?

да нет, один и тот же код испольняю через nodejs, один и тот же обьект

тип?

да, поправил :)

да нет, один и тот же код испольняю через nodejs, один и тот же обьект

а документ большой? Попробуйте вместо update сделать find и посмотреть что с ним происходит

?‍♂️ сори, туплю, у меня там Date.now() в документе)

?‍♂️ сори, туплю, у меня там Date.now() в документе)

:) ну и хорошо, что разобрались :)

Привет всем!

Есть такой запрос http://dpaste.com/1K8VY4D . Он находит дату первого заказа для каждого пользователя. Теперь мне надо выбрать из заказов данные { id, is_first_order }. Это по сути $lookup, только для уже выбранных данных. Подскажите, как это сделать..

Есть такой запрос http://dpaste.com/1K8VY4D . Он находит дату первого заказа для каждого пользователя. Теперь мне надо выбрать из заказов данные { id, is_first_order }. Это по сути $lookup, только для уже выбранных данных. Подскажите, как это сделать..

Ну вообще, в агрегате вы можете сделать несколько лукапов. Вот ка здесь: https://stackoverflow.com/a/44153229/2733113

Там привязываются другие таблицы, а у меня вроде подзапрос.

Там привязываются другие таблицы, а у меня вроде подзапрос.

судя по as: 'users' в первом лукапе и далее foreignField: 'users._id' второй как раз на данных первого строится. Тут проще прпобовать

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

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

Да, пробуйте

Что-то вроде того - http://dpaste.com/2J91FZ5 и результат http://dpaste.com/2HKFD7A

Не знаю оптимально ли это, но тут по сути 2 запроса всего

Что-то вроде того - http://dpaste.com/2J91FZ5 и результат http://dpaste.com/2HKFD7A

Круть!

Спасибо за наводку)

пару часов просидел, думая

Не знаю оптимально ли это, но тут по сути 2 запроса всего

а объём данных какой? Если меньше миллиона, то и не заморачивайтесь

1000 где-то

пару часов просидел, думая

Взгляд со стороны всегда помогает :) на том и стоим :)

1000 где-то

1000 оно в памяти держать может даже без индексов

В конце еще добавлю { $group: { _id: { month: { $month: '$date_created', year: { $year: '$date_created' } } } и будет видна статистика returned и onetime покупателей по каждому месяцу

В конце еще добавлю { $group: { _id: { month: { $month: '$date_created', year: { $year: '$date_created' } } } и будет видна статистика returned и onetime покупателей по каждому месяцу

дело, сам статистику люблю!

с монго раньше не работал просто

с монго раньше не работал просто

да я и сам не то что бы спец большой, так, учусь понемногу...

Привет всем, такой вопрос, насколько функция remove быстрая? Просто получается такая ситуация, что у меня есть функция, которая запускает кроном каждые 5 минут: 1) достает из базы все данные 2)ремувит данные в таблице с помощью remove 3)меняет достаные данные чутка относительно новой инфы 4)инсертит эти же данные в таблицу

Я начал замечать, что информации в таблице очень мало и как-то не так работает инсерт

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

причем может быть раз в 10 минут, а может раз в 100 минут

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

асинхронность? в монге есть expire индекс, который сам будет удалять документы

Видимо самым простым вариантом будет делать инсерт после кэлбэка ремува

асинхронность? в монге есть expire индекс, который сам будет удалять документы

предлагаешь им просто дать цикл жизни? но ведь есть шанс промахнуться относительно инсерта

удалить данные раньше

удалить данные раньше

а у тебя они пересекаются? сделай unique индекс, пока данные есть он ещё раз их не вставит, потом удалит по индексу и ты вставишь

Привет всем, такой вопрос, насколько функция remove быстрая? Просто получается такая ситуация, что у меня есть функция, которая запускает кроном каждые 5 минут: 1) достает из базы все данные 2)ремувит данные в таблице с помощью remove 3)меняет достаные данные чутка относительно новой инфы 4)инсертит эти же данные в таблицу

Неадвно удалял 1 миллион документов, примерно секунд 10 заняло. Может вам подойдёт ttl индекс, как предлагал @yurii_chikhrai вот описание https://docs.mongodb.com/manual/core/index-ttl/

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

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

А на сколько плох вариант с инсертом после каллбэка ремова

?

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

Так может вам update использовать?

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

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

и потенциально таких записей может быть 1000-5000

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

и потенциально таких записей может быть 1000-5000

всё равно не вижу проблемы

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

Старая привычка от ментора)

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

а, то есть одним запросом всю 1000 доков не получится проапдейтить? тогда да, это плохой вариант...

по крайне мере пока что нет)

так как там полностью разные объекты

относительно каждой записи

если бы они были одинаковые, то да, updateMany и вперед

я так со статусами делаю, просто массив айдишников

и in

как альтернативу вы хотите сделать один файнд всего, изменение в апликации, ремув всего и инсерт изменённых данных. Верно я понимю?

ну как самый сбалансированный вариант в моей ситуации(по моему мнению) - это достать все записи из базы, ремувнуть таблицу, допилить это данные как мне нужно и заинсертить опять в базу

оно так и работает уже отсноительно долго

но только сейчас я заметил

что данные не накапливаются

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

а не до, как это прописано кодом

хотфиксом сейчас решил эту проблему вызово инсерта от resolve ремува

ну как самый сбалансированный вариант в моей ситуации(по моему мнению) - это достать все записи из базы, ремувнуть таблицу, допилить это данные как мне нужно и заинсертить опять в базу

тогда вы не сэкономите на операциях ведь?

почему? я делаю 3 запрос за 5 минут, вместо n запросов относительно количество данных в базе

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

ну дык insertMany же по сути один запрос идет

нет?

просто пихаю массив с кучей объектов

один раз

ну дык insertMany же по сути один запрос идет

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

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

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

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

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

ну не обязаетльно, соединение можно переиспользовать

тогда(чисто теоретически) это получается тот же самый апдейт(но мы этого не узнаем), но с чутка меньшим количеством кода

монга конечно приятнее sql(имхо), но подставить тоже умеет)

тогда(чисто теоретически) это получается тот же самый апдейт(но мы этого не узнаем), но с чутка меньшим количеством кода

да, узнать это сложно. > монга конечно приятнее sql(имхо) у меня тоже такое ощущение, хотя большинство назвали бы это садомаза :)

ну вот из бд, я сначала весьма долго был на монге

и вот только не так давно попробовал sql

поначалу было дико больно

но потом привык

но все равно монго ван лав

ну вот из бд, я сначала весьма долго был на монге

вот как бывает...

Привет всем, такой вопрос, насколько функция remove быстрая? Просто получается такая ситуация, что у меня есть функция, которая запускает кроном каждые 5 минут: 1) достает из базы все данные 2)ремувит данные в таблице с помощью remove 3)меняет достаные данные чутка относительно новой инфы 4)инсертит эти же данные в таблицу

Это частный случай проблемы синхронизации и вы выбрали не самый оптимальный способ

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