Anatoly
db.collection.aggregate([
{
"$match": {
$or: [
{
questionId: 1,
answerIndex: 1
},
{
questionId: 2,
answerIndex: 0
}
]
}
},
{
$group: {
_id: {
userId: "$userId"
},
count: {
$sum: 1
}
}
}
])
Anatoly
👌
Tonylook
Nemo
Nemo
при historyPay = historyPay.map((elem) => {
return `${elem.money}р Дата ${elem.created_at}`
})
Vladimir
Dr
https://docs.mongodb.com/manual/reference/operator/aggregation/dateToString/
Nemo
https://docs.mongodb.com/manual/reference/operator/aggregation/dateToString/
стремено выглядит. менять весь запрос надо? заместь простого финда с лимитом мне переписовать все в агрегейт?))
Denis
стремено выглядит. менять весь запрос надо? заместь простого финда с лимитом мне переписовать все в агрегейт?))
Или aggregate или кодом меняй формат даты. В чем сложность то
Dr
Согласен, выглядит не лучшим вариантом, но увы, вот так.
Обычно кодом проще всего.
Nemo
Согласен, выглядит не лучшим вариантом, но увы, вот так.
Обычно кодом проще всего.
Dr
"fomatted" 😉
Nemo
Или aggregate или кодом меняй формат даты. В чем сложность то
зачем городить велосипед. если определенно уже есть готовые заготовки - определенно. ибо это стандартная задача
Nemo
Nemo
типа сорт по айди)
Dr
Почему не прокатывает? Должно, покажи запрос
Dr
HistoryScheme.find({user_id: usrId}).sort({"created_at": -1})
Dr
Как-то так
yopp
из которой я хочу перенести документы? нет
в которую я хочу скопировать - добавляются
тогда пагинация по _id, по этому ключу есть индекс и вы можете использовать пагинацию по маркерам:
- получаете последний _id первого батча: last_id = $project: {_id: 1}, $sort : {_id: 1}, $skip: (<batch_size> - 1), $limit: 1
- мержите первый батч c условием: $match: { _id: $gte MinKey, $lte: <last_id>, $sort: {_id: 1}
а дальше в цикле
– получаете последний _id следующего батча: next_id = $project: {_id: 1}, $match: { $gt: <last_id>}, $sort : {_id: 1}, $skip: (<batch_size> - 1), $limit: 1
- мержите батч: $match: { _id: $gt: <last_id>, $lte: <next_id>, $sort: {_id: 1}
- last_id = next_id
yopp
а, aggregate в covered query так и не научился
Viktar
Подскажите, монга умеет использовать несколько индексов в запросах?
yopp
тогда через find: find({}, {_id: 1}).sort({_id: 1})
Viktar
У меня как не кручу, всегда один в плане фигурирует
yopp
Подскажите, монга умеет использовать несколько индексов в запросах?
в пересечение умеет, но планировщик запросов может решить его не использовать
yopp
пересечение индексов в целом не очень эффективная операция, если пересекаются большие множества. планировщик в оценке размеров множеств консервативаен
yopp
в таких случая compound index более эффективное решение
yopp
вы можете ещё попробовать сбросить кеш планов и сделать hint планировщику на эти индексы
yopp
но если заранее известно что множества большие, то compound
Viktar
Множества большие. У меня саамаая большая проблема с местом. База большая и индексы тоже большие. Вот приходится изголяться.
Cosmic Ranger
приветствую
я сделал одно из полей
someid: {
ref: “someCollection”,
type: mongoose.ObjectId,
required: true,
},
потом делаю из него populate в нужных случаях
но теперь не могу по нему делать find, что делать?
no
https://docs.mongodb.com/manual/reference/operator/aggregation/dateToString/
Интересно!) Спасибо за ответ))
Cosmic Ranger
наверное потому что это теперь не текст, а реф
Cosmic Ranger
но я его не превращаю populateом в объект, так что это просто айди и искать по нему кажется должна быть возможность
no
Cosmic Ranger
как по обычному полю find({someid: ‘’}). если не делать поле рефом, то ищет нормально
Cosmic Ranger
неужели нужно делать ещё одно поле чисто для текста, а это будет типа ссылкой
Anatoly
как по обычному полю find({someid: ‘’}). если не делать поле рефом, то ищет нормально
import { ObjectId } from 'mongodb' { someId: new ObjectId(stringId) }
Cosmic Ranger
я использовал Schema.Types.ObjectId(id) и это не работало
Daniil
наверное потому что это теперь не текст, а реф
тип у поля не изменился. Не мешайте функциональности mongoose с самой монгой
Антон
тогда через find: find({}, {_id: 1}).sort({_id: 1})
Я пробовал сортировать. Но у меня id не objectId, а кастомный айди. И в итоге почему-то перенеслось только 4к записей
yopp
а не важно какой тип у _id
Антон
тогда пагинация по _id, по этому ключу есть индекс и вы можете использовать пагинацию по маркерам:
- получаете последний _id первого батча: last_id = $project: {_id: 1}, $sort : {_id: 1}, $skip: (<batch_size> - 1), $limit: 1
- мержите первый батч c условием: $match: { _id: $gte MinKey, $lte: <last_id>, $sort: {_id: 1}
а дальше в цикле
– получаете последний _id следующего батча: next_id = $project: {_id: 1}, $match: { $gt: <last_id>}, $sort : {_id: 1}, $skip: (<batch_size> - 1), $limit: 1
- мержите батч: $match: { _id: $gt: <last_id>, $lte: <next_id>, $sort: {_id: 1}
- last_id = next_id
Скип не могу использовать, потому что тогда запросы очень медленно выполняются
https://stackoverflow.com/a/50267128
yopp
yopp
это итерация по _id
yopp
это _очень_ быстро
yopp
потому что план запроса: найти $gt, идти по дереву в натуральном порядке до $lte
yopp
или до $limit
yopp
весь смысл в том, что вы указываете с какого _id начинать отсчёт, а значит вам когда вы делает $skip не нужно проходить по n=skip ключам индекса, при условии что $skip с каждым запросом увеличивается
yopp
при условии что у вас коллекция стабильная или есть гарантия того, что _id возрастающий, это очень быстры способ пагинации
Антон
yopp
в принципе, наверное что-то можно сколхозить чтоб дальше $skip не делать, но там covered query и это супербыстро
yopp
(covered query, когда ответ на запрос использует только индекс и не делает fetch из коллекции)
Антон
при условии что у вас коллекция стабильная или есть гарантия того, что _id возрастающий, это очень быстры способ пагинации
А что значит стабильная?
_id у нас генерится на основе нескольких полей. Примерно такие: 004625263-1000-23-WP-1,
А может быть и такой
002517473-1000--AG-2
yopp
к тому что в неё ничего не записывается и не удаляется, а если записывается то _id новых документов больше чем _id старых
yopp
с удаляются в принципе можно жить
Антон
Понял, спасибо большое
yopp
👍
Ilshat
@dd_bb спамер спамит (Martha)
Cosmic Ranger
тип у поля не изменился. Не мешайте функциональности mongoose с самой монгой
тогда почему не делается find по этому полю
Ilyas
Всем привет. Можете подсказать, имеет ли смысл создавать индекс для boolean типа? Я просто нуб в database
Viktar
Всем привет. Можете подсказать, имеет ли смысл создавать индекс для boolean типа? Я просто нуб в database
Добрый. Если он вам необходим, то имеет. Дайте больше информации и получите более развернутый ответ
Ilyas
Добрый. Если он вам необходим, то имеет. Дайте больше информации и получите более развернутый ответ
Спасибо за ответ. Есть коллекция где есть 1 млн документ.
У каждого документа есть свойства: name, age, isActive.
Я, к примеру, хочу вывести все документы где isActive === true.
(Конечно по кусочкам)
Viktar
В таком случае имеет
Гена
Гена
Подскажите что не так делаю
Гена
вот так вот работает
mongo "mongodb://admin:admin@mngdb01:11100/?authSource=admin" --tls --tlsCertificateKeyFile=/ssl/mongodb.pem --tlsCAFile /ssl/ca.pem
Гена
Гена
&tlsCAFile=%2Fssl%2Fca.pem&tlsCertificateKeyFile=%2Fssl%2Fmongodb.pem
Dr
Одинарные кавычки используйте
Dr
И ещё CAfile обычно плохая привычка передавать, монго умеет из системного ca-bundle брать
Гена
И ещё CAfile обычно плохая привычка передавать, монго умеет из системного ca-bundle брать
я с баша захожу, так нет такого
Гена
может надо что то экранировать ? путь к сертам?
Dr
А добавьте ещё --verbose
Гена
А добавьте ещё --verbose
вот так
mongo "mongodb://admin:admin@mngdb01:11100/?authSource=admin&ssl=true&tlsCertificateKeyFile=/ssl/client-all.pem&tlsCAFile=/ssl/ca.pem --verbose" ?