Oleg
db.getCollection('payments').aggregate([
{
"$match": {status: 'paid'}
},
{
"$group": {
"_id": null,
"total": {"$sum": ["$amount", "$credentials.WMI_COMMISSION_AMOUNT"]}
}
}
])
Как вывести общую сумму оплат с вычетом комиссии, которая находится в credentials.WMI_COMMISSION_AMOUNT?
При таком запросе ошибка:
Error:
Assert: command failed: {
"ok" : 0,
"errmsg" : "aggregating group operators are unary ($sum)",
"code" : 15953
} : aggregate failed
AstraSerg
db.getCollection('payments').aggregate([
{
"$match": {status: 'paid'}
},
{
"$group": {
"_id": null,
"total": {"$sum": ["$amount", "$credentials.WMI_COMMISSION_AMOUNT"]}
}
}
])
Как вывести общую сумму оплат с вычетом комиссии, которая находится в credentials.WMI_COMMISSION_AMOUNT?
При таком запросе ошибка:
Error:
Assert: command failed: {
"ok" : 0,
"errmsg" : "aggregating group operators are unary ($sum)",
"code" : 15953
} : aggregate failed
$sum со списком возможно только на стейдже project https://docs.mongodb.com/manual/reference/operator/aggregation/sum/#definition
yopp
Всем привет.
У кого-нибудь есть опыт использования в проде mongo cloud?
Интересует скорость переезда с одной подписки на другую, например с M3 -> M4 и обратно M4 -> M3.
Динамическое добавление/удаление нод в разных регионах.
Речь только про replica set, шард кластер не рассматривается.
репликасет по одной ноде rolling upgrade делает
yopp
сколько займёт зависит от облачного провайдера
yopp
оно тушит текущую ноду, отцепляет блочное устройство, делает провиженинг новой ноды с этим блочным устройством
yopp
и потом ждёт пока нода догонит кластер
yopp
про добавление нод не знаю, не приходилось использовать. в зависимости от того как они будут ноды бутстрапить, будет зависеть скорость. скорее всего они просто поднимают пустую ноду, а значит это займёт ровно столько, сколько занимает initial sync. если они снепшот блочного устройства подсосывают, то наверное столько, сколько нужно на копию снепшота + догнать кластер. но я чот сомневаюсь что они по второму сценарию идут
rdcm
и потом ждёт пока нода догонит кластер
А если новая нода не догоняет кластер и оплог успевает ротироваться, как быть?
rdcm
Планируется активная запись
yopp
шардировать
yopp
увеличивать read capacity
Oleg
$sum со списком возможно только на стейдже project https://docs.mongodb.com/manual/reference/operator/aggregation/sum/#definition
А как это должно выглядеть в итоге?
yopp
больше вариантов нет
yopp
ещё конечно можно размер оплога увеличить, но маловероятно что это поможет
AstraSerg
А как это должно выглядеть в итоге?
Сделайте груп с суммированием, а потм добавьте ещё одни стейдж projectи в нем уже сумму по полям
rdcm
Можно сказать уже есть, реализовано в приложении
Пользователей обещают нагнать, максимальная нагрузка скорее всего будет на несколько недель максимум (пальцем в небо)
rdcm
Но не думаю что сильно ошибся
yopp
это в гигабайтах оплога в час сколько?
yopp
это легко достаточно подсчитать
yopp
если целевая нагрузка известна
rdcm
Пока затрудняюсь ответить, статистические данные отсутствуют
Должно работать при ~2500 одновременных пользователей
yopp
2500 одновременных пользователей сколько операций в минуту совершают?
rdcm
1000 rps, 80% select 20% insert
yopp
но вобщем даже если они будут по операции в секунду совершать, а каждая операция по килобайту, это 2.3 мегабайта в секунду или 8 гигабайт в час.
rdcm
Нашел последние цифры
yopp
1000 рпс на 2500 пользователей?
yopp
достаточно популярная рекламная платформа, которая крутилась на нескольких десятках тысяч сайтов давала 30-80к запросов в минуту, это 500-1400rps
yopp
и там побольше чем 2500 пользователей было
AlphaGammaBeta
утро!
ребят...
я вот тут накосячил..
или не накосячил, ещё не знаю.
в общем, есть база.
каждый документ - это пользователь
пользователь пересылает отчёт, и в документ пользователя заносится строка словаря
вида
"дата1":
{
"4-8 строчек": "вида"
"количество": 5,
"качество": "хорошо",
...
}
и так далее по датам...
строчки однотипные, но много....
можно ли как-то получить только те даты с отчётами, где, например, "качество" только "хорошо"?
до чего я додумался - это получить весь документ и прогнать его for'ом...
но база в облаке, и я лелею надежду, что она может быть когда-нибудь разрастётся до полугига, например))
есть ли ещё варианты?)
yopp
тысяча запросов в секунду это безумно большая нагрузка
yopp
это аудитория в сотни тысяч человек
rdcm
Ну, зависит от приложения
Других данных у меня пока нет
yopp
если вы к такому готовитесь, то я бы предложил начинать с моделирования нагрузки и последующего нагрузочного тестирования
yopp
потому что монга скорее всего будет не самой большой вашей проблемой
Max
тысяча запросов в секунду это безумно большая нагрузка
Как сделать так, чтобы владельцы бизнеса думали так же :)
rdcm
Согласен, нагрузочное тестирование необходимо
Но если вернуться к оплогу.
Допустим 200rps на вставку, как правильно посчитать скорость его заполнения?
yopp
Согласен, нагрузочное тестирование необходимо
Но если вернуться к оплогу.
Допустим 200rps на вставку, как правильно посчитать скорость его заполнения?
взять jmeter, нарисовать сценариев, запустить и посмотреть
AstraSerg
утро!
ребят...
я вот тут накосячил..
или не накосячил, ещё не знаю.
в общем, есть база.
каждый документ - это пользователь
пользователь пересылает отчёт, и в документ пользователя заносится строка словаря
вида
"дата1":
{
"4-8 строчек": "вида"
"количество": 5,
"качество": "хорошо",
...
}
и так далее по датам...
строчки однотипные, но много....
можно ли как-то получить только те даты с отчётами, где, например, "качество" только "хорошо"?
до чего я додумался - это получить весь документ и прогнать его for'ом...
но база в облаке, и я лелею надежду, что она может быть когда-нибудь разрастётся до полугига, например))
есть ли ещё варианты?)
Не расстраивайтесь. Можно получить, да, можно через unwind например https://docs.mongodb.com/manual/reference/operator/aggregation/unwind/
rdcm
взять jmeter, нарисовать сценариев, запустить и посмотреть
Про доступные инструменты я в курсе :)
yopp
оплог нужно не в документах в секунду мерять, а в байтах
AlphaGammaBeta
yopp
да. а потом посмотреть сколько проектов в мире имеют 84 миллиона запросов в день
rdcm
оплог нужно не в документах в секунду мерять, а в байтах
Ок, если поделитесь формулой расчета буду признателен :)
yopp
Ок, если поделитесь формулой расчета буду признателен :)
у вас очень невнятно сформулирована задача
yopp
нарисуйте лоад план, на бумажке
rdcm
да. а потом посмотреть сколько проектов в мире имеют 84 миллиона запросов в день
Речь всё таки не про 24 часовую непрерывную нагрузку в таком объёме, это факт. Скорее речь о нескольких часах в день на протяжении нескольких недель.
yopp
распишите какие у вас есть ресурсы, сколько и каких запросов к ним будет
yopp
и потом по каждому из запросов померяйте размер записи в оплоге
yopp
дальше используйте данные из лоад плана и посчитайте цифры
Max
да. а потом посмотреть сколько проектов в мире имеют 84 миллиона запросов в день
у меня одних инсертов больше
но все равно это все "ерунда, можно из говна и палок собрать, нафига тут кластер?"
Vova
распишите какие у вас есть ресурсы, сколько и каких запросов к ним будет
А есть где-то хорошие статьи где можно почитать про разрешение высоких нагрузок и best practices?
Max
простите, чатик
пригорает
yopp
а у вас там реклама, да?
Max
да
yopp
посчитать сколько стоит один запрос, а потом посчитать стоимость минуты простоя :)
yopp
в необслуженных запросах
yopp
можно красивый суточный график нарисовать
yopp
точнее не стоит, а приносит
yopp
с рекламным трафиком это обычно легко
Max
это логике не поддается
она такая - когда поздравляешь всех с большой цифрой - все говорят, что "большие цифры, к сожалению, это не деньги"
а как только цифры меньше - вазелин сразу отбирают ))
yopp
в смысле? очень даже поддаётся
Max
я выдаю технические цифры
yopp
а ты выдавай цифры с бабками
Max
народ сам это под себя адаптирует
yopp
это всех участников отрезвляет
yopp
capacity кластера в бабках
yopp
текущую утилизацию ёмкости в бабках
yopp
стоимость простоя в бабках
yopp
стоимость запроса в бабках
yopp
да, типа того
yopp
revenue / codb
rdcm
распишите какие у вас есть ресурсы, сколько и каких запросов к ним будет
Попробую прикинуть на днях и посчитать скорость заполнения оплога. Раскидаю пданируемое количество запросов, на количество нод. Сейчас большей информации нет.
Расчетами поделюсь :)
yopp
у вас один тип запросов?
yopp
если нет, то просто число запросов на число нод никакого смысла не имеют
yopp
чем быстрее вы от запросов к байтам перейдёте, тем будет лучше