Mark
Всем привет! Подскажите, пожалуйста, есть ли в монго возможность блокировать другие потоки при редактировании документа? И как это сделать? Т.е. у меня сейчас нексолько потоков обращается для редактирования к одному документу. А надо чтобы первый поток заблокировал второй и не позволил второму редактировать. Либо есть какая-то возможность атомарно произвести редактирование одного документа и как это сделать?
Алексей
на 1 документ атомарно по умолчанию
Mark
принял, спасибо парни
Mark
тогда такой вопрос в чём разница между find и findAndModify? только в том что первый возвращает список, а второй только один документ, который попал под условие, и булевое значение ok если удалось отредактировать? Или Я что-то путаю?
Nick
спасибо, изучу этот момент
далеко ходить не придется уже есть выжимка https://www.mongodb.com/docs/manual/reference/method/db.collection.findAndModify/#comparisons-with-the-update-method
Makar M.
Привет всем. Кто может подсказать, почему в stats storageSize больше size примерно в 20 раз?
Makar M.
Является ли это нормой?
Алексей
а ты не удалял много документов/коллекций? почитал что вроде как сторСайз может быть меньше, но вот больше он может быть с учетом того что зарезервировано под уже удаленное, что сайз не учитывает. Но могу ошибаться
Makar M.
Только пишет и читает
Makar M.
Без апдейтов и делитов
Makar M.
В документах много текстовых данных по объёму
Алексей
в доке так аккуратно написано что сторСайз "может" быть меньше сайза, а вот наоборот не описан случай)
Makar M.
Ага)
Makar M.
У меня size около 2гб, а storageSize 41 гб
Алексей
у меня стор раза в 3 меньше сайза... а ты как его получаешь, какой командой?
Makar M.
stats()
Makar M.
У меня size около 2гб, а storageSize 41 гб
ChatGPT кстати не смогла помочь
Алексей
читаю что монго для скорости заранее аллоцирует тебе память на диске, чтобы заюзать ее когда старая заполнится, но не 40 же гигов...
Makar M.
Забыл сказать, у меня ттл стоит на удаление записей
Makar M.
Но с момента создания первого документа ещё не прошёл ттл, поэтому, удалений не было
Makar M.
Мб он как-то влияет?
Makar M.
Хотя и документов немного, 55к
Алексей
в общем ждем более опытных товарищей
belyy.lis
Всем привет, такой вопрос. У меня будет несколько приложений, с одной учётной. Как можно коллекции раскидать по группам или лучше сделать 3 базы данных отдельные?
belyy.lis
Учётка одна, но данные в разных приложениях будут совсем разные.
Алексей
раз все молчат, то я отвечу -я бы сделал разные БД для приложений, чтобы и не пересекались и было понятно чьи данные где лежат
belyy.lis
раз все молчат, то я отвечу -я бы сделал разные БД для приложений, чтобы и не пересекались и было понятно чьи данные где лежат
Тогда надо делать запросы к 2м базам данных. Профиль то один будет, точнее к 3м даже. База мультиаккаутна, приложения 1 и приложения 2
Алексей
а какая разница? не руками же, в приложениях пути, бд и коллекции пропишешь, зато все лежит отдельно под одной крышей
belyy.lis
А 2 коннекта с БД держать это норм практика?
belyy.lis
Или серваки тоже лучше отдельные
Алексей
так все равно у тебя пул соединений будет, обычно в настройках указывают сколько конкретно
karakurt
Ребят, помогите спроектировать бд для чата по типу телеги. Вот такие сущности должны быть примерно: 1. Chat (2 типа: групповой и личный) 2. Message 3. Membership (обозначает участие в чате, поля такие: userId, chatId, settings). В settings буду хранить всякие настройки типо isMuted и т.д. 4. User Основная проблема с сущностью Chat На фронте хочу выводить список чатов. Но личные и групповые по-разному выводятся: У личного чата выводится аватарка и название собеседника, а у группового аватарка и название группы Вот для группового чата структура документа будет такой примерно: { _id: ObjectId(), type: "group", title: "title, avatarUrl: "avatarUrl" } А как для личного сделать не могу допереть
karakurt
{ _id: ObjectId(), type: "dialog", memberships: [ObjectId("membershipId"), ObjectId("membershipId")] } Вот была такая идея, но не знаю, как при получении списка чатов засунуть сюда инфу о собеседнике
Алексей
это все чат и первое и второе, просто во втором только 2 участника) а сущность то одна
Makar M.
Где-то читал, что в монго можно потерять все данные, если внезапно выключить машину на которой она работает и процесс записи из-за этого повредит файлы монго. Типо, файлы есть на серваке, но монго не может их прочитать из-за повреждений. Это актуально ещё?
Алексей
по идее нет, там же пишется типа чекпоинтов постоянно и при падении монга откатится на последний чекпоинт сохраненный, потеряет конечно последнее, но не все
Makar M.
А нужна ли тебе монго в этом случае?
не лучше ли в таком случае юзать sql бд с связями?
karakurt
это все чат и первое и второе, просто во втором только 2 участника) а сущность то одна
да, я понимаю, но у меня у группового чата много всяких других полей: title, description, accessibility (public or private), invite_hash, join_by_request, join_by_link_count ПРосто в вопросе их не привел, чтобы упростить
Makar M.
Но чтобы откатить, нужно прочитать данные
karakurt
И в личном чате все эти поля нафиг не нужны. В SQL они просто все NULL
Алексей
Но чтобы откатить, нужно прочитать данные
так повредиться томогут только новые данные а не старые которые просто лежат
Makar M.
Я говорю о том, что по середине записи в файл выключится свет и монго запишет на половину, повредив структуру
karakurt
А нужна ли тебе монго в этом случае?
почему ты думаешь, что здесь монго не подходит?
Makar M.
Или например при апдейте старых данных, запишет в диск на половину и потом не сможет прочитать
Алексей
Ну т.е. такое может быть?
да для новых данных, старые чекпоинты не повредятся при этом
karakurt
так а мне-то поможете?
Makar M.
Makar M.
В целом, монго для других сценариев
Makar M.
У тебя есть чёткие связи и отношения сущностей
Makar M.
На этом можно хорошо выиграть, заюзав тот же постгрес
karakurt
так вот я написал
karakurt
да, я понимаю, но у меня у группового чата много всяких других полей: title, description, accessibility (public or private), invite_hash, join_by_request, join_by_link_count ПРосто в вопросе их не привел, чтобы упростить
karakurt
И в личном чате все эти поля нафиг не нужны. В SQL они просто все NULL
Makar M.
Сделав пару джоинов и всё, сохраняя целостность данных ключами
karakurt
Мне сказали. что как раз sql не подходит, поэтому и перешел на монго
Алексей
Мне сказали. что как раз sql не подходит, поэтому и перешел на монго
а нужна литебе сущность для персонального чата? пусть сама сущность юзера хранит друзей
Makar M.
Каждый документ будет весить пол тонны)
Алексей
во первых не будет во вторых только обджект_ид храним а не весь документ друга
karakurt
а нужна литебе сущность для персонального чата? пусть сама сущность юзера хранит друзей
ну по сути нет, но я хотел одним запросом просто получить чаты текущего пользователя и все
karakurt
если я разделю на две таблицы/коллекции, то надо как-то под-другому их доставать
Алексей
ну по сути нет, но я хотел одним запросом просто получить чаты текущего пользователя и все
если сущности 2 то все равно 1 запросом не получишь -надо групповые и отдельно персональные
karakurt
karakurt
ааааа
karakurt
крч ладно, подумаю еще
karakurt
спс за помощь
Makar M.
Тут ошибка в том, что и на SQL базах у тебя всё будет быстро работать
Makar M.
А не только на NoSQL
Makar M.
Только в них ты можешь сделать джоины и нужные тебе агрегации данных удобно и понятно, уместив получение чатов в один запрос
Makar M.
Который может отрабатывать за 20-50 мс