мдамс трэшак

1 - 2 = 0 можно сделать (проверку на минимум 0), но это уже будет не атомарно по-любому, т.к это не сделаешь с $inc. или я не понимаю как

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

Проверку эту как часть фильтра указывайте

Хотя в вашей асинхронщине возможно будет тяжело это реализовать

events = [ { type: Borrow, timestemp: 1412414 value: 1 }, { type: Supply, timestemp: 1414212 value: 2 }, ] Всем привет, может выручите и подскажете в какую сторону смотреть, если я хочу сгруппировать события по timestemp и посчтитать sum(Borrow) / sum(Supply) на интервале

events = [ { type: Borrow, timestemp: 1412414 value: 1 }, { type: Supply, timestemp: 1414212 value: 2 }, ] Всем привет, может выручите и подскажете в какую сторону смотреть, если я хочу сгруппировать события по timestemp и посчтитать sum(Borrow) / sum(Supply) на интервале

Смотрите на aggregation framework

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

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

В каком таком? Если вы про массив, то можно unwind предварительно сделать.

группировка идет допустим по часу, мне за этот час нужно посчитать сумму всеx событий Borrow и это я понимаю как сделать, а как прикрепить к этому интерваллу сумму по Supply и посчитать их разницу не понимаю, и что то мне кажется unwind тут не спасет

А, так вам по разным таймстампам нужно? Могу предложить добавить поле «час»

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

вот примерный вариант

{ $match: { "created_on" : { $gte: minDate, $lt : maxDate } "eventType": {$in: ["Borrow, Supply"]} } }, { $group: { "_id": { "year" : { $year : "$created_on" }, "dayOfYear" : { $dayOfYear : "$created_on" }, }, "count": { $sum: "$value"(вот тут мне надо получить sum(Borrow)/sum(Supply) }, } },

В грппе считаете две суммы, потом делаете проджект и в нем вычисляете деление

как в группе посчитать две суммы?

для разных событий

как в группе посчитать две суммы?

https://play.db-ai.co/m/XJkf_J_RigABpe5O

в вашем случае чтото такое

немного извращенно конечно

https://play.db-ai.co/m/XJkf_J_RigABpe5O

Спасибо огромное, пусть даже извращенное, но жизнь спасет)

хотя наверное это вариант не совсем подходит, там же получается "_id": null, а у меня он должен быть сгруппированный по дате "_id": { "year" : { $year : "$created_on" }, "dayOfYear" : { $dayOfYear : "$created_on" }, },

так а что мешает дату указать?

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

4.0.7 (Mar 25) ◦ 3.6.11 (Mar 1) • Плейграунд для запросов: https://play.db-ai.co • Docs: https://docs.mongodb.com/manual/ • Learn MongoDB: https://university.mongodb.com Stable: 4.0.7 (https://docs.mongodb.com/manual/release-notes/4.0/#mar-25-2019) Bugfix: 3.6.11 (https://docs.mongodb.com/manual/release-notes/3.6/#mar-1-2019) Legacy: 3.4.20 (https://docs.mongodb.com/manual/release-notes/3.4/#mar-13-2019, EOL June ’19) End of life: 3.2.21 (Sep ’18), 3.0.15 (Feb ’18)

@dd_bb раз уж появился, а в плейграунде нет форматирования?

мож какая комбинация клавиш

Под форматированием что ты понимаешь?

типа жмешь кнопочку и оно все красиво выровнено отступами

Не-а. Надо?

Если надо — заведи тикет

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

В принципе ето не очень сложно, надо прост представление распарсеного объекта назад в eJSON сериализовать. На бэкенде оно уже сделано для вывода результатов, а на фронтенде надо сериализатор сколхозить

ща запилю ишью, а там смотри сам

https://github.com/db-ai/playground/issues/28

https://github.com/db-ai/playground/issues/28

👍

и еще один вдогонку https://github.com/db-ai/playground/issues/29

Слушайте, а как можно ускорить лукап, который через pipeline? { "$match": { "$expr": { "$eq": [ "$parentId", "$$tagId" ] } } }, В нем вот эта конструкция капец какая медленная

Добрый день. Пытаюсь разобраться в transactions и casual consistancy. В документации говорится, что операции с 1 документом атомарны. Но потом говорят, что другой поток может увидеть частичные изменен

Какая же это атамарность

Какая же это атамарность

Single document

Но другой поток не может увидеть частично изменённый докумен

В приведённом абзаце комментари про durability. Т.е. можно увидеть состояние документа которое потенциально может откатиться при роллбэке

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

Добрый день. Пытаюсь разобраться в transactions и casual consistancy. В документации говорится, что операции с 1 документом атомарны. Но потом говорят, что другой поток может увидеть частичные изменен

