Третий сверху покрывает указанный запрос

Третий сверху покрывает указанный запрос

Тогда почему запрос выполняется долго?

Вероятнее всего из-за количества документов которые попадают под это конкретное условие

https://docs.mongodb.com/manual/reference/method/db.collection.aggregate/#return-information-on-aggregation-pipeline-operation

https://docs.mongodb.com/manual/reference/method/db.collection.aggregate/#return-information-on-aggregation-pipeline-operation

https://hastebin.com/elarucoguz.bash

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

https://hastebin.com/elarucoguz.bash

А какой версии монга?

А какой версии монга?

db version v3.2.19

Попробуйте тот-же самый запрос на девелоперской машине с 3.6. Там больше информации о выполнении агрегационных запросов в explain

А сколько всего документов в коллекции?

У вас, кстати, уже есть даже индекс с created at. Так что лучше сначала найти максимальную дату, а потом уже по ней агрегировать. Меньше данных в выборке, быстрее будет.

Можно ещё убрать project

Положив конверсию даты в group

Но это надо проверять,возможно сокращение размера документа до групиовки тут помогает

ребят а напомните какой exporter для монго стоит использовать ?

Ребятки прувеет!)) Подскажите пожалуйста, я хочу узнать есть ли поле "comments" в определенном документе ("_id":"11111") Делаю такой запрос: db.tasks.find({"_id":task_id},{"comments":{"$exists":True}}) приходит ошибка: Unsupported projection option: comments: { $exists: true } "$exists":True - ищет по всем документам Как сделать if exist для определенного документа? Спасибо)

Ребятки прувеет!)) Подскажите пожалуйста, я хочу узнать есть ли поле "comments" в определенном документе ("_id":"11111") Делаю такой запрос: db.tasks.find({"_id":task_id},{"comments":{"$exists":True}}) приходит ошибка: Unsupported projection option: comments: { $exists: true } "$exists":True - ищет по всем документам Как сделать if exist для определенного документа? Спасибо)

Перенесите условие по comments в первый хеш

По-умолчанию условия в запросе объединяются через логическое И

Перенесите условие по comments в первый хеш

.find({"comments":{"$exists":True}},{"_id":task_id}) так?

Вы ищите документ в котором id равен Y «И» поле существует

Да

Да

странно, выдало вообще не понятный результат? список [{'_id': '44444'}, {'_id': '33333'}, {'_id': '55555'}, {'_id': '22222'}]

А, вы опять два хеша передаёте

.find({"comments":{"$exists":True}, "_id":task_id})

Первый аргумент запрос, второй аргумент фильтр полей

Первый аргумент запрос, второй аргумент фильтр полей

Понял, Спасибо большое)

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

Спасибо! Это решило вопрос. А какой индекс в итоге нужно оставить?

Если запрос с датами, то последний

Если запрос с датами, то последний

А value там нужен?

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

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

ОК, спасибо.

Протестируйте несколько вариантов: compound index по трёх полям и два индекса: compound по operation и cred.rand плюс индекс по дате

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

В питоне вероятно есть какой-то метод проверки пустоты списка

https://www.pythoncentral.io/how-to-check-if-a-list-tuple-or-dictionary-is-empty-in-python/

Mongoose?

http://mongoosejs.com/docs/api.html#document_Document-markModified

ребят, такой вопрос: используя aggregation framework нужно придерживаться какого-то определенного порядка $unwind,$project и тд. или можно прописывать запросы по личному удобству?

понял, спасибо)

За большую базу рекомендую почитать про реализацию GridFS. В документах MongoDB можно хранить бинарные данные — картинки, mp3 и так далее. Для данных размером более 1 Мб рекомендуется использовать GridFS. GridFS — это соглашение о хранении файлов произвольного размера в MongoDB, поддерживаемое всеми официальными драйверами.

За большую базу рекомендую почитать про реализацию GridFS. В документах MongoDB можно хранить бинарные данные — картинки, mp3 и так далее. Для данных размером более 1 Мб рекомендуется использовать GridFS. GridFS — это соглашение о хранении файлов произвольного размера в MongoDB, поддерживаемое всеми официальными драйверами.

спасибо!

Всем привет! Подскажите, пожалуйста: Есть полигоны городов, внутри них точки ресторанов. Выбираем по _id ресторан. Как-то можно узнать с помощью запроса, что ресторан находится в городе N ? Или это нужно связь parent-child создавать?

Т.е. вы хотите по координатам ресторана получить его город?

Т.е. вы хотите по координатам ресторана получить его город?

Всё верно

Всё верно

Геопоиск это дорогая операция. На мой взгляд лучше сразу при получении координат кешировать указатель на город. В остальном: вам нужен reverse geocoding. Создайте коллекцию, где каждый документ город с полигоном, отписывающим его границы. Дальше по координате ресторна запрашивайте с помощью geoWithin, в какой из полигонов попадает ресторан.

Или через geoIntersects

Геопоиск это дорогая операция. На мой взгляд лучше сразу при получении координат кешировать указатель на город. Вы имели ввиду следующее: выбрать все рестораны внутри полигона города N и проставить им parent: _id города?

Ну то есть, мне сейчас надо пройтись по всем городам, выбрать у каждого города рестораны и в каждый документ ресторана добавить строку parent: _id города (тем самым создав связь с родительским объектом). Или всё-таки не так?

