Скажи задержки

тебе надо что-то вроде "**.text": <регулярка>?

Всем привет. Почему реплика сет на вставку гораздо медленнее чем single? Локально у меня реплика из 1 ноды. Разница на insertOne с writeConcern w 1 и без 8 раз. На маке локально. У коллеги локально то ли на винде то ли через докер всего лишь в 3 раза. На сервере тоже в 8 раз разница, но там 3 ноды в реплике. Вопрос, насколько реплика должна быть медленее на вставку, и что можно сделать, чтоб вернуть частично производительность?

Всем дня доброго. Помогите, плз. разобраться. Есть коллекция (довольно тяжелая), количество документов около 4.7млн, весит примерно 22Га. Выполняю один и тот же простой запрос по {атрибут: значение} - время выполнения пляшет от минуты до 5. Нагрузки на базу нет. Что за чертовщина, куда копать можно?

Привет! insertOne в контексте реплик покажет сильную просадку в бенчмарках в связи с тем что кроме записи самого документа нужно еще и записать операцию в оплог. Условные «в 3 раза» медленнее это плюс-минус похоже на корректное измерение А о каких абсолютных числах идёт речь? Насколько вставка по одному документу критична для вашей нагрузки?

не критично совсем, это я вообще случайно заметил. Вот в 3 раза медленнее на проде это было бы нормально в случае 3 нод в сете. Но оно в 8 раз медленее почему то. А у колеги локально в 3 раза как раз. И как я писал, локально у меня реплика из 1 ноды всего. Тоже медленно, хотя почему не понимаю. Я включил комп, хакинтош, ссд 6ГБ/c скорость. Там почему то еще медленее в 2 раза чем на маке. Ну абсолютное значение локально у меня 9мс вставка документа с 5-10 полями по 10 симовов. А без реплики за 1мс вставляет. Это я через system.profile смотрел. Писал выше скрипт, который делает 100_000 вставок. Там вообще 3 поля простых. 15 секунд против 110 разница.

explain показывает использование подходящего индекса

А из запроса большое количество документов возвращается? Все ли запросы покрыты индексами? Если есть запросы мимо индекса, то это может быть причиной что монга упирается в или в пропускную способность памяти, если все данные в неё помещаются, или в пропускную способность диска, если не помещаются

Нубовопрос можно? Ну, тогда спрошу. =) Вот в рамках одного соединения может быть несколько параллельных запросов на чтение? Или они будут в очередь становиться? Я думаю, что, скорей всего, может. Но вдруг. Вот, решил уточнить. =)

А если провести эксперимент?

Нубовопрос можно? Ну, тогда спрошу. =) Вот в рамках одного соединения может быть несколько параллельных запросов на чтение? Или они будут в очередь становиться? Я думаю, что, скорей всего, может. Но вдруг. Вот, решил уточнить. =)

Можно не ждать ответа здесь, а задать тот же вопрос более строго chatgpt, на основе ответа прогуглить его ответ (типа maxPoolSize) для верификации достоверности ответа и все, profit.