may not see a partially updated

Да. Меня смутило durable и вправду.

@dd_bb

Привет! Есть кластер в атласе 2 ядра 8 оперативы (М30). В бд-шке есть пару коллекций на 200К - 500К записей - запросы с простым find иногда отрабатывают по 15-30 секунд - при пиковых нагрузках на БД. Это нормально или у меня руки ростут ниже чем у обычных людей? Что можно потюнить? Стоит ли добалять оперативы/ядра (менять тип инстанса)?

Привет! Есть кластер в атласе 2 ядра 8 оперативы (М30). В бд-шке есть пару коллекций на 200К - 500К записей - запросы с простым find иногда отрабатывают по 15-30 секунд - при пиковых нагрузках на БД. Это нормально или у меня руки ростут ниже чем у обычных людей? Что можно потюнить? Стоит ли добалять оперативы/ядра (менять тип инстанса)?

Смотреть в первую очередь queries статистику, может надо ключей накинуть

Смотреть в первую очередь queries статистику, может надо ключей накинуть

Там достаточно индексов - буду добавлять больше - просядет врайт операции

Там достаточно индексов - буду добавлять больше - просядет врайт операции

А размер базы какой?

А размер базы какой?

6 Гб. Там есть одна жирная коллекция на несколько гигов, с геоданными

вообще варианта 2: - сидеть разбираться что тормозит и тюнить - платить деньгами увеличивая конфиг и надеясь что угадал

вообще варианта 2: - сидеть разбираться что тормозит и тюнить - платить деньгами увеличивая конфиг и надеясь что угадал

ладно, спасибо, буду пробовать

!spam

Второй нюанса по поводу Casual Consistency, который мне не понятен:) Если чтение и запись стоит в majority и w: 1, то почему не обеспечитвается Read own writes?

Если я записываю данные на primary(master) БД, то при чтнеии после записи у меня должны вернутся обновленные данные, разве нет?

https://docs.mongodb.com/manual/core/causal-consistency-read-write-concerns/

Ааа, я кажется понял. Пока выполняется запись на один primary узел, другой, будучи secondary, становится primary (так как предыдущий primary занят). И тут нам могут вернутся не свежие данные. Так?

Ааа, я кажется понял. Пока выполняется запись на один primary узел, другой, будучи secondary, становится primary (так как предыдущий primary занят). И тут нам могут вернутся не свежие данные. Так?

И ещё от readPreferrence зависеть будет

И ещё от readPreferrence зависеть будет

Да, но потом я опять не понял) Я прочел ответ по поводу смены primary узлов здесь https://stackoverflow.com/questions/42615319/the-difference-between-majority-and-linearizable Но не понимаю почему они вообще должны меняется. Операции ведь многопоточны, а автор ответа говорить что "пока одна primary нода занята, другие конкурируют за то, чтобы стать новой primary". Так вот мне не понятно, как это мастер нода может быть занята. У меня предположении только если что то пошло не так и она перестала отвечать в течение какого то времени, тогда согласен, что слейвы борются чтоб стать новым мастером.

Насчёт read preference в режиме secondary понятно, что не обеспечивается causal consistency.

Вы все правильно свели к «между запросами были выборы»

Почему были выборы — не важно

Почему были выборы — не важно

Понял. Благодарю.

Добрый день! С монго до этого не работал, пытаюсь хоть примерно оценить ее применимость для своей задачи. Буду благодарен за соображения / критику.

Вопрос такой: как она работает с большим количеством рандомных изменений документов? Допустим, у меня есть порядка 100M документов, каждый примерно 10kB. Я хочу изменить 100k таких документов, каждое изменение порядка 1kB. На какое время записи можно (очень грубо) расчитывать. Хотя бы порядок. Допустим это при одной железке «подходящего» размера.

это невозможно оценить

даже грубо

ок, возможно достаточно соображений, вообще это "подходящий" для монги сценарий, или совсем противоестественный обычно разные базы имеют разные implications в основе реализации, и исходя из них можно делать очень общие, но прикидки.

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

размер измнеения роли не играет, так как CoW

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

Похожие по форме изменения, но данные для каждого дока свои. Абстрагируясь от предметной области можно представить так: Нужно из общего лога комментариев к постам раз в какое-то время обновлять документы с постами: дописывать комментарии в соответствующий список, обновлять каунтеры.

Соответственно почти 100% изменений увеличивают размер документов.

это не важно, потому что cow

важно какой у вас запрос

если запрос будет по _id или другому уникальному индексу и не будет требовать сканировать ключи — будет быстро

если запрос будет требовать сканировать ключи, или что ещё хуже — документы, быстро не будет