чет нагуглить не могу

Коллеги подскажите, о чем говорит эта запись [WT OplogTruncaterThread: local.oplog.rs] WiredTiger record store oplog truncation finished in

Технический вывод, информация о времени очистки выпавших из границ capped коллекции записей. А в чем проблема?

Просто встречаю в логах иногда) Просто не нашел нигде пояснения спасибо

всем привет

сможет ли кто-нибудь помочь мне поставить аутентификацию на базу?

@dd_bb

гайз, а кто нибудь знает какие нибудь фокусы чтобы bulk updates ускорить на блинах? щас получается размер батча линейно влияет на лейтенси ну и в целом лейтенси хочется чуть поменьше балк на 150 записей 50мс, на 2000 - 800мс у кого нить был опыт?

bulk-операции это просто упаковка n-го количества операций в один «пакет», в базе они применяются последовательно, как обычные update’ы Самое просто, что можно порекомендовать - перезанять на NVMe SSD. Не так дорого стоит

Ну про железо понятно,это дальше будеть

То есть даже перестройки инднкса идут не батчем?

еще такой вопрос, что с lmt индексами в монге? в wiredtiger есть, но че то я так понял в монге все еще B-tree :/

для _id даже включить нельзя вроде

гайз, а кто нибудь знает какие нибудь фокусы чтобы bulk updates ускорить на блинах? щас получается размер батча линейно влияет на лейтенси ну и в целом лейтенси хочется чуть поменьше балк на 150 записей 50мс, на 2000 - 800мс у кого нить был опыт?

Изменить схему таким образом, чтоб обновлять меньше документов

еще такой вопрос, что с lmt индексами в монге? в wiredtiger есть, но че то я так понял в монге все еще B-tree :/

Я сомневаюсь что структура организации индекса будет иметь хоть какой-то статистически значимый эффект

еще меньше обновлять не получится к сожалению

по каким критериям происходит выборка для обновлений?

Но в целом, 2.5к операций в секунду на hdd это неплохой результат

это CDC из мастер системы. выборка 1) по id 2) по id в массиве(1% обновлений)

да, результат вполне ок. 2.5-5к просто хотел понять можно ли как-то потюнить чтобы не был линейный рост лейтенси при увеличении размера батча. если батч делать не 150 а 2к то трупут до 8к доходит, но лейтенси 800мс не подходят

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

97% что эти задержки это дисковая система

если у вас не очень важные обновления можно делать их мимо журнала

Возможно это уменьшит задержки, но не уверен

в вайртайгер нельзя уже отключить журнал

Вы можете отключить его в запросе

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

Тогда ack операции вам придёт без ожидания журналирования

Но в целом, я бы не пытался это крутить

Шарды сомневаюсь что дадут какой-то ощутимый прирост

почему?

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

NVME

И памяти побольше

память под диск кэш имеете ввиду?

А у вас сколько данных?

вайтайгера кэш на 1/3 занят. есть что-то что еще в монге по памяти мониторить?

ну то что щас гоняется 1кк записей, в бою 150кк будет

запись в районе 1-3кб наверное

гайз, а кто нибудь знает какие нибудь фокусы чтобы bulk updates ускорить на блинах? щас получается размер батча линейно влияет на лейтенси ну и в целом лейтенси хочется чуть поменьше балк на 150 записей 50мс, на 2000 - 800мс у кого нить был опыт?

Можно только ordered: false попробовать, но свои приколюхи. А как вы меряете летенси? И почему балк а не просто обычные запросы?

ordered false и так, он чуть шустрее вроде чем true но тоже погрешность лейтенси - System.nano; execute; system.nano и перцентиль в прометеус:)

батчи потому что из кафки батч пришел - в монгу батч обработал - закинул.

ordered false и так, он чуть шустрее вроде чем true но тоже погрешность лейтенси - System.nano; execute; system.nano и перцентиль в прометеус:)

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

обе метрики

ну и показывает что основное время execute занимает

Т.е. Ожидание запроса

В это время монга упирается в диски/цпу/сеть?

ну упирается никуда, но кажется что лейтенси диск дает. по графикам iotime до 300мс 2k iops на запись между прочим;)

ну упирается никуда, но кажется что лейтенси диск дает. по графикам iotime до 300мс 2k iops на запись между прочим;)

Хдд? Рейд? Сколько дисков?

рейд1, хдд, 1 массив 2 диска

не спрашивайте почему так:)

А, можно успокоиться, больше сложно получить

вот такая картинка

ну в целом 2к iops на хдд это прям норм так, так что да

Там расчетная норма 150-200 на обычный диск

это рандомные если записи

последовательная 10-20к вполне ок

я поэтому тож на батчи расчитывал:)

хм, не 2к, 1к, в проме запрос кривой был:) но все равно норм, ладно, всем спс

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

а монга балк по шардам не раскидает через роутер?

Раскидывает, но время ожидания сбора результата со всех шардов - доп латенси

ну сеть обычно такую не дает как hdd)

ну ладно, это уже если ssd не дадут профита нужного

ну ладно, это уже если ssd не дадут профита нужного

mongos can attempt to send the writes to multiple shards simultaneously.

https://docs.mongodb.com/manual/core/bulk-write-operations/#strategies-for-bulk-inserts-to-a-sharded-collection

короч это уже будущее, потом просто вернетесь к этому вопросу если потребуется

да, спс

Доброго времени суток! Скорее всего мой вопрос глупый, только начал использовать mongodb, но возникла ситуация, в которой не могу придумать запрос который возвращал бы 1) результат агрегации 2) количество элементов ДО применения skip и limit db.bets.aggregate([ { $match: { 'user.id': id } }, { $lookup: { from: 'lots', let: { lotId: '$lotId' }, pipeline: [{ $match: { $expr: { $and: [ { $eq: ['$_id', '$$lotId'] }, { $gte: ['$willFinish', now] } ] } } }], as: 'lot' } }, // { // $count: 'COUNT' - возвращает верно, но результат агрегации не выводится // }, { $skip: (page - 1) * limit }, { $limit: limit }, { $unwind: '$lot' } ])

можете подсказать в какую сторону смотреть?

думал можно как-то сначала запомнить результат агрегации, а затем вывести его в два поля, где одно это count, а второе это уже сам результат, через некий $facet возможно

не хотелось бы в два запроса выполнять

не хотелось бы в два запроса выполнять

почему?

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

делайте два запроса

то есть он выполнит оптимизацию? или нет другого способа?

на какую оптимизацию вы расчитываете?

{ $match: { 'user.id': id } }, { $lookup: { from: 'lots', let: { lotId: '$lotId' }, pipeline: [{ $match: { $expr: { $and: [ { $eq: ['$_id', '$$lotId'] }, { $gte: ['$willFinish', now] } ] } } }], as: 'lot' } }, что вот эта часть не будет выполняться дважды

{ $match: { 'user.id': id } }, { $lookup: { from: 'lots', let: { lotId: '$lotId' }, pipeline: [{ $match: { $expr: { $and: [ { $eq: ['$_id', '$$lotId'] }, { $gte: ['$willFinish', now] } ] } } }], as: 'lot' } }, что вот эта часть не будет выполняться дважды

вам нужно делать два разных запроса

окей, благодарю

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