Я не знаю :(

Добрый день, подскажите пожалуйста, есть коллекция с ключами (допустим): a,b,c,d,e,f,g,h Запросы к этой коллекции могут приходить с различной комбинацией этих полей, b,c d,e,h a,f,g и т.д. Как правильно их оптимизировать/ускорить? Создать для каждого ключа индекс или для каждого запроса составной индекс на комбинацию? Плодить большое количество индексов тоже не очень хорошая идея как я понимаю, т.к. будет страдать вставка.

Добрый день, подскажите пожалуйста, есть коллекция с ключами (допустим): a,b,c,d,e,f,g,h Запросы к этой коллекции могут приходить с различной комбинацией этих полей, b,c d,e,h a,f,g и т.д. Как правильно их оптимизировать/ускорить? Создать для каждого ключа индекс или для каждого запроса составной индекс на комбинацию? Плодить большое количество индексов тоже не очень хорошая идея как я понимаю, т.к. будет страдать вставка.

Здравствуйте! Такие схемы лучше укладывать в массив словарей формата {key: a, value: b}, Тогда вы можете сделать один индекс {field.key: 1, field.value: 1}, который будет покрывать весь возможный набор комбинаций

Здравствуйте! Такие схемы лучше укладывать в массив словарей формата {key: a, value: b}, Тогда вы можете сделать один индекс {field.key: 1, field.value: 1}, который будет покрывать весь возможный набор комбинаций

Если для каждого поля (ключа), n количество значений, получается в этот массив нужно внести все n вариантов с этим ключом?

Добрый день, поделитесь как можно увеличить скорость отдачи монгосом батчей? Или просто упираемся в потолок 16 мб, bson max size, на ответ? Связка mongodb-kafka source connector На сейчас максимум что выжали nreturned:6323 reslen:16751003 protocol:op_msg remoteOpWaitMillis:467 5529ms

5с на 16мб достаточно много. Запрос по шард ключу? Есть ли сортировки?

Зачем? один раз, когда создаешь индекс

У коллекции https://www.mongodbtutorial.org/mongodb-indexes/mongodb-compound-index/

Салам, есть проблема недостатка опыта с MongoDB. Хочу посоветоваться как лучше моделировать данные. У меня есть пользователи, кампании и организации. Каждому пользователю может быть назначена роль внутри организации и отдельные кампании внутри этой же организации - сама структуре данных выглядит приблизительно вот так { "assigned": [ { "role": "Admin", "organizationId": "6523d763a946c01177cbbc9a", "accounts": [ { "role": "Member", "accountId": "6523d763a946c01177cbbd12" }, { "role": "Admin", "accountId": "6523d763a946c01177cbbf34" } ] }, { "role": "Member", "organizationId": "6523d763a946c01177cbbd45", "accounts": [ { "role": "Member", "accountId": "6523d763a946c01177cbb987" } ] } ] } Дело в том что сейчас это сделано таким образом в Mongoose, что AssignedUserOrganization и AssignedUserAccount это не отдельные коллекции а скорее просто документы которые находятся внутри UserSchema @Schema({ _id: false }) export class AssignedUserAccount { @Prop({ type: Types.ObjectId, ref: 'Account' }) accountId: Types.ObjectId; @Prop({ type: String, enum: UserAssignmentRole }) role: UserAssignmentRole; @Prop({ type: Settings }) settings: Settings; } @Schema({ _id: false }) export class AssignedUserOrganization { @Prop({ type: Types.ObjectId, ref: 'Organization' }) organizationId: Types.ObjectId; @Prop({ type: [AssignedUserAccount] }) accounts: AssignedUserAccount[]; @Prop({ type: String, enum: UserAssignmentRole }) role: UserAssignmentRole; } В данный момент ужасно неудобно обновлять какой-либо AssignedUserAccount если я хочу определённому пользователю сменить роль внутри какой-либо кампании внутри организации Собственно, в чём вопрос - будет ли нормальным решением вынести эти вещи в отдельные коллекции и просто их присоединять к документу пользователя через $lookup? Или это мой мозг привыкший к Postgres автоматически привык всё это разделять на таблицы/коллекции? 🙏

Да это нормально, природа данных такова что так будет удобнее

Гайс, а укого сохранилась 4.2 СЕ для убунты? Ищу винтаж

добрый вечер, можно ли к монге прикрутить полнотекстовый поиск? В идеале sphinx

А что помешает? Напишите код для переноса данных или для одновременного изменения и в монге и сфинксе и вуаля

после индексации, в сфинксе останется исходные данные или внутри сфинкса только индекс?

Как сделаете

а вообще не творю ли я дмчь пытаясь прикурить туда сфинкс?

а вообще не творю ли я дмчь пытаясь прикурить туда сфинкс?