Соответственно почти 100% изменений увеличивают размер документов.

Это неважно, всегда перезаписывается весь док

всегда создаётся копия страниц с документом, да

понял, спасибо

но тут такой момент: паттерн запроса это универсальная проблема

Похожие по форме изменения, но данные для каждого дока свои. Абстрагируясь от предметной области можно представить так: Нужно из общего лога комментариев к постам раз в какое-то время обновлять документы с постами: дописывать комментарии в соответствующий список, обновлять каунтеры.

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

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

*от проблемы не убежать

А где можно почитать, как именно монга работает с документами на уровне хранилища? Детали CoW, как переиспользуется место старых версий документов, вот это все.

это вам не важно воообще

хорошо работает, отлично прямо

99.(9)% что ваши проблемы будут лежать далеко за пределами этой предметной области :)

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

В терминах постов и каментов: взяли из лога 1M каментов, из них 100k уникальных айди постов, эти 100k айди (последовательно, батчами, всем скопом — как будет эффективнее) используем для запроса

такие простые вещи как пропускная способность памяти, дисковой системы и размер «горячей» части данных — вот ваши проблемы

В терминах постов и каментов: взяли из лога 1M каментов, из них 100k уникальных айди постов, эти 100k айди (последовательно, батчами, всем скопом — как будет эффективнее) используем для запроса

а зачем батчем, почему бы не делать сразу?

Если можно сразу — значит сразу

ну если у вас будет update и вы точно знаете _id документа, то всё будет зависеть от двух факторов

размер активной части индекса и размер активной части документов

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

на моём дохлом mba 13 года с каким-то тухленьким ssd который вообще по sata подключен, монга может ~30к инсертов в секунду делать

с документами по килобайту примерно

Звучит обнадеживающе 🙂 Пошел разбираться и пробовать. Большое спасибо!

Привет. Порядок документов в коллекции, в которую не добавляются документы, при запросах с пагинацией (limit/skip) без сортировки сохраняется между запросами? А при добавлении / изменении, опять же без сортировки, могут ли "перетасоваться" ранее добавленные документы?

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

на практике в рамках standalone инсталяции у вас скорее всего порядко меняться не будет

на практике в рамках standalone инсталяции у вас скорее всего порядко меняться не будет

Спасибо, мне этого достаточно. Хотелось бы ещё уточнить, изменение документа (например сильное увеличесние количества содержимого) теоретически могло бы его поднять выше?

нет

Благодарю за ответ.

изменение дока скорее всего откинет его в конец

нет

внутренний id не меняется в течении жизненного цикла документа на одной ноде

внутренний id?

да

давай ликбез

«коллекция» на самом деле состоит минимум из двух k/v хранилищ. одно для _id и другое для документов

в k/v для документов в роли ключа используется внутренний индектификатор

он-же используется в индексе для адресации документа

по нему-же и происходит natural сортировка

емнип там был varint который более-менее монотонно возрастает

ARGUMENTS TO $LOOKUP MUST BE STRINGS, LET: {USER_ID: {$TOSTRING: "$_ID"}} IS TYPE OBJECT

был какой-то ключ для проекции, чтоб включить отображение внутренного id

Подскажите пожалуйста из-за чего данная ошибка падает

спасибо

скиньте всю часть с лукапом

был какой-то ключ для проекции, чтоб включить отображение внутренного id

https://docs.mongodb.com/manual/reference/method/cursor.showRecordId/

скиньте всю часть с лукапом

ARGUMENTS TO $LOOKUP MUST BE STRINGS, LET: {USER_ID: {$TOSTRING: "$_ID"}} IS TYPE OBJECT

а запрос в чем выполняется?

Драйвер mongoskin

версия монги?

версия монги?

3.4.19

синтаксис лупак с пайплайном появился в 3.6

синтаксис лупак с пайплайном появился в 3.6

большое спасибо

https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/#join-conditions-and-uncorrelated-sub-queries

Добрый вечер, помогите, пожалуйста. Недавно пользуюсь MongoDB, и до этого проблем не было, работал на localhost. Сейчас потребовалось соединиться с базой, мне дали такую строчку, но не понимаю, куда ее вводить, пробовал в mongo cmd - не работает. mongodb+srv://gkola2:<password>@gkolal-nm3q3.mongodb.net/test

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

а dmesg что говорит ?

а dmesg что говорит ?

конкретно монги там не нашел вообще, почему то. но есть пару ошибок "Out of memory" с другими приложенями. а есть способ предотвращения таких случаев кроме повышения памяти? например автоподнятие. потому что такое приходит довольно редко и память редко забивается вся

конкретно монги там не нашел вообще, почему то. но есть пару ошибок "Out of memory" с другими приложенями. а есть способ предотвращения таких случаев кроме повышения памяти? например автоподнятие. потому что такое приходит довольно редко и память редко забивается вся

monit но решение, честно говоря, так себе

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

Я бы еще посоветовал глянуть на настройки самой монги и сколько она использует памяти для сортировок и агрегаций

конкретно монги там не нашел вообще, почему то. но есть пару ошибок "Out of memory" с другими приложенями. а есть способ предотвращения таких случаев кроме повышения памяти? например автоподнятие. потому что такое приходит довольно редко и память редко забивается вся

Вынести монгу на отельный сервер

Но вообще странно что там бэктрейс

Можно ещё покрутить размер кеша WT или отключить OOM, но это все полумеры

конкретно монги там не нашел вообще, почему то. но есть пару ошибок "Out of memory" с другими приложенями. а есть способ предотвращения таких случаев кроме повышения памяти? например автоподнятие. потому что такое приходит довольно редко и память редко забивается вся

добавить swap?)) (шучу, сделает хуже) а вообще https://docs.mongodb.com/manual/administration/production-notes/#prod-notes-ram

Можно ещё покрутить размер кеша WT или отключить OOM, но это все полумеры

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

Нет, из логов ничего не понятно.

Нет, из логов ничего не понятно.

понял, спасибо

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

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

а докер помочь не может в этом случае?

От докера больше памяти не станет :)

если туда вынести приложение вместе с монгой

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

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

Так ООМ же всё подряд убивает, можно как костыль OOMScoreAdjust монге подкрутить

Так ООМ же всё подряд убивает, можно как костыль OOMScoreAdjust монге подкрутить

да, плохое решение. лучше буду решать проблему нормально, как сказали🙂

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

хм, а в логах монги такое есть. это не изза отсутствия места на самом сервере? но у меня её вроде достаточно🤔

да тут точно нехватка места на диске

судя по времени монга как раз и падает когда у меня бекап на сервере делался, в то время похоже бекап забивал всю память на диске, пока старый не удалился ещё

Приветствую. В какую сторону мне стоит посмотреть если у меня такой юзкейс: Есть коллекция, и рефы из её документов могут быть в других коллекциях, и нужно считать, допустим, количество рефов на этот документ. Динамически с каждым добавленным/удалённым рефом. doc { _id: {ObjectID} data: {...some data} timesReferenced: {int} } Мнения?

yopp, в статьях по Casual Consistancy упоминается про ролл бэке, неасмотря на то, что речи о транзакциях здесь нет. В частности, при записи чего либо в read cocern w: 1 может возникнуть чтение данных, которые были откачены. То есть данные пришли на primary, там сохранились и дальше, к примеру, начала выполняться операция чтения. В то же время происходит репликация на слейвы, в процессе которой может что-то пойти не так и произойдет ролл бэк?