Ну вроде понял. Спасибо)

Подскажите пожалуйста как в nosql сделать грамотно модель данных для примерно такой задачи: будет документ заказа, в нем необходимые позиции товара. И другие пользователи должны будут предлагать свои варианты по этому заказу. Соответственно потом будет формироваться окончательный заказ исходя из предложенных вариантов. Я не прошу за меня все тут расписывать, но был бы признателен если на словах объясните приблизительную организацию документов. Опыта в монге нет, и похожих задач не видел а наговнякать не хотелось бы. Заранее спасибо

Подскажите пожалуйста как в nosql сделать грамотно модель данных для примерно такой задачи: будет документ заказа, в нем необходимые позиции товара. И другие пользователи должны будут предлагать свои варианты по этому заказу. Соответственно потом будет формироваться окончательный заказ исходя из предложенных вариантов. Я не прошу за меня все тут расписывать, но был бы признателен если на словах объясните приблизительную организацию документов. Опыта в монге нет, и похожих задач не видел а наговнякать не хотелось бы. Заранее спасибо

В оф. документации есть подробное описание самых ходовых способов организации документов с примерами «правильного» применения. В конкретном случае я бы наверное сделал 2 коллекции: заказы и товары. Заказ - документ с массивом id товаров + поля для описания. Ну а товар - документ с нужными полями. Но это если думать 3 секунды. Дьявол в деталях.

Подскажите пожалуйста как в nosql сделать грамотно модель данных для примерно такой задачи: будет документ заказа, в нем необходимые позиции товара. И другие пользователи должны будут предлагать свои варианты по этому заказу. Соответственно потом будет формироваться окончательный заказ исходя из предложенных вариантов. Я не прошу за меня все тут расписывать, но был бы признателен если на словах объясните приблизительную организацию документов. Опыта в монге нет, и похожих задач не видел а наговнякать не хотелось бы. Заранее спасибо

не холивара ради, а почему носкл? чем обычный sql не устроил? есть какието требования, которые не покроет тот же mysql?

В оф. документации есть подробное описание самых ходовых способов организации документов с примерами «правильного» применения. В конкретном случае я бы наверное сделал 2 коллекции: заказы и товары. Заказ - документ с массивом id товаров + поля для описания. Ну а товар - документ с нужными полями. Но это если думать 3 секунды. Дьявол в деталях.

Ну навскидку тоже так думаю

не холивара ради, а почему носкл? чем обычный sql не устроил? есть какието требования, которые не покроет тот же mysql?

Да хочется именно с монгой познакомиться

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

Всем привет, работаю с mongodb через асинхронный драйвер у меня при возникновении ошибки singleresultcallback не генерирует никаких ошибок https://gist.github.com/eltgm/4df959ff0e7f42aa7e8b471d5238c831 вот пример у меня приходит не валидный фильтр accountFilter(по этому фильтру он не найдёт необходимый документ), в onError мне нужно вывести ошибку как это сделать или что исправить, чтоб мне приходила ошибка? пытался гуглить это, не получилось

вот из документации The MongoDB Asynchronous Driver API mirrors the new Synchronous MongoDB Driver API, but asynchronous methods that make network I/O operations take a SingleResultCallback<T> and return immediately. The SingleResultCallback<T> interface requires the implementation of a single method onResult(T result, Throwable t) which is called upon the completion of the operation. Upon successful operation, the result parameter contains the result of the operation. If the operation failed for any reason, then the t contains the reason for the failure. If the operation failed for any reason, then the t contains the reason for the failure. причина ошибки, в моём случае, отсутствие документа, удовлетворяющего заданному фильтру но мне приходит result null и t null

mongodb-async-java

Ну навскидку тоже так думаю

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

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

Отчасти да, но на это обычно больше уходит время. Хотя да, согласен, понимания будет больше

парни, здорова) подскажите, почему 29 строка вызывает ошибку? я вроде нагуглил тот вариант, что такая ошибка бывает, когда закрывешь базу перед тем, как выполнить операцию с бд, но у меня же метод close вызывается в колбеке метода, значит должен выполняться тогда, когда inserrt уже выполнится

Отчасти да, но на это обычно больше уходит время. Хотя да, согласен, понимания будет больше

просто одно дело начать разбираться спотыкаясь на базовых вещах, чем сделав все по инструкции потом пытатсья в это въехать. В вашем случае пока что все видится как обычная плоская модель юзер-заказ-товары, где у заказа массив и в нем id-шники товаров (вероятно с суммой и видами действующих акций на момент прикрепления товара к заказу)

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

А покажите объявление переменной db

И вообще вы что-то делаете не так, раз закрываете соединение с базой после запроса

вот из документации The MongoDB Asynchronous Driver API mirrors the new Synchronous MongoDB Driver API, but asynchronous methods that make network I/O operations take a SingleResultCallback<T> and return immediately. The SingleResultCallback<T> interface requires the implementation of a single method onResult(T result, Throwable t) which is called upon the completion of the operation. Upon successful operation, the result parameter contains the result of the operation. If the operation failed for any reason, then the t contains the reason for the failure. If the operation failed for any reason, then the t contains the reason for the failure. причина ошибки, в моём случае, отсутствие документа, удовлетворяющего заданному фильтру но мне приходит result null и t null

это нормально

нет ошибки