Народ, куда копать, как это делается? Операция обновления. Есть два условия. По первому условию из коллекции берём выборку документов. Теперь, если хотя бы один из документов не соответствует второму условию, отменяем весь процесс. Иначе, обновляем документы

Народ, куда копать, как это делается? Операция обновления. Есть два условия. По первому условию из коллекции берём выборку документов. Теперь, если хотя бы один из документов не соответствует второму условию, отменяем весь процесс. Иначе, обновляем документы

А сделать выборку сразу по двум условиям?

А сделать выборку сразу по двум условиям?

Это не одно и тоже же. В моем случае первое условие для выборки, а второе для отмены ВСЕГО запроса

Это не одно и тоже же. В моем случае первое условие для выборки, а второе для отмены ВСЕГО запроса

Второе, это, например, пользователь закрыл соединение?

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

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

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

Ты решаешь не ту проблему. Проблема в том, чтобы в выборке не пришло ничего лишнего. По этому вернусь к первому совету. 2 условия в выборку для обновления

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

Нее, у него доступ к документу в целом есть, нет доступа к полю, которое он пытается обновить

Представь ты пытаешься массово обновить описание статей в каком-то блоге. И вдруг по определенным условиям ты не можешь получить доступ именно к тому параметру статьи, куда ты пытаешься дорваться у ОДНОЙ из статей. Хотя ко всем остальным параметрам имеешь доступ

И если такое стало, нужно откатить изменения во всех уже изменённых

И если такое стало, нужно откатить изменения во всех уже изменённых

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

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

А если транзакции из 4 монги использовать? Там же есть отмена транзакции

Начал транзакцию, проверил все данные, если есть ошибка, отмена транзакции. Если все норм, делаю update. Конец транзакции

Два запроса. Но из-за транзакции и блокировки, это слишком долго. Но у меня есть подозрения что в монге это можно одним запросом сделать. Вот в чём вопрос

Два запроса. Но из-за транзакции и блокировки, это слишком долго. Но у меня есть подозрения что в монге это можно одним запросом сделать. Вот в чём вопрос

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

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

?

