Любая аутентификация ничего не гарантирует, кроме того что кто-то владеет подходящим секретом.

С билингом самым сложным был флоу процессинга (нелинейность и асинхронность) и создание подписок по итогам успешной оплаты.

https://jira.mongodb.org/browse/SERVER-30811 ну вдруг..

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

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

интересный кейс про биллинг, нет случайно блога с примерами?)

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

У нас в проекте возникали проблемы с dirty read, при редактирование нескольких зависимых документов с нескольких нод

У нас в проекте возникали проблемы с dirty read, при редактирование нескольких зависимых документов с нескольких нод

Это слишком абстрактное описание проблемы.

интересный кейс про биллинг, нет случайно блога с примерами?)

Не-а. Надо уже завести, но пока времени нет.

это все прикольно пока подписок ограниченное количество

а если мильены ?

а если мильены ?

Да хоть миллиарды

Не-а. Надо уже завести, но пока времени нет.

на самом деле я уже пользовал addToSet и обыгрывал ситуацию вокруг атомарности апдейта одного документа, но про write concern'ы я бы почитал

особенно про использование на кластере

конечное время обработки так или иначе есть для каких то объемов

конечное время обработки так или иначе есть для каких то объемов

Эээ.

закон Амдала же

не ?

или он не работает от слова совсем ?

Я тебя не понимаю сейчас совсем :)

ну ты упрешься либо в пропускную способность канала либо дисков либо CPU

Шардить никто не мешает

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

По ацдишникам профиля шардится изумительно

не мешает конечно

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

ну и там по цепочке

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

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

Эээ. Да.

В любой информационной системе.

yep

И?

Я не очень понимаю что ты хочешь этим сказать

успокойсо

все ок

Мы можем деражать время обработки в каком-то разумном пределе, лимитируя объём информации. Шардинг отлично решает эту задачу, подписки статистически активируются последовательно в течении конечного временного периода (у нас 4 недели было). Остальные в 90% случаев уже не активируются никогда. На «горячей» зоне живут подписки за последние 8 недель. Ёмкий ключ позволяет хорошо масштабироваться в ширину, в том числе и на запись.

Автозамену в последней бете окончательно доломали. Роботы бунтуют

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

реляционность во мне требует отдельную коллекцию 🙂

А сколько устройств в группе?

От одного до 10000

Есть 2 разные модели, которые лежат в одной коллекции. Как получить всю коллекцию? Обычно я получаю [modelName].find(), но тут так не получится.

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

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

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

я бы тоже почитал

а то пока больше по интуиции

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

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

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

это я понимаю, просто не хочется бежать за кем-то по граблям

что вы таки понимаете под термином “глубина вызовов” ???

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

и так миллион раз ?

или миллион микросервисов 7

как сделаешь

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

даже у гугла

не говоря про более рядовые компании

зайди в акронис, в разработку 🙂

и что там ? :)

там узнаешь много нового

как то такого желания раньше не возникало =)

Не работает, фиксабельно?

Как получить записи из базы данных за определённый период?

ты имеешь в виду, что у тебя есть поле с датой и нужно отфильтровать документы по этому полю?

ты имеешь в виду, что у тебя есть поле с датой и нужно отфильтровать документы по этому полю?

Да

$gte и $lt

Покажешь на примере?

items.find({ created_at: { $gte: ISODate("2010-04-29T00:00:00.000Z"), $lt: ISODate("2010-05-01T00:00:00.000Z") } })

=)

https://stackoverflow.com/questions/2943222/find-objects-between-two-dates-mongodb

Спасибо

ISODate is not defined

ты на ноде чтоль пишешь?

Ну да

new Date('2014-01-22T14:56:59.301Z')

Окей

Спасибо, заработало

привет все. а расскажите про oplog. размера по дефолту 50gb уже мало и время между репликами хотелось бы увеличить. Какие плюсы минусы, подводные камни? oplog Живет в оперативной памяти? будет вытеснять индексы? или можно увеличивать сколько влезет?

Это capped коллекция, не помню чтоб у неё принципиально отличалось поведение от других. Если нужно увеличить — увеличивай. Можно попробовать увеличить только на отдельной скрытой ноде, но я не помню могут ли остальные участники читать оплог со скрытых нод. Но это просто проверятся на тестовом столе.