Это ты про что конкретно, я что-то не нашел в ченжлоге и не гуглится

В 3.4 добавили вьюхи

Вообще, для того же, для чего и в других базах, имхо. Сделать вьюху с aggregation на стороне сервера и потом доставать из не данные обычным find

Оно ченжлог по 3.2 только гуглит, дай линк плиз, на телефоне неудобно

Вообще, для того же, для чего и в других базах, имхо. Сделать вьюху с aggregation на стороне сервера и потом доставать из не данные обычным find

У меня было именно такое подозрение:)

Материализовывать умеет?

И инкрементально апдейтить?

Иначе, это просто хранимая процедура. Что само по себе не плохо, конечно

Оно ченжлог по 3.2 только гуглит, дай линк плиз, на телефоне неудобно

Оно ещё релиз кандидат

https://docs.mongodb.com/v3.4/release-notes/3.4/

И инкрементально апдейтить?

Read only Они

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

Read only Они

Апдейтить материаоизацию мне надо

Read-only Views — MongoDB Manual 3.4 https://docs.mongodb.com/v3.4/core/views/#reference-views

Ссылка

Хранимка, короче, но с возможностью ограничено пихнуть дальше в AF

Или выбрать не всё. Ну, прикольно. Ещё один кусочек кейсов для MR подъели

гайз

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

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

ObjectID

мм

чет не догоняю причем тут таймстамп

и обжектайди

Потому что таймстам включен в ObjectID

Те можно сделать меньше больше по ObjectID

Причем с него начинается

http://lmgtfy.com/?q=mongodb%20ObjectID

Всем привет. Подскажите пожалуйста почему робомонго и другие визуальные проги не видят коллекции и данные если монга юзает ваертриггер движок?

Всем привет. Подскажите пожалуйста почему робомонго и другие визуальные проги не видят коллекции и данные если монга юзает ваертриггер движок?

Возьми версию посвежее, возможно из git

Всем привет. Подскажите пожалуйста почему робомонго и другие визуальные проги не видят коллекции и данные если монга юзает ваертриггер движок?

в шелле видно?

в шелле видно

пробовал и то и то

не помогает

не нашел ни одного гуишного инструмента

Аутентификация/авторизация включены?

Видимость коллекций от стораджа не зависит.

авторизация не включена

все по дефолту

может ты не в той базе смотришь просто?

ух ты, сразу две девушки! или фэйк?

не обольщайтесь, одна из них эйчарша :)

Nastya привет :)

Омг

))

Две дамы среди ночи заинтересовались MongoDB.

да и ты посреди ночи в чате зависаешь ) на дринкап питонист не ходил, Рома? :)

Неа :( я приболел, как и Серега

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

оу, ясно.

Сходил на дегустацию португальских вин и портвейна :))

не обольщайтесь, одна из них эйчарша :)

Дмитрий, привет) Попрошу не путать) я рекрутер, а не эйчар))

А в чём принципиальная разница?

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

а рекрутер исключительно хантингом?

Понятно.

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

Отпуска и прочие бумаги - это спец по КДП)) HR занимается подбором, наймом, адаптацией, обучением и пр и пр

а рекрутер исключительно хантингом?

Рекрутер, да, поиском и наймом.

Рекрутер, да, поиском и наймом.

Ну, т.е. рекрутер это такой специализированный hr

Не важно, в общем Настя будет вам хантить:)

А ещё вчера в телеграмчике появилась её коллега, но пока не светится в сообществах:)

Коллеги, подскажите одну интересную вещь. Запускаю агрегацию по двум параметрам - x: { $in: ... } и y: {$gt: ...}.

Есть compound index. x: -1 и y: -1.

Агрегация работает в два раза быстрее, если есть отдельно x: -1.

Есть ли какое-то логическое объяснение этому кроме странностей агрегаций?

Есть ли какое-то логическое объяснение этому кроме странностей агрегаций?

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

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

Использовался.

Но по x: -1 быстрее, чем по x: -1 и y: -1.

Да-да, именно в таком ключе. То есть я создаю два индекса (x: -1 и x: -1, y: -1).

Если используется x: -1, y: -1, то работает хуже, чем при x: -1.

Почему такое может быть? Возможно, дело в моих данных, но я с таким не сталкивался.

x y 99 99 88 88 77 88 66 88

И вот когда по x шагает, то делает это быстрее, чем по x + y, хотя есть условие, что y больше чего-то там.

Если используется x: -1, y: -1, то работает хуже, чем при x: -1.

Двойной индекс не влезает в память?

Двойной индекс не влезает в память?

Не знаю, прямо сейчас играюсь. Кажется, что он не использует нужный индекс.

Больше поиска, потому что куски результата по in разбросаны по разным кусками индекса из-за разных y

Не знаю, прямо сейчас играюсь. Кажется, что он не использует нужный индекс.

Что я с самого начала написал?:)

Там explain же, все дела, не?

"winningPlan"=>{"stage"=>"CACHED_PLAN", "inputStage"=>{"stage"=>"FETCH"

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

"inputStage"=>{"stage"=>"IXSCAN"

А потом идёт по индексу.

По второму полю.

Двойной индекс не влезает в память?

А как-то можно проверить? Но на сервере 64 GB оперативы, в mongostat всё влезает.

Ну, ни одна база не будет использовать индекс при условии gt и отсутствии сортировки

Ну, ни одна база не будет использовать индекс при условии gt и отсутствии сортировки

Так, я тут не понял.

Раньше же использовала.

А потом winningPlan поменялся.

Ну, попробуй запросами поиграть. Простыми find

Сейчас включу $sort.

Ну, попробуй запросами поиграть. Простыми find

Простые не нужны, вся суть в агрегации.

Там $in на пару тысяч элементов.

Простые не нужны, вся суть в агрегации.

Query одинаковый же поисковый

Поисковый да. А, я понял, про что ты.

Посмотреть на индексы там.