А у вас индексы в gridfs коллекциях точно есть?
Есть, дефолтный
Проксимов
yopp
всё-же рекомендую проверить что с дисками происходит
yopp
и посмотреть explain в запросах которые ваша gridfs реализация генерирует
yopp
ну и конечно проверить что у вас до монги канала хватает
Artem
CastError: Cast to Number failed for value "{ '$gte': 5 }"
что? это как?
yopp
CastError: Cast to Number failed for value "{ '$gte': 5 }"
что? это как?
как у вас запрос выглядит?
Artem
.find({
field: {
subfield: { $gte: 5 }
}
})
Проксимов
.find({
field: {
subfield: { $gte: 5 }
}
})
Ну я в монге не спец, но кажется в субфилде есть то, что не может быть сравнено с 5
Artem
Ну я в монге не спец, но кажется в субфилде есть то, что не может быть сравнено с 5
subfield: { type: Number }
Собсвтенно поэтому он и приводит весь объект к числу
yopp
.find({
field: {
subfield: { $gte: 5 }
}
})
https://docs.mongodb.com/manual/tutorial/query-embedded-documents/#query-on-nested-field
Artem
https://docs.mongodb.com/manual/tutorial/query-embedded-documents/#query-on-nested-field
Спасибо, все работает. Странно, чего не сделали синтаксиса вроде того что я писал
Nikolai
Ребята, привет! Кейс - есть два дампа в bson, данные частично перекрываются, сделаны под Mongo 3.6. Делаю последовательный рестор в 4.2, рестор первого дампа пролетает относительно быстро, второго, в котором есть дублирующиеся коллекции, делается днями. Данных примерно по 200 GB в каждом дампе. Пробовал на разных конфигах машин на AWS, и жирнее и меньше - ощутимой разницы в скорости рестора практически нет. С чем это может быть связано и есть ли варианты ускорить процесс рестора?
yopp
Спасибо, все работает. Странно, чего не сделали синтаксиса вроде того что я писал
Этот синтаксис имеет другую семантику
yopp
Это совпадение с объектом
Artem
понял
Andrey
И всё?
Andrey
Ну вот они и пкрестраиваются при повторной вставке в коллекцию...видимо...меня поправят дальше
Andrey
Надо было експортить наверно...а не дампить
Nikolai
Ну вот они и пкрестраиваются при повторной вставке в коллекцию...видимо...меня поправят дальше
Насколько я могу судить по первому рестору, индексы строятся после того, как данные залиты в базу, а второй дамп именно заливается долго.
Asdf
Всем привет. А кто-то смог приконнектиться к атласу на пхп?
Andrey
Насколько я могу судить по первому рестору, индексы строятся после того, как данные залиты в базу, а второй дамп именно заливается долго.
Да...залил первую восстановились индексы...льешь вторую - индексы уже есть. По новым данным они перестраиваются
Nikolai
Да...залил первую восстановились индексы...льешь вторую - индексы уже есть. По новым данным они перестраиваются
Именно синхронно, в процессе заливки второй части?
Andrey
Именно синхронно, в процессе заливки второй части?
Я поэтому заливаю такие объемы в базу до конца...а потом когда уже много писать в базу не планирую, строю индексы. Иначе скорость сильно падает записи. Это из практики
Nikolai
Я поэтому заливаю такие объемы в базу до конца...а потом когда уже много писать в базу не планирую, строю индексы. Иначе скорость сильно падает записи. Это из практики
Принял. Если дропнуть индексы, что уже построены, и заресторить вторую часть, после чего построить индексы заново - должно помочь?
Andrey
Принял. Если дропнуть индексы, что уже построены, и заресторить вторую часть, после чего построить индексы заново - должно помочь?
там сейчас может админ скажет - как правильно
Andrey
Но я бы так сделал
Nikolai
Та мне хоть как-нибуть приконнектиться
Не подскажу. Я вчера решал проблему с TLS на Спрингах и новыми cipher в клауде, но вы про другое.
Asdf
С консоли коннектиться к атласу а на пхп коннектиться не хочет
Nikolai
там сейчас может админ скажет - как правильно
ок, спасибо за идею. если если у админа есть возможность заапрувить этот сценарий - буду признателен.
Andrey
я вот никак не могу понять, почему если поле гарантированно Int64 - почему после distinct в результате тип Double
Andrey
в robo3T
yopp
Принял. Если дропнуть индексы, что уже построены, и заресторить вторую часть, после чего построить индексы заново - должно помочь?
в 4.2 если fature compatibility 4.2 выставлено, то индексы создаются в фоне
yopp
возможно вы пытаетесь вставлять данные пока индексы строятся
yopp
попробуйте восстановить оба дампа без индексов, после чего отдельно восстановить индексы
Nikolai
попробуйте восстановить оба дампа без индексов, после чего отдельно восстановить индексы
принял, спасибо. есть какая-то опция, что позволяет пропустить построение индексов, что описаны в дампе?
Nikolai
Nikolai
ну вот. отпиши потом - как повлияло на скорость
добро, попробую. тогда последовательность получается такая, что первый дамп ресторится без индексов с --noIndexRestore, а второй - с ними, после чего индексы строятся по всей коллекции, что получается из обоих дампов.
Andrey
Andrey
ну уже без разницы
Asdf
MDWIT
Всем привет. Может кто-то объяснить почему при сортировке монга игнорирует 2й параметр?
Есть ли способ сортировки с учетом нескольких параметров одновременно?
yopp
Nikolai
Asdf
Спасибо
Anonymous
Nick
Anonymous
Всем привет. Может кто-то объяснить почему при сортировке монга игнорирует 2й параметр?
Есть ли способ сортировки с учетом нескольких параметров одновременно?
присоединяюсь к данному вопросу* Народ, почему по второму параметру не производится сортировка, полное игнорирование происходит, меняешь местами, сортирует по тому что первое стоит, собственно сабж везде замечается, т.е. на разном софте, допустим, если .sort({_id: -1, dateadd: 1}) - не учитывает второй параметр, меняешь местами параметры, сортирует по дате, но _id уже не берет в учет. и так с любыми полями, в разной вариации. в чем прикол? подскажите )
Viktor
Привет
Viktor
{
$lookup: {
from: 'users',
let: {id: '$results.participantId'},
pipeline: [
{$match: { $expr: {$eq: ['$$id', '$_id'] } } },
{$project: {name: 1, email: 1, _id: 1}}
],
as: 'participant'
}
},
Viktor
что я делаю не так?
Viktor
а все так
Viktor
спасибо
Viktor
а не не так
Viktor
если я прописыва as: results.participant
Viktor
то все остальные пропсы в results стираются
Viktor
ну, че молчим то
Viktor
???
Viktor
решать будете уже?
Anonymous
Nick
решать будете уже?
здесь нет тех поддержки, если хотите получить ответ подождите, пока кто-то подскажет
Viktor
лооооол всмысле нет тех поддержки
Viktor
а зачем тогда вообще паблики нужны
Viktor
по разаработке
Viktor
я прохожу на сеньора собес
Viktor
быстрее
Nick
лол
Nikolai
ну вот. отпиши потом - как повлияло на скорость
попробовал с --noIndexRestore, что-то также медленно рестор идет, за 14 минут ресторится порядка 70MB данных.
2021-01-29T14:00:20.043+0000 [........................] databasename.Collection1 84.4MB/49.7GB (0.2%)
2021-01-29T14:00:20.043+0000 [........................] databasename.Collection2 36.8MB/28.7GB (0.1%)
******************
2021-01-29T14:14:05.054+0000 [........................] databasename.Collection1 150MB/49.7GB (0.3%)
2021-01-29T14:14:05.054+0000 [........................] databasename.Collection2 64.0MB/28.7GB (0.2%)
ошибка, что пишется на дублирующиеся записи:
2021-01-29T14:00:20.093+0000 continuing through error: E11000 duplicate key error collection: databasename.Collection1 index: _id_ dup key: { _id: ObjectId('562e5d6a0cf2ce3492bfd49e') }
Viktor
убери
Viktor
так
Viktor
100 рублей заплачу
Viktor
рили