Привет! кто-то сталкивался с тем что монга медленно выполняет запросы? либо же драйвер к ней ( node.js, mongoose). При чём по началу всё хорошо - скорость меньше 100 милисекунд, но через день-два скорость падает до 30 секунд. 1) Сервер и монга на aws-е в одном регионе. 2) Данных мало, меньше 10 Мб в сумме. 3) perfomans advisor на монге говорит что всё ок 4) На сервер тоже всё ок - ошибок нету, ресмурсов железки достаточно 5) Конфиг конекшена: { reconnectTries: 30, reconnectInterval: 500, poolSize: Number(process.env.DB_POOLSIZE) || 10, // process.env.DB_POOLSIZE = 20 socketTimeoutMS: 30000, keepAlive: true, useNewUrlParser: true, } 5) раньше грешил на то что я делаю подписку на ченж стрим в монге: const db = mongoose.connection; db.once('open', () => { console.log('db.once(open)') io.on('connection', (socket) => { log.info('Socket connected.'); const changeStream = db.collection('rides').watch(); changeStream.on('create', async () => socket.emit('drivers-map', await queryRidesCoordinates())); changeStream.on('change', async () => socket.emit('drivers-map', await queryRidesCoordinates())); }); }); но кажись проблема не в этом Может есть у кого идеи в чём может быть проблема?

Привет! кто-то сталкивался с тем что монга медленно выполняет запросы? либо же драйвер к ней ( node.js, mongoose). При чём по началу всё хорошо - скорость меньше 100 милисекунд, но через день-два скорость падает до 30 секунд. 1) Сервер и монга на aws-е в одном регионе. 2) Данных мало, меньше 10 Мб в сумме. 3) perfomans advisor на монге говорит что всё ок 4) На сервер тоже всё ок - ошибок нету, ресмурсов железки достаточно 5) Конфиг конекшена: { reconnectTries: 30, reconnectInterval: 500, poolSize: Number(process.env.DB_POOLSIZE) || 10, // process.env.DB_POOLSIZE = 20 socketTimeoutMS: 30000, keepAlive: true, useNewUrlParser: true, } 5) раньше грешил на то что я делаю подписку на ченж стрим в монге: const db = mongoose.connection; db.once('open', () => { console.log('db.once(open)') io.on('connection', (socket) => { log.info('Socket connected.'); const changeStream = db.collection('rides').watch(); changeStream.on('create', async () => socket.emit('drivers-map', await queryRidesCoordinates())); changeStream.on('change', async () => socket.emit('drivers-map', await queryRidesCoordinates())); }); }); но кажись проблема не в этом Может есть у кого идеи в чём может быть проблема?

неправильные индексы, много навешал на модель монгуса... когда ты делаешь выборки, в местах, где не надо менять данные ты делаешь .lean() ?

неправильные индексы, много навешал на модель монгуса... когда ты делаешь выборки, в местах, где не надо менять данные ты делаешь .lean() ?

нет, лин не делаю. там в коллекциях до ста рекордов не больше, индексов пока не создавал - пока не видно наверняка на что они нужны. да и я делаю .select() - по идее это должно обрезать лишние поля документов на уровне БД-шки

да и опять таки - как этим обьяснить что перфоманс теряется со временем?

я уже ума не приложу в чём трабла. поставил сервак пока на ребут каждые два часа (там даунтайм 5 секунд), незаметно, хотя это лютый костыль

да и опять таки - как этим обьяснить что перфоманс теряется со временем?

ну из-за того, что нет индексов, скорее всего, монга пробует закешировать твои выборки, забывает память и своп, вот и получаешь проседание. Да, select - обрезает на момента базы, это правильно. Добавь ещё всюду lean, где нет изменений.

ну из-за того, что нет индексов, скорее всего, монга пробует закешировать твои выборки, забывает память и своп, вот и получаешь проседание. Да, select - обрезает на момента базы, это правильно. Добавь ещё всюду lean, где нет изменений.

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

а что к стати lean даёт?

а что к стати lean даёт?

отвязывает твои данные из базы от монгуса, получаешь чистые обьекты. У нас выборка на 3.5к записей шла около 3 секунд, нативным драйвером - 0.7, а монгусом с lean() - 0.8

отвязывает - это как?

отвязывает - это как?

не можешь вызвать на объекте .save(), например

да и я пока юзаю много где монгузовский populate. ... хз как оно на нём работает

да и я пока юзаю много где монгузовский populate. ... хз как оно на нём работает

популейт работает быстрее, чем $lookup, так что не парся

популейт работает быстрее, чем $lookup, так что не парся

а мне говорили что наоборот - что агрегейшен фреймворк работает шустрее - так как на уровне БД-шки

ну из-за того, что нет индексов, скорее всего, монга пробует закешировать твои выборки, забывает память и своп, вот и получаешь проседание. Да, select - обрезает на момента базы, это правильно. Добавь ещё всюду lean, где нет изменений.

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

а мне говорили что наоборот - что агрегейшен фреймворк работает шустрее - так как на уровне БД-шки

да, сам агрегейш фреймворк работает быстрее, но populate агрегированных данных - лучше $lookup

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

смотри по каким полям у тебя выборки - там и ставь индексы

да, сам агрегейш фреймворк работает быстрее, но populate агрегированных данных - лучше $lookup

с этим у нас тоже был перформенс ишью, выборка длилась около 5 секунд, а когда убрали лукап внутри монги и делали популей уже полученой выборки (50 итемов), то с популейтом скорость стала 0.6 секунды

"но populate агрегированных данных - лучше $lookup" - странно, почему так то?

я вообще хотел запилить аггрегированые вюшки в потрохах которых буде лукап

что бы не делать туёву кучу популейтов

с этим у нас тоже был перформенс ишью, выборка длилась около 5 секунд, а когда убрали лукап внутри монги и делали популей уже полученой выборки (50 итемов), то с популейтом скорость стала 0.6 секунды

тип лукап работает на всех данных коллекций?

"но populate агрегированных данных - лучше $lookup" - странно, почему так то?

Populate это вообще фича монгуза

я вкурсе уже)

А lookup исполняет монга

У меня все на lookup, по мне так удобнее

Yurii , спасибо, буду ковырять)

тип лукап работает на всех данных коллекций?

работает на всех, но когда ты делаешь популейт - он делает один запрос в базу - find({_id: {$in: [ids]}}) а lookup на каждый документ делал дополнительный запрос (до 4 версии точно, сейчас не изучал). Тем самым популейт разруливает тем, что потом в памяти связывает полученные объекты

работает на всех, но когда ты делаешь популейт - он делает один запрос в базу - find({_id: {$in: [ids]}}) а lookup на каждый документ делал дополнительный запрос (до 4 версии точно, сейчас не изучал). Тем самым популейт разруливает тем, что потом в памяти связывает полученные объекты

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

Всем привет! Есть вопросы про шардинг. Имеется система учета статистики посещения сайтов и ее БД. Ожидается очень активный рост количества сайтов в системе, отсюда встал вопрос масштабирования заранее. Важное условие: все запросы к БД всегда выполняются по одному сайту. В данный момент id сайта имеет тип int, растет инкрементально. Насколько я понимаю, логично сделать shard key из id сайта или на его основе. Вопросы: 1. инкрементально растущий int в качестве shard key - допустимо или плохо? в принципе, есть возможность замапить его на guid например. 2. при добавлении нового шарда нагрузка отбалансируется автоматически? и к чему стремится баланс: к разделению диапазона shard key на равные диапазоны? или учитывается нагрузка на каждый шард и распределяется равномерно она? можно ли как-то влиять на процесс распределения (например указывать диапазон значений shard key для шарда)? Заранее извиняюсь, вопросы возможно очень нубские, поэтому буду рад даже если просто ткнете в ссылки/книги.

