Юрий
collection.findOne( {_id : el.id }
Юрий
в документе только _id и массив из пары элементов.
т.е.
{_id:12345, array:[1,2,3]}
Nick
А почему бы не использовать просто апдейты на базе?
Юрий
при создании коллекции индекс никакой добавлен не был.
он, как я понял, по умолчанию включен на поле _id
Юрий
А почему бы не использовать просто апдейты на базе?
хотел, но как правило, массив array может меняться не польностью, в идеале, числа в массиве надо инкрементировать, но как воспользоваться $inc только к некоторым элементам массива, я так и не понял.
Юрий
нет ли какого то метода, что бы скормить в базу сразу весь массив документов, и что бы база сама определила, что нужно переписать, а что добавить?
типа updateMany([ {_id_1, ..}, {_id_2, ..}, {_id_3, ..} ...{ _id_n, ..}])
insertMany, к сожалению так не работает, но он быстр
Nick
А массив чисел? Чтото не уловил какой критерий у вас для инкремента только отдеььных чисел
yopp
Скрипт вытаскивает все документы из базы?
Юрий
Юрий
такая структура
yopp
Сделай массив из нормальных документов. [{ aid: xxx, c: zzz}]
Юрий
Скрипт вытаскивает все документы из базы?
только те, которые потенциально нужно заменить.
сейчас коллекция на 10лямов. Нужно заапдейтить или создать ещё миллион записей.
в итоге в коллекции может стать 10 100 000 записей.
Т.е. лопатится база с логами, а агрегированный результат пишется в монгу
Юрий
а да, там всё таки не массив. там тоже объект.
yopp
Тогда инкремент на поле apps.<id>
Юрий
Тогда инкремент на поле apps.<id>
а если нужно инкрементировать несколько элементов, то придется делать несколько запросов с inc для одного документа?
yopp
Нет,один запрос с несколькими инкрементами
Nick
db.getCollection('t').update(
{
"_id" : 1
},
{
$inc: {
"apps.123":1,
"apps.322":1
}
},
{
"upsert" : true
}
);
Nick
чтото такое
Юрий
о. спасибо! попробую так.
yopp
Но твоя проблема мне кажется не в этом
yopp
Такое падение производительности маловероятно что вызвано монгой
Юрий
это когда тестирвал на локальной машине с HDD
гет запросы с коллекцией 1млн документов и 9 млн
Юрий
Юрий
то же самое сейчас на сервере с SSD
yopp
Гет запрос?
Юрий
ну на получение
Юрий
да
Юрий
findOne
yopp
А покажи запрос
yopp
И покажи к нему explain(“executionStats”:1)
Юрий
да по сути то он такой
collection.findOne({_id:el.ifa}, function(err, docs) {
if (err){
errors++;
callback([]);
}
else{ ...
для получении миллиона документов, этот самый миллион разбивается на батчи по 10 000 элементов, который запрашиваются одновременно.
когда 10 000 будут получены, стартует очередные 10 000.
yopp
Ээээ
yopp
Мать моя.
yopp
$in для _id
yopp
И туда в условие 10к ацдишников.
yopp
Но я не понимаю логику происходящего. Зачем в память вытаскивать все миллионы по 10к документов?
yopp
Логи в оффлайне обрабатываются?
Nick
он же делал апдейт в приложухе
Юрий
у меня есть пачка логов за сутки. Я их на своей стороне агрегирую. Получаю миллион документов.
этот миллион документов нужно положить в монгу. В процессе складывания, либо создаю новые документы, либо апдейчу некоторые параметры у уже суещстующего документа в apps
извинте за сумбурность
yopp
Это аналитика для аппстора?
Юрий
ага
yopp
Сеть рекламная какая-то небось?
Юрий
Nick
)
yopp
Короч у вас там по ощущению бардак с ингресом данных
yopp
Но всё поправимо. 120€/час, контракт, вся петрушка. Сделаем пиздатую аналитику на монге.
Юрий
а есть бесплатный чат?)
tenni
кто-то за тебя работать будет? =)
yopp
Чят то бесплатный. Но твоя проблема не в монге
Юрий
а в чем? передача данных? скрипт?
yopp
Скорее всего в логике где-то
yopp
Как я выше написал, вместо 10к вызовов findOne следует попробовать заменить на $in
yopp
Но я вообще не вижу смысла читать документы.
Юрий
да, обязательно, спасибо)
yopp
Апдейта с апсертом должно хватать.
Юрий
пойду читать маны, спасибо большое!
yopp
Я прост сразу вижу следующую твою проблему. Как искать по айдишнику приложения. ;)
Юрий
db.getCollection('t').update(
{
"_id" : 1
},
{
$inc: {
"apps.123":1,
"apps.322":1
}
},
{
"upsert" : true
}
);
кажется всё получилось по этому методу.
чуть позже проверю быстродействие. Спасибо большое!
Nick
Причем в инкремент там можно не только единицу передавать, ну эт на всякий случай
Oleg
Ребят, есть аппка юзающая монгу
Oleg
создана определнная роль и бд для этой аппки
Oleg
на каком уровне логирования будет в логах видно аутентификация под этой ролью ?
Oleg
на сколько понимаб за это ответчает systemLog.component.accessControl.verbosity
Oleg
но нигде не могу найти что на каждом уровне будет логироватся
yopp
но нигде не могу найти что на каждом уровне будет логироватся
https://docs.mongodb.com/manual/reference/log-messages/
Nick
https://docs.mongodb.com/manual/reference/log-messages/
вот например systemLog.component.accessControl.verbosity у него расписано
The verbosity level can range from 0 to 5:
0 is the MongoDB’s default log verbosity level, to include Informational messages.
1 to 5 increases the verbosity level to include Debug messages.
Т.е. поулчается неважно выставлять 1 или 2 или 5, просто тупо будут дебаг сообщения? Или же все-таки будет больше информации выводитсья при level 5?
yopp
будет больше сообщений
yopp
в сообщении будет одно и тоже
yopp
ну вы чо, это же loglevel, оно же тупое
Nick
собственно как раз и вводит в заблуждение различные уровни, если они все соответвуют одному и тому же DEBUG уровню
yopp
https://github.com/mongodb/mongo/blob/6471618952c8727bc5b06039ed2cf861e1a36436/src/mongo/logger/log_severity.cpp
Nick
if (_severity > 0)
return 'D';
yopp
https://github.com/mongodb/mongo/blob/6471618952c8727bc5b06039ed2cf861e1a36436/src/mongo/logger/log_severity.h#L55
Nick
ну как я и думал
Oleg
@dd_bb а не знаешь оно логирует что кто-оибо аутентифицировался под креденшилами?
Oleg
если увеличить логлевел
yopp
да, но я не помню чтоб оно кроме логина что-то ещё писало
yopp
причём там всё херово в любом случае