Ребята привет, помогите побороть проблему, не могу понять в чем "прикол". При запросе к БД вида "value"=>'3A002E001657345630373420' ищет запись, а такую "value"=>'31002E000857345630373420' - уже нет - хотя эти записи 100% есть. Руками в Robomongo могу найти, но скриптом, почему-то вторую запись не так воспринимает...

проверьте, используете ли вы find_one вместо find.

нет, 100% не find_one

т.к. запрос динамический и в него приходят переменные из других мест и там результаты долеки от одной строки

покажите запросы которые отправляете

подскажите, если у меня запрос find по двум полям. запрос find({$and: [ {$or: [ {'category': {$in: [16, 17, 18, 19]}}, {'kind': {$in: [21373754,21373763,21373768]}} ] }, {'kind': {$nin: [23,24,25,26]}} ] } ) В ощем случае, то что поле используеться и в $in и потом $nin как-то повлияет на посторение индекса? сейчас создал индекс kind, category.

explain в помощь

И проверьте ещё какое поле даёт большее сужение поиска для следующего условия

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

буду благодарен за подсказки

Как описать в схеме монгуса массив объектов?

explain в помощь

explain показывает "inputStage" : { "stage" : "IXSCAN",

вот и ответили на свой вопрос

на всех трех этапах

Как описать в схеме монгуса массив объектов?

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

покажите запросы которые отправляете

{ 'mfr_step' => 'mfr_needles', 'mcu_id' => '390032001257345630373420' } Вот такой find_query в логе

а есть такой докуент в базе?

да, конечно

они у меня в таблицу на сайте выводятся

я там делаю фильтр

в БД "строка"

а второе поле mfr_needles?

оно всегда одно и тоже (по крайней мере в примерах выше)

только mcu_id меняется

я про значение в документе

короч выполните свой запрос с одним полем mcu_id в монгошелле

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

Никакой. Не надо это делать

В WT будет очень небольшой оверхед.

короч выполните свой запрос с одним полем mcu_id в монгошелле

и что в нем смотреть? Есть ли тот, что не получаю при конкретном mcu_id?

Никакой. Не надо это делать

:( а как же быть тогда? очень больно уже с 500гб на каждом мембере

Единственный способ переложить эффективно данные — все прочитать и потом записать снова.

и что в нем смотреть? Есть ли тот, что не получаю при конкретном mcu_id?

эм, а в чем ваша пробелма тогда?

тоесть накатить новый мембер ?

:( а как же быть тогда? очень больно уже с 500гб на каждом мембере

Не понимаю тогда что ты хочешь

цель - уменьшить количество используемого места под монгу выпилив старые данные

delete батчами

db.getCollection('data').find({'mfr_step': 'mfr_needles', 'mcu_id' : '360033001657345630373420'}).sort({process_time: -1})

выдает ответ

После delete делать ничего не надо, емнип, wt сам отдаст место в хранилище, если сможет.

Если не сможет, то да, добавить временную реплику и в неё все перелить.

А потом initial sync по кругу сделать из неё

выдает ответ

так что за проблема то?

видимо в perl - тогда наверное не тут спрашваю :)

видимо не явно в число преобразует...

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

производство оборудования

точнее процесс тестирования

Клево!

А много данных?

Вы в монгу только результаты QA пишите? Или прямо протоколы тестирования?

я занимаюсь только выводом уже иеющейся инфы :)

Такая ситуация. Есть массив значений поля, по которому нужно извлечь документы. Массив большой, несколько десятков тысяч значений. Оператор $in невероятно долго это выполняет, даже с индексом. Как лучше сделать?

поменять структуру даных

?

вот берете свою основную задачу, и пытаетесь перестроит ьструктуру данных чтобы стало удобно работать и не зависеть от индексов

ну тут даже не в индексах дело. есть коллекция. В ней миллион документов. У документа есть поле offer с уникальным значением для каждого документа. Приходит запрос, в нем массив данных с конкретными значеними поля оффер. Допустим 100 000.

как это эффективно извлечь

$in захлебывается

на такой массив

а вам нужны все 100000 документов?

да, все документы у которых поле offer совпадает со значением в массиве. Грубов говоря, у товара есть уникальный id, есть массив с id этих товарав. Их 100 000, в коллекции миллион. Мне нужны только эти 100 000, которые запросили

ну а дальше что вы делаете с этими 100к доками? сколько из них показываете?

или

то выгрузк в экмели всякие всего подряд?

Все. Извлекаю, формирую из них файл и отдаю обратно.

тогда проще выгружать вообще все и фильтровать на клиенте если данных так много

То есть у монго нет эффективного средства для подобной выборки? Хотел сделать на стороне базы, в принципе и на клиенте можно, но не хотелось лишний раз такие объемы извлекать туда-сюда

его нигде нет

когда выбирается 10% всех данных

причем скорость получения всех данных ориентировочно будет значительно быстрее если использовать натуральный порядок в БД даже против использования индексов

ок, спс

Выгружать миллион и делать на клиенте это тупик все равно. + траффик по сети. Оно минут 20 только выгружаться будет а потом память кончится. Это все равно нужно делать через запрос + paging

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

В общем $in справился, как ни странно. Нашел в коде утечку памяти из-за которой запрос начинла есть, как не всебя оперативку.

плюс добавил по этому же полю еще и $nin

работает

какое у вас получилось время ответа севера? (для статистики)

тестировал на локальной машине, со скромными ресурсами. По коллекции с 800 000 записями сложный запрос find({$and: [ {$or: [ {'category': {$in: [выбирает все 800 000 значений]}}, {'offer': {$in: [сто тысяч значений]}} ] }, {'offer': {$nin: [сорок тысяч значений]}} ] } ) условие categry $in дополнительно выбирает всю коллецию целиком для усложнения нагрузки. тестирую через скрипт, время ответа базы к скрипту менее секунды. Плюс комп сейчас ОЧЕНЬ скромный по ресурсам, прям совсем

ну соотвественно, я не все данные передаю, а только число найденных документов😁

А что мешает предрасчитать массив для offers а не делать дико сложные ин/нин?