но в целом для меня такой запрос выглядит абсурдным, очень широкая выборка в которой индекс вообще не должен примениться изза эвристик. Плюс видно что данных нет подходящих под выборку, т.е. планировщик вообще может что угодно тут соптимизировать лишь бы ничего не делать

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

Ребят ставлю Монгу в кластер, не ставится, говорит что требуется у проца avx cat /proc/cpuinfo | grep avx - говорит что нет его... как быть?

1. В виртуалке включить avx поддержку 2. Поставить старую версию mongo 4.4.6

Я написал в тех поддержку хостинга они почему то говорят что не могут этого сделать

Я написал в тех поддержку хостинга они почему то говорят что не могут этого сделать

неужели кластер из 4 шестиядерных серверов может так так сильно нагружаться всего 3 постоянными потоками запросов?

не, индексы сделал, без индексов падало с дедлайном

тогда дальше уже специфка, что за запросы, как много их

и поток то какой?

в смысле?

это 10 в секунду на воркера. Мониторинг монги что показывает ? во что упираетесь

из гошного драйвера в цикле в 3 потока идут запросы к кластеру из 4 серверов базы

4 реплики

Второе - одинаково. Первое не помню щас.

скорее интерсует наскольок норм будет работать boolean индекс, от этого по сути решение зависит

Вы хамите, но я вам отвечу. Других способы есть, искали ли вы их? Skip limit - самый примитивный способ реализации pagination в лоб. Его использует, когда данных мало, когда вызовов со skip мало, и да он тут работает. Если у вас много skip limit(вы об этом выше писали) - это означает, что у вас или безысходная ситуация, или вы ошибочно составили структуру документа, и не можете итерироваться по документам, кроме как требовать от mongodb делать skip. Явление низкой производительности MongoDB со множеством skip - это давно и часто обсуждалось без привязки к вообще какому-либо языку разработки. Например, вопрос, ответ: https://www.mongodb.com/community/forums/t/what-is-the-fastest-way-to-filter-documents-with-pagination-in-collection-with-millions-of-records/209413/3 "MongoDB" как бы пишет, что по мере увеличения количества skip, ,будет медленно, и что можно придумать: https://www.mongodb.com/docs/manual/reference/method/cursor.skip/#behavior Вторая проблема со skip - может возникнуть с консистентностью данных, если в базу пишут более или менее активно. Может просто не "кидать камни" в разрабов почти единственной библиотекой работы с mongodb, а просто погуглить, то найдутся и вопросы, и ответы. Вот тут есть решения и даже красивые картинки с замерами производительности. https://medium.com/swlh/mongodb-pagination-fast-consistent-ece2a97070f3 Можно придумать на backend-е еще более экзотические способы. Но в целом, если у вас много skip limit при запросе и много данных - значит вы точно что-то не то делаете.

Доброго дня. У меня в бд появляются дубли, только если интервал запроса к одному документу < 5 мс. Считаю, что проблема в блокировках на уровне бд. Подскажите, какие варианты решения возможны? Добавлять uid, кажется неправильным, нужно будет на уровне кода обрабатывать ошибку при ошибочной повторной вставке. Не могу найти в доке можно ли как-то крутить таймауты для локеров и вообще как их добавить на уровне коллекций. Подскажите мануал нормальный или вариант решения

Что тут подразумевается под дублями?

Документ в коллекции, значения всех его полей идентичны уже имеющемуся документу в этой коллекции , за исключением _id - на 1 больше, чем в идентичном документе.

Это проблема двойной вставки. Зачем дважды доки вставляете? Если это нормально для приклада, то нужно навесить уникальные индексы, которые будут предотвращать дубль

Обращение к бд идет из скрипта. Дубль наблюдается только, когда запущены два скрипта (процесса) условно параллельных (< 50 мс интервал) процесса. Почему тогда при работе только одного процесса нет дублей?! Думаю очевидно, что проблема в рекурентном доступе на уровне бд.

Обращение к бд идет из скрипта. Дубль наблюдается только, когда запущены два скрипта (процесса) условно параллельных (< 50 мс интервал) процесса. Почему тогда при работе только одного процесса нет дублей?! Думаю очевидно, что проблема в рекурентном доступе на уровне бд.

Доброго дня. У меня в бд появляются дубли, только если интервал запроса к одному документу < 5 мс. Считаю, что проблема в блокировках на уровне бд. Подскажите, какие варианты решения возможны? Добавлять uid, кажется неправильным, нужно будет на уровне кода обрабатывать ошибку при ошибочной повторной вставке. Не могу найти в доке можно ли как-то крутить таймауты для локеров и вообще как их добавить на уровне коллекций. Подскажите мануал нормальный или вариант решения

что делают скрипты?

Тянутся актуальные данные от интегратора, кладутся в массив A. Удаляются все документы из коллекции. В цикле из массива A достается объект и сохраняется в коллекцию.

Раньше это было в основной логике монолита. И каждый запрос к ресурсу содержал эту логику. При определенном рпс начали появляться дубли в бд и как следствие на фронте. Я вынес эту логику в джобу, админы настроили ее запуск по крону. Но по какой-то причине в логах вижу, что она запускается дважды условно параллельно. Не хочу зависеть от админских настроек, не хочу переписывать логику и фильтровать дубли в ней. Хочу сделать блокировку на уровне коллекции средствами монги или средствами кода, добавив коллекцию с блокировками.

тут только уникальный индекс или транзакции

Транзакции для монги я не делал и сейчас это кажется оверхэд для проекта и тем более для этого бага. Возможно стоит рассмотреть uid.

хотя очевидно что надо просто пересмотреть то как запускается джоба и это должно полностью рулиться на программном уровне без участия админов

не понятно как вы хотите использовать uid и что оно даст

Мне как разработчику и начальству удобно, что крон джобы можно конфигурировать без моего участия, без нового релиза, без отдела тестирования

Я про уникальный индекс

отсутствие отдела тестирование заметно)

Как раз в тестовом контуре все ок, джоба отрабатывает единожды)

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

Не понял, о чем вы. Я про db.collection.createIndex({"name" : 1}, {"unique" : true})

а причем тут uid тогда

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

А как мне это поможет?

Подскажите. Nodejs. Вытаскиваю напр. 100 документов, в каждом из них в одном из полей 4к ObjectId (рефернсы на другую колекцию), это потребляет кучу памяти. Более того это поле дублируется в каждом доке и можно было бы переиспользовать рефенсы, но нет каждый ObjectId - отдельный буфер. Если конвертнуть в строки - то памяти потребляться будет намного меньше. Можно как то вклиниться в десериализацию, чтобы переиспользвать рефернсы на одинаковые ObjectId? Можно ли возвращать ObjectId строкой для всего документа, а не только, где я прописал $toString?

экономия на спичках. А зачем вытаскивать эти массивы с 4к объектов?

Так логика обновления работает, делаем дифф с прошлым значением

экономия на спичках. А зачем вытаскивать эти массивы с 4к объектов?

Не Экономия на спичках В прототипе переиспользовал референсы - потребление упало с 1200 до 200 мб

не понимаю термина "переиспользовал". Вот есть у вас массив из ObjectId. Вы просто заместо них используете строки?

В моем случае почти у всех доков дубликаты ид в большом поле, я просто юзал пул object id, если уже такой ключ был - беру объект с пула

а причем тут uid тогда