Anonymous
Вот я проебался, потому что до этого не смотрел, какой индекс используется.
Anonymous
А сейчас это как гадание на кофейной гуще, потому что зафорсить индекс нельзя на агрегацию.
Anonymous
Приходится исхищряться.
Anonymous
Если у меня есть записи пользователей и timestamp, то лучше использовать timestamp первым?
Anonymous
Т.е. я хочу получить записи определённых пользователей по timestamp'у выше, чем я задаю.
Anonymous
Поэтому у меня два индекса -1, т.к. кроме timestamp'a чаще пишут новые пользователи. Они все в начале по сортировке.
Anonymous
Ну я пытаюсь получить все сообщения определённых пользователей за последние X дней.
Anonymous
Следовательно есть $in на пользователей и $gte на timestamp.
Anonymous
При этом я знаю, что чаще всего в эту выборку попадают пользователи с большим ID.
Anonymous
И все данные (timestamp) лежат "в хвосте" (последние).
Anonymous
Т.е. я не запрашиваю данные за прошлый год, мне нужные последние X дней.
Anonymous
Вот я сейчас сделал id, timestamp и timestamp, id. С timestamp, id результаты хуже, чем с id, timestamp.
yopp
Есть ли какое-то логическое объяснение этому кроме странностей агрегаций?
Порядок сортировки не указан
yopp
Почитай про составные индексы и сортировку. В доке кажется есть ответ на твой вопрос.
yopp
Плюс тренируйся на find, match stage в 99% работает идентично
yopp
Если мне память не изменяет планировщик такие вещи уже давно оптимизирует сам
Bruno
интересно откуда :)
Михаил Макарычев
отсюда
http://netology.ru/blog/prg-tg?utm_source=forwebdev&utm_medium=announcement&utm_campaign=bolshaya-kollektsiya-iz-133-kanalov-i-chatov&stop=1
Serg
привет
Serg
как только не используем, но по большей части как вспомогательный инструмент. Я пилю всякую аналитику, макеты рабочие делаю и т.д. Сертификаты кто получал их?
Serg
я курсы DBA и Node.js + монга на 100% закрыл, но чет как-то забил на сертификацию
Yuliia
привет, я ноду учу, но пока не использую в коммерческих проектах, монгу тоже использую в обучении
Serg
ну зависит от задачи, где-то и find достаточно, а где-то и с map-reduce затыкается все
Serg
коллекцию вертеть с 7млн документов - то еще удовольствие
Serg
монга больше для малых и средних объемов данных подходит, для больших объемов нужно оперативки столько, чтоб вся база в ней помещалась иначе сильное падение производительности
Serg
мск
Anonymous
Нет?
Anonymous
Anonymous
На одном сервере ещё, даже без кластера.
Anonymous
Эх, а ведь скоро нужно будет шарды делать.
Anonymous
Всё никак руки не дойдут.
Anonymous
Я думаю, основные проблемы начинаются как раз на этом этапе.
Serg
скажем задача создать доп поле для каждого документа на основании нескольких полей текущего, выжирает очень много оперативки, вплоть до аут оф мемори
Anonymous
А как ты это делаешь?..
Anonymous
Это же очень простая операция.
Andrey Ponomarenko
в течение месяца начну впервые знакомиться с БД и mongodb в частности, надеюсь тут не будут сильно карать меня за нуб вопросы)
Anonymous
Может быть ты ищешь не по индексу? Тогда полноценное сканирование коллекции может хорошо повесить процессор.
Anonymous
Да и диск вместе с ним иногда.
Alex
а зачем искать по индексу, если нужно обойти все документы?
Serg
var col = "transactions_original";
var bulk = db.getCollection(col).initializeUnorderedBulkOp();
var i = 0;
var pipe = [{$match: {}}];
db.getCollection(col)
.aggregate(pipe, {allowDiskUse: true})
.forEach(function(item) {
var a = item.tr_datetime
.split(" ")[1]
.split(":");
var seconds = (+a[0]) * 60 * 60 + (+a[1]) * 60 + (+a[2]);
bulk.find({ "_id" : item._id })
.updateOne(
{ $push: {
"train_set.input" : {
$each: [
item.customer_id/1000000000,
item.tr_datetime.split(" ")[0]/1000,
seconds/100000,
item.mcc_code/10000,
item.tr_type/10000,
(item.amount+145984525.17)/300000000
]
}
}
}
);
});
bulk.execute();
Anonymous
var col = "transactions_original";
var bulk = db.getCollection(col).initializeUnorderedBulkOp();
var i = 0;
var pipe = [{$match: {}}];
db.getCollection(col)
.aggregate(pipe, {allowDiskUse: true})
.forEach(function(item) {
var a = item.tr_datetime
.split(" ")[1]
.split(":");
var seconds = (+a[0]) * 60 * 60 + (+a[1]) * 60 + (+a[2]);
bulk.find({ "_id" : item._id })
.updateOne(
{ $push: {
"train_set.input" : {
$each: [
item.customer_id/1000000000,
item.tr_datetime.split(" ")[0]/1000,
seconds/100000,
item.mcc_code/10000,
item.tr_type/10000,
(item.amount+145984525.17)/300000000
]
}
}
}
);
});
bulk.execute();
Тут проблема не базы данных, а архитектуры приложения и запросов, разве нет?
Alex
Я думаю, основные проблемы начинаются как раз на этом этапе.
Вы же помните, что каждая шарда должна быть репликасетом? :)
Denis
У нас на старой работе монга была как хранилище raw transaction для rtb / ssp /dsp
Anonymous
Вы же помните, что каждая шарда должна быть репликасетом? :)
Да, но я планировал первый кластер без реплики делать.
Anonymous
Или это ошибка?
Anonymous
Я разворачивал без реплики на локалках, вроде всё норм.
Denis
на новой, мы храним в монге все данные DRM в максимально денормализованном виде.
Alex
монго не рекомендует... а как бэкапить, например?
Anonymous
монго не рекомендует... а как бэкапить, например?
Хороший point. На данном этапе, я боюсь, ресов не хватит на всё. Хотя время ещё есть, может быть к тому моменту серверов будет больше.
Anonymous
Сейчас-то бэкапится очень просто, понятное дело. Single instance.
Alex
Да тоже не всегда просто, когда база 700гигов.
Anonymous
var col = "transactions_original";
var bulk = db.getCollection(col).initializeUnorderedBulkOp();
var i = 0;
var pipe = [{$match: {}}];
db.getCollection(col)
.aggregate(pipe, {allowDiskUse: true})
.forEach(function(item) {
var a = item.tr_datetime
.split(" ")[1]
.split(":");
var seconds = (+a[0]) * 60 * 60 + (+a[1]) * 60 + (+a[2]);
bulk.find({ "_id" : item._id })
.updateOne(
{ $push: {
"train_set.input" : {
$each: [
item.customer_id/1000000000,
item.tr_datetime.split(" ")[0]/1000,
seconds/100000,
item.mcc_code/10000,
item.tr_type/10000,
(item.amount+145984525.17)/300000000
]
}
}
}
);
});
bulk.execute();
Так я не понял, почему просто не обновить все поля в базе? db.collection.update() и $set?
Anonymous
Да тоже не всегда просто, когда база 700гигов.
Кстати, я уже спрашивал, но когда-то давно - а что делать, если на реплике заканчивается место?
Alex
Кстати, я уже спрашивал, но когда-то давно - а что делать, если на реплике заканчивается место?
а какие варианты? или расширять место или выносить данные :)
Anonymous
Вот, а куда их можно "вынести"? Можно подробнее?
Anonymous
Добавить места - это понятно. Но и там до разумных пределов.
Alex
Вот, а куда их можно "вынести"? Можно подробнее?
Ну. Мы выносили по коллекциям на другие сервера с монгой. Не шардинг, а прямо отдельный инстанс. Ну и самописный шайтан- демон , который знает где какие данные лежат. Но это шаманство. 😎
Serg
это прям хз
Alex
Вертикально расширяться никак
Alex
в сервере нет места под диски
Alex
А монговский шардинг больно дохрена дорогой выходит
Anonymous
Я вот думал, если бы можно было рекурсивно шардить реплики создавая им маленькие кластеры со своими репликами?
Anonymous
Это конечно бред.
Alex
Реккрсивно шардить?🤔
Anonymous
Но меня вот очень волнует, например, что делать с базой (точнее с репликой), которая не влезает на сервер.
Anonymous
Предположим, что места больше уже не докинуть.
Anonymous
А реплики?
Serg
что значит дорогой
Anonymous
Можно чуть-чуть подробнее для самых глупых?
Alex
ага, это если у тебя бюджет минобороны
Anonymous
Я просто реально вот этот момент не понимаю.
Serg
там же в комьюнити версии полноценный шардинг
Alex
дорогой - значит, что каждый шард это репликасет это минимум 2 сервера
Anonymous
А 3 конфиг-сервера?..
Alex
эээ
Anonymous
Но минимально рекомендуется три, если я не ошибаюсь...
Alex
Можно больше , да :))
Anonymous
Так а не закончится место на реплике?