С lean сколько занимает?

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

Разбивать на отдельные коллекции одинаковые по структуре документы не самая эффективная стратегия, так как она не решает проблем которые такой разбивкой пытаются решить. Если хочется начинать увеличивать ресурсы, то более эффективно использовать шардинг и зонировать документы

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

в том то и дело, что на другой бд с версией 6.0.3 эта тулза работает прекрасно

запросы откуда медленно выполняются?

с консоли моментально, с вьюх типа dbgate, compas сек по 50

про первое не слышал, а компас какой версии?

про первое не слышал, а компас какой версии?

appName: 'MongoDB Compass', clientMetadata: { driver: { name: 'nodejs', version: '4.13.0' },

appName: 'MongoDB Compass', clientMetadata: { driver: { name: 'nodejs', version: '4.13.0' },

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

129 записей

а в другой БД структура доков такая же?

всего в коллекции

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

Всем привет! Ищу помощи с Котлином/монго или джавой/монго, кто разбирается в вопросе. Если вкратце, то не получается обновить поля в коллекции данных, содержащих сложные структуры данных, сейчас для обновления полей записи каждый раз выполняю метод replaceOne, которая вызывает проблемы при многопоточной работе с одной и той же коллекцией. Хочу найти способ заменить в документе только конкретные поля и сделать commit. Также есть пара вопросов про использование монги именно в спрингбут проектах, например, если конфигурация монги не является бобом, а сам проект спринг бутовский, могут ли из-за этого быть рассинхроны при многопоточном доступе к данным? Пишу на котлине спрингбут проект с ДБ монго, спасибо за обратную связь!

replaceOne заменяет полностью документ, скорее всего вам нужен updateOne плюс атомарные операции или транзакции https://www.mongodb.com/docs/manual/core/write-operations-atomicity/

Всем привет! Ищу помощи с Котлином/монго или джавой/монго, кто разбирается в вопросе. Если вкратце, то не получается обновить поля в коллекции данных, содержащих сложные структуры данных, сейчас для обновления полей записи каждый раз выполняю метод replaceOne, которая вызывает проблемы при многопоточной работе с одной и той же коллекцией. Хочу найти способ заменить в документе только конкретные поля и сделать commit. Также есть пара вопросов про использование монги именно в спрингбут проектах, например, если конфигурация монги не является бобом, а сам проект спринг бутовский, могут ли из-за этого быть рассинхроны при многопоточном доступе к данным? Пишу на котлине спрингбут проект с ДБ монго, спасибо за обратную связь!

по replaceOne - можете заменить: создаете лист updateOneModel. дальше пушите туда обьекты с обновлениями(через Update + Set) потом bulkwriteasync(list)

replaceOne заменяет полностью документ, скорее всего вам нужен updateOne плюс атомарные операции или транзакции https://www.mongodb.com/docs/manual/core/write-operations-atomicity/

Привет! А можно ли оптимизировать facet c count? На форумах пишут о проблеме с производительностью - я тоже столкнулся с этим. Но очень нуждаюсь в таких кверях для пагинации..

а в чём проблема использовать skip() & limit()?

нужно знать количество все равно

количество чего?

Документов, которые удовлетворили условие :)

для чего?

для статистки, допустим

эмм, зачем велосипед? https://www.mongodb.com/docs/manual/reference/method/db.collection.countDocuments/

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

https://stackoverflow.com/questions/20348093/mongodb-aggregation-how-to-get-total-records-count

Вопрос был не в том, как А можно ли оптимизировать Facet + count = кверя выполняется в 10 раз дольше

Вопрос был не в том, как А можно ли оптимизировать Facet + count = кверя выполняется в 10 раз дольше

Коллеги, как посоветуете лучше искать регуляркой имя пользователя, если оно лежит в двух полях (имя и фамилия), а надо чтобы строка "Иван Иванов" находила необходимого пользователя

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

Здравствуйте, в первой модели есть массив с id. С помощью этих id надо взять данные другой модели. Как можно это сделать. Сделал так, но не работает

после $poject стейджа у вас остается только _id и там не будет subscriptions поля

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

вот походу с массивом есть тонкости

все корректно, массив развернется, $in не нужно городить https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup/#use--lookup-with-an-array

все корректно, массив развернется, $in не нужно городить https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup/#use--lookup-with-an-array

проверьте название колелкции organization точно ли она в базе без s на конце

А как монго дает названия коллекция, добавляет s к названиям моделей?

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

вопрос с промежуточными вычислениями, сегодня писал логику работы апишного метода. там использую синхронно последовательно 6 запросов к БД с промежуточными расчётами. естественно, логика запросов базируется на результатах промежуточных расчётах. такие задачи в рамках "1 запроса" с каким-нить pipeline не решаются, как я понимаю?

не очень понял суть вопроса

вопрос с промежуточными вычислениями, сегодня писал логику работы апишного метода. там использую синхронно последовательно 6 запросов к БД с промежуточными расчётами. естественно, логика запросов базируется на результатах промежуточных расчётах. такие задачи в рамках "1 запроса" с каким-нить pipeline не решаются, как я понимаю?

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

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

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