Алексей
ааа, понял
Алексей
так я бы длин разбил сплитом на три поля и их бы хранил/индексировал, почему поле одно на все имя?
Алексей
по фамилии Бузырева уже быстро отсееет, не надо и текст искать
Elvee
так я бы длин разбил сплитом на три поля и их бы хранил/индексировал, почему поле одно на все имя?
это не очень удобно когда мы ищем. В итоге вместо одного поля у нас их 3 получается
Elvee
по фамилии Бузырева уже быстро отсееет, не надо и текст искать
Сейчас хочу посмотреть как искать точное вхождение
Алексей
еще смущает возврат 80 тыс документов, я полагал что ищем одного кого-то
Andrey
а докер образа для монги 7 еще нет?
Andrey
Нету
хотя странно, указал latest и он подтянул 7.0.1
Black
хотя странно, указал latest и он подтянул 7.0.1
https://hub.docker.com/_/mongo/tags Здесь не указано наличие 7 версии.Вру,есть- https://hub.docker.com/layers/library/mongo/7.0.0/images/sha256-86be2714cae3fbda498f608c67a15c3fd36e7261c5198c2edd8c963f8c4941b4?context=explore Просто оно почему-то не указано в версиях образа
Black
да, спасибо, поэтому и спросил, но db.version() показывает 7.0.1
Есть: https://hub.docker.com/layers/library/mongo/7.0.0/images/sha256-86be2714cae3fbda498f608c67a15c3fd36e7261c5198c2edd8c963f8c4941b4?context=explore Просто не указано в версиях образа почему-то
Can
Добрый вечер А не могли бы подсказать как можно в Монге связать все коллекции DB по id?
Алексей
привет, тебе не реляционная БД нужна случайно тогда? как именно связывать хочешь, по какому признаку?
Andrii
Hi everyone I have around 9+ years of professional experience in all phases of SDLC (Software Development Life Cycle) Including requirements analysis, applications design, development,Integration, maintenance.Extensive knowledge in developing applications in a single page (SPAs) using various JavaScript frameworks like Angular, React.js, Node.js, Nest.js, BackboneJS and Bootstrap.Experienced in developing micro services using Node-JS, Hapi-JS, Express-JS, Docker, H202 and AWS.Solid experience on JavaScript Frameworks like MVC/MWM JavaScript frameworks and Exposure to Node.js.Experience working on scalable environment using Agile/SCRUM methodologies.Strong knowledge of OOP (Object Oriented Programming) and applying 00 principles in full Software Development Life Cycle xperience in cross browser and cross-device compatibility check and thoroughly performed unit testing using Jasmine, Mocha, JUnit and Karma.   if you are looking for Full-Stack Developer Please DM
Easy Rider
Всем привет. Столкнулся с такой штукой - при параллельных запросах вылазиет иногда ошибка "Command update failed: WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction" Это в документации советуют проверять и делать повторную попытку записи. А нельзя ли как-то указать монге чтобы она не начинала транзакцию или операцию, пока не окончена предыдущая? Ну как бы работала чтобы просто в 1 поток и всё
Easy Rider
Иначе получается куча нафиг не нужного кода, который все будет замусоривать
Алексей
а ты в один и тот же документ чтоли пишешь из разных потоков?, как так получается?
Nick
Всем привет. Столкнулся с такой штукой - при параллельных запросах вылазиет иногда ошибка "Command update failed: WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction" Это в документации советуют проверять и делать повторную попытку записи. А нельзя ли как-то указать монге чтобы она не начинала транзакцию или операцию, пока не окончена предыдущая? Ну как бы работала чтобы просто в 1 поток и всё
начинать или нет говорит клиент, т.е. ваш софт и делается это всегда в явном виде, проверяйте код где вы стартуете их. Вообще использование транзакций - это особенная ситуация, когда почемуто другими способами вы не можете решить проблему и осознанно выбираете этот путь, и значит вы понимаете их ограничения и что в случае фейла транзакции надо чтото делать либо ретраить либо еще чтото либо вообще просто ошибку юзеру показать и откинуть запрос.
Easy Rider
Не в документ а в коллекцию
Easy Rider
В документ и нельзя, монга же атомарна на уровне документа
Easy Rider
начинать или нет говорит клиент, т.е. ваш софт и делается это всегда в явном виде, проверяйте код где вы стартуете их. Вообще использование транзакций - это особенная ситуация, когда почемуто другими способами вы не можете решить проблему и осознанно выбираете этот путь, и значит вы понимаете их ограничения и что в случае фейла транзакции надо чтото делать либо ретраить либо еще чтото либо вообще просто ошибку юзеру показать и откинуть запрос.
Почему особенная ситуация? Это абсолютно нормально. Транзакции нужны и повсеместно используются. Монга просто ведет себя уродски. Она пытается взять блокировку при начале транзакции в течение 5 миллисекунд, и если не получилось, выдает ошибку. А я хочу чтоб она до победного пыталась это сделать. Ну или хотя бы чтобы можно было указать - например, 5000 миллисекунд. Иначе придется везде писать обвязку - чтобы повторные попытки записи были. Лишний код получается, там где его могло бы не быть
Easy Rider
В 1 поток все работает отлично. Как только есть хотя бы 2 потока, уже начинают постоянно лезть ошибки.
Easy Rider
а поподробней можно что за инфа про 5 мс, ссылочкой бы
Да я щас с телефона, на компе гуглил. В mongo shell это можно поменять. И когда я поменял, там вылезло что «изменено с 5 на 5000», то есть не наврали. Правда это не сработало, как были ошибки так и остались
Easy Rider
а особенная потому что обычно все решается обычными апдейтами без транзакций которые как раз просто на уровне документа работают без блокировок
Если мне надо изменить документы сразу в 2 коллекциях или в 2 документах в 1 коллекции? Классический пример. Списываем деньги с 1 юзера и добавляем другому. До кучи можно еще куда-то добавлять инфу о том что был перевод средств. Если не использовать транзакции, то при сбое, могут списаться деньги с 1 человека, а второму не зачислиться, и лог об этом тоже не будет создан. Деньги просто как бы исчезнут. Ну в журнале можно будет посмотреть, но это уже не бизнес-логика приложения будет, а ручная работа по поиску пропавшего бабла
Easy Rider
это чуть ли не единственная ситуация применения транзакций в принципе, когда без них реально нельзя. Вы же говорили что это обычная ситуация и они походу нужны чуть ли не на каждый чих
Таких ситуаций миллиард. Например вот у меня ситуация такая щас. Я логгирую все обращения к api бекенда. Запись идет просто о запросе (юзерагент, заголовки, тело и т.д.) и потом сразу пишу в другую таблицу количество запросов пользователя за конкретный день (вставка или инкремент). Это должно быть согласовано.
Easy Rider
Но дело даже не в этом. На практике, монга и без транзакции может выдать ошибку записи. Если разные потоки пишут в одну коллекцию.
Easy Rider
у вас реально в одной транзакции это делается?
Да, но это только 1 пример, таких наверное еще пара десятков.
Easy Rider
Например пользователь регается на сайте. При этом используется промокод. В коллекции промокодов должно инкоементироваться число использований этого промокода. Тоже нужна транзакция
Easy Rider
Easy Rider
Короче, я теперь понимаю почему в интернете так много статей называющихся примерно «почему вам ни в коем случае нельзя использовать монгодб», в которых первоначальный энтузиазм сменился на осознание в какую жопу залезли 😀
Easy Rider
Nick
что касается сброса параметра maxTransactionLockRequestTimeoutMillis, он как и другие если выставляется через adminCommand, то работает до ребута. После ребута опять дефолтное значение будет. Если требуется и после ребута, то надо в конфиге указывать либо через параметр запуска mongod Но в целом странно что вам надо столько ждать лока, у вас случаем не обернутов транзакцию кучу кода, который не связан с работой с бд?
Easy Rider
и до ребута и после ребута, не работает
Алексей
ну похоже кто то еще одновременно хочет туда же куда ты закрыл доступ транзакцией, вот тут описана ситуация похожая на твою https://www.mongodb.com/community/forums/t/mongoservererror-writeconflict-error-this-operation-conflicted-with-another-operation-please-retry-your-operation-or-multi-document-transaction/206298
Алексей
кстати, в своем коде я попытался пересмотреть схемы и избавился почти от всех транзакций, но пара все равно есть и они нужны, они правда не падают как у автора выше, но скорее причина в том что продукт не в проде, а интеграционные и нагрузочные тесты этот момент не покрывают. По коду вижу, что теоретически ситуация как у автора выше -возможна. Обойтись без транзакции нельзя - если первое действие пройдет, а второе нет то получаем проблему, пример с балансом средств хорошо подходит. В итоге какие есть варианты решения? Я с монго недавно начал работать, но тут есть люди с большим опытом, как вы решаете такие вещи? Ретраи, таймауты, логи, findAndUpdate?
Tetra
кстати, в своем коде я попытался пересмотреть схемы и избавился почти от всех транзакций, но пара все равно есть и они нужны, они правда не падают как у автора выше, но скорее причина в том что продукт не в проде, а интеграционные и нагрузочные тесты этот момент не покрывают. По коду вижу, что теоретически ситуация как у автора выше -возможна. Обойтись без транзакции нельзя - если первое действие пройдет, а второе нет то получаем проблему, пример с балансом средств хорошо подходит. В итоге какие есть варианты решения? Я с монго недавно начал работать, но тут есть люди с большим опытом, как вы решаете такие вещи? Ретраи, таймауты, логи, findAndUpdate?
все зависит от контекста задачи, гдето 3 ретрая, гдето просто сразу ошибка показывается юзеру, гдето надо заново все переобщитать, перезапустив таску. А гдето полное изменение структуры данных так чтобы обошлось одним идемпотентным апдейтом без всяких транзакций
Алексей
да, вот со структуры я начал, удалось кое-что убрать и решить простой 1 записью. Но не везде. Надо попробовать с ретраями, тут только вопрос как это протестировать? просто это еще не падало и фиг знает как воспроизвести, вернее не просто воспроизвести.
Tetra
да, вот со структуры я начал, удалось кое-что убрать и решить простой 1 записью. Но не везде. Надо попробовать с ретраями, тут только вопрос как это протестировать? просто это еще не падало и фиг знает как воспроизвести, вернее не просто воспроизвести.
тут полноценное нагрузочное надо проводить с имитацией действий пользователей. Либо хитрить и в коде просто добавлять слипы внутри транзакций, но это не совсем корректно, разве что чтобы вызывать ошибки чаще.
Алексей
Алексей
правда, что важнее, твой пост навел на идею как еще от одной транзакции избавиться изменив схему, спасибо тебе! )
Easy Rider
В общем, в драйвере есть хелпер - WithTransaction, который как бы берет на себя перезапуск транзакции в случае неудачи. Все это довольно фигово работает, если 1 поток, все быстро. При 2 потоках падение скорости уже заметно, при 10 - на 2 порядка. Получается, постоянно где-то внутри там идут конфликты, и транзакции постоянно перезапускаются, опять попадают на конфликты и так до тех пор пока наконец не получится завершить транзакцию. Простая блокировка в коде, так чтобы одновременно только 1 поток мог выполнять транзакцию, возвращает скорость к нормальной. Ну то есть независимо от того сколько потоков пытаются получить доступ к транзакции, все равно они становятся в очередь и одновременно только 1 транзакция работает. И это работает быстро. Не пойму, как это можно сделать без самостоятельной организации такой блокировки. Но тут новая проблема. if (!await _dbService.visitors.IncrementAsync(session, ...parametrs...)) { await _dbService.visitors.InsertAsync(session, ...parametrs...); } Транзакция просто не работает. При многопоточности, сколько одновременно потоков начинают выполнять это, столько документов и вставляется, а уже потом, начинается инкремент
Easy Rider
ну логика такая, если не получилось инкрементировать документ в коллекции (потому что его нет еще), то мы вставляем новый. Все это должно действовать атомарно, но на практике, получается что все транзакции запускаются одновременно, консистеность не обеспечивается, и они все сразу смотрят что документа еще нет и вставляют его.
Andrey
Если такая «с транзакциями беда» - реализуйте свой случай кодом?
Алексей
А если сделать апсерт? Вроде по условию ты проверяешь успех и если нет то делаешь инсерт, апсерт одним апдейтом поможет
Easy Rider
Сделал апсерт, короче. Причем, если он выполняется внутри транзакции, он почему-то теряет атомарность
Easy Rider
ну логика такая, если не получилось инкрементировать документ в коллекции (потому что его нет еще), то мы вставляем новый. Все это должно действовать атомарно, но на практике, получается что все транзакции запускаются одновременно, консистеность не обеспечивается, и они все сразу смотрят что документа еще нет и вставляют его.
Тут примерно начинаю понимать - отчего так. Монга не может заглянуть в код и посмотреть какие там операции внутри транзакции выполняются. Она просто откатывает транзакцию, если возник конфликт. Но если конфликта не возникает, все сразу транзакции выполняются. В общем, это не то же самое что оператор lock, транзакция не делает так чтобы участок кода который лежит в транзакции мог выполняться только один в один и тот же момент времени
Богдан
Всем привет! При запуске спринг приложения на базе монго выходит такая ошибка. Уже второй день не могу разобраться в чём дело. Может подскажите на что обратить внимание, чтобы решить вопрос?
Nick
Всем привет! При запуске спринг приложения на базе монго выходит такая ошибка. Уже второй день не могу разобраться в чём дело. Может подскажите на что обратить внимание, чтобы решить вопрос?
проблемы с поднятием embedded mongo, вам надо слазить в код где оно инициализируется и смотреть что за процесс там пытается стартануть и разбираться почему не может
Алексей
code 48 на скрине "This is an error message that MongoDB users often get when the port for MongoDB is already in use."
Богдан
там кстати выше не вошло на скрин но есть ошибки монги, вот их бы посмотреть, все что до строк о завешении
Часть выше. Опишу ситуацию после которой возникла проблема. Другой разработчик написал бэк и успешно запустил его, всё работало. Но потом я (совершенно без знаний) влез в код и изменил файлы модели базы данных, репозитория и апи). Приложение перестало работать, после я вернул старые файлы, но ошибка сохранилась. Удалил приложение, закачал заново код с гита, собрал, но всё равно не запускается. Такое чувство, что вопрос не в приложении, а в чём то внешнем
Алексей
ты прочел мой коммент выше про код 48?
Алексей
вот ответ
Алексей
твоя монга на порту еще жива, новая не поднимется пока старую не убьешь
Алексей
ИЛИ тот порт занят кем то другим что вряд ли, если вы не мухлевали с портами
Kvhqm
Ну или что-то в этом роде. Видишь как получается, нарушил правило, теперь не работает...
Богдан
твоя монга на порту еще жива, новая не поднимется пока старую не убьешь
То есть в настройках приложения нужно указать другой порт? Здесь..
Алексей
Алексей
То есть в настройках приложения нужно указать другой порт? Здесь..
погоди, а не проще разобраться что с портом?)) может подключиться через монгош и прибить? нафиг порты то менять?
Алексей
что он занят мы и в логах увидели, а вот занят ли он монгой -в терминале запусти mongosh он сам подключится если там бд
Алексей
но вообще мне интересно а ваше приложение при выключении не должно убивать монгу? или при старте проверять что она стартанула и к ней просто подключиться а не пытаться новую поднять? ПРосто если это монга (99%) получается после завершения работы приложения она продолжает работать и не дает вам заново запуститься
Алексей
ну вот, в прошлый раз ты ее точно запустил несмотря на правки)
Алексей
осталось убить и можно заново стартовать