Всем привет! Есть вопросы про шардинг. Имеется система учета статистики посещения сайтов и ее БД. Ожидается очень активный рост количества сайтов в системе, отсюда встал вопрос масштабирования заранее. Важное условие: все запросы к БД всегда выполняются по одному сайту. В данный момент id сайта имеет тип int, растет инкрементально. Насколько я понимаю, логично сделать shard key из id сайта или на его основе. Вопросы: 1. инкрементально растущий int в качестве shard key - допустимо или плохо? в принципе, есть возможность замапить его на guid например. 2. при добавлении нового шарда нагрузка отбалансируется автоматически? и к чему стремится баланс: к разделению диапазона shard key на равные диапазоны? или учитывается нагрузка на каждый шард и распределяется равномерно она? можно ли как-то влиять на процесс распределения (например указывать диапазон значений shard key для шарда)? Заранее извиняюсь, вопросы возможно очень нубские, поэтому буду рад даже если просто ткнете в ссылки/книги.

1. инкремент - оченб плохо, про это написано в доке по выборку ключа, если не будет вариантов, то монга поддерживает автохеширваоние без изменения самого типа ключа https://docs.mongodb.com/manual/core/sharding-shard-key/#monotonically-changing-shard-keys https://docs.mongodb.com/manual/core/hashed-sharding/ 2. да начнет балансирвоаться само, если собственно включен балансинг - его можно выключать как весь, так и для отдельных коллекций. баланс стремится только к равному количеству чанков, т.е. предполагается, что у вас все равномерно распределено по диапазонам и нет перкосов - это достаточн осерьезная пробелма если у вас данные очень неравномерны по наргрузке и может сложиться ситуация что все горячие данные на одном шарде. монга будет бить на чанки когда они достигнут одного из двух событий - размер выше порога либо количество доков выше опредленного порога. Но тут нужно понимать, что если чунк уже содержит один ключ и его нельяз разделить, то данный чанк будет помечен фагом jumbo и перестанет кудалибо перемещаться. Влиять на распределние можно - есть понятие зон https://docs.mongodb.com/manual/core/zone-sharding/, да и вообще можно ручками/скриптами перекидывать чанки между шардами - ест ьспец команды

1. инкремент - оченб плохо, про это написано в доке по выборку ключа, если не будет вариантов, то монга поддерживает автохеширваоние без изменения самого типа ключа https://docs.mongodb.com/manual/core/sharding-shard-key/#monotonically-changing-shard-keys https://docs.mongodb.com/manual/core/hashed-sharding/ 2. да начнет балансирвоаться само, если собственно включен балансинг - его можно выключать как весь, так и для отдельных коллекций. баланс стремится только к равному количеству чанков, т.е. предполагается, что у вас все равномерно распределено по диапазонам и нет перкосов - это достаточн осерьезная пробелма если у вас данные очень неравномерны по наргрузке и может сложиться ситуация что все горячие данные на одном шарде. монга будет бить на чанки когда они достигнут одного из двух событий - размер выше порога либо количество доков выше опредленного порога. Но тут нужно понимать, что если чунк уже содержит один ключ и его нельяз разделить, то данный чанк будет помечен фагом jumbo и перестанет кудалибо перемещаться. Влиять на распределние можно - есть понятие зон https://docs.mongodb.com/manual/core/zone-sharding/, да и вообще можно ручками/скриптами перекидывать чанки между шардами - ест ьспец команды

благодарю! ясность появилась, пойду вдумчиво читать ссылки

Здравствуйте, как решить проблему с тем что медленный count в монгодб (4.0) если у меня больше 1 мл записей ? пример: db.records.count({“indexed_key”:“string_value”}) на 10 млй записей от 3 до 9секунд

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

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

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

На сервере посмотри iostat -kx 3

у меня все работает в докер контейнерах если что

Процент утилизации диска если близко ко 100, то серв не справляется

Ну контейнер все равно к диску закреплен, можно на сервере, где докер посмотреть диски

Процессор

А count по всей коллекции?

Или с запросом

А сорян

Вижу

Индекс же есть?

вот если что експлайн запроса https://pastebin.com/x9sCPbgK

да, индекс есть

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

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

Мне лично такой подход помог разгрузить сервер даже с большей нагрузкой

так, сейчас скажу что дает iostat -kx 3

В общем чтобы понять нужно знать какая утилизация диска, сколько процессор жрет

вот если что експлайн запроса https://pastebin.com/x9sCPbgK

"version" : "4.1.3",

это что за зверь?

Еше один нюанс, сторадж монги находится на NFS сервере, который в одной виртуальной сетке но на отдельном сервере

"version" : "4.1.3",

https://hub.docker.com/r/bitnami/mongodb/

а постабильнее не хотите?

? могу откатить на более стабильную)

прост 4.1 девелоперская ветка

смотрю что на диск запись 165мб/с

а сколько норма для ссд диска тогда ?

какие нормы? ищите что заявлено производителем и равно ли оно в точности тому что у вас по нагрузке, а так же окружению, свежести дисков и партии

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

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

NFS - самое поганое что может быть для БД

спасибо, я попробую вариант с хранением на самой ноде протестировать

спасибо, я попробую вариант с хранением на самой ноде протестировать

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

это я могу попробовать, где стоит смотреть в конфиге о пути хранения индексов ?

тут не помогу, знаю что это можно сделать, но сам не делал