Делаю пет-проект, который сохраняет сообщения в базу данных. Нагрузка - до 10К сообщений в день от самых разных юзеров сервиса с самыми разными сообщениями из различных сред (группа, тет-а-тет и т. д.). Какой путь выебрет (тут нет опечатки) 30-летний скуфердяй фронтенд-макака для хранения записей о сообщении? 1. Хранить все записи о сообщениях в одной коллекции; 2. Создавать уникальные коллекции под каждого юзера.

Первое, на таких объемах нет смысла чтото выдумывать

Делаю пет-проект, который сохраняет сообщения в базу данных. Нагрузка - до 10К сообщений в день от самых разных юзеров сервиса с самыми разными сообщениями из различных сред (группа, тет-а-тет и т. д.). Какой путь выебрет (тут нет опечатки) 30-летний скуфердяй фронтенд-макака для хранения записей о сообщении? 1. Хранить все записи о сообщениях в одной коллекции; 2. Создавать уникальные коллекции под каждого юзера.

друзья, прошу подсказки, никак не могу разобраться. Есть монго БД, при запуске/рестарте порождает 3 процесса Main PID: 12818 (mongod) CGroup: /system.slice/mongod-shard.service ├─12818 /usr/bin/mongod --quiet -f /etc/mongod-shard.yconf run ├─12821 /usr/bin/mongod --quiet -f /etc/mongod-shard.yconf run └─12822 /usr/bin/mongod --quiet -f /etc/mongod-shard.yconf run при этом она не работает, к ней нельзя законнектиться локально, праймари сообщает, что данная нода недоступна. Порт не отображается, как работающий. Килл "лишних" процессов ни к чему не приводит, систем-юнит active, но при этом порт и БД все равно недоступны. Все остальные члены РС имеют 1 пид, а не три, работа идет нормально.

где запускается? как настраивали?

вм на центосе, системд-юнит классический. Настройки по дефолту все практически, ничего такого... На данный момент обнаружил призрачную зацепку, что был ООМ Out of memory: Kill process 1929 (mongod) score 935 or sacrifice child но это скорее следствие того, что у меня 3 пида вместо одного

Всем привет! Совершаю ли я военное преступление антипаттерн, когда у меня в сущности, сохраненной в базе, такие поля? "_id": { "$oid": "654b9605f6be299a150196be" }, "id": "aa14ecfb-173d-45da-ac58-759c6a758614", Должны ли _id и id быть одинаковыми?

Всем привет! Совершаю ли я военное преступление антипаттерн, когда у меня в сущности, сохраненной в базе, такие поля? "_id": { "$oid": "654b9605f6be299a150196be" }, "id": "aa14ecfb-173d-45da-ac58-759c6a758614", Должны ли _id и id быть одинаковыми?

Зачем id, если есть _id

Ты можешь при выборке _id превращать в id

Потому что в _id какая-то составная пое****, а мне нужны стринги, когда raw-значение получаю для парсинга

Парни и Девочки, привет! У меня есть проблема при восстановлении бэкапа монги. У меня выполняется бэкап шардированной монги с помощью pbm logical. В одной из коллекций попадает дубликат некоторых документов: Если грепнуть по bson файлу, можно увидеть что по данному документу присутствует дубликат, отличающийся только по полю expiringAt. {"_id":{"visitor":"435fu2llsdj5k68fl5vn56l","category":{"$numberLong":"1288087480"}},"expiringAt":{"$date":{"$numberLong":"1700430111337"}}} {"_id":{"visitor":"435fu2llsdj5k68fl5vn56l","category":{"$numberLong":"1288087480"}},"expiringAt":{"$date":{"$numberLong":"1701680914145"}}} При восстановлении базы, pbm агент доходит до дубликата и заваливается с ошибкой, не завершив процесс восстановления, что очень не очень. Есть ли варианты игнорить дубликаты или заставить агента реагировать на них адекватнее? Кто вообще сталкивался с такой проблемой?

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

вот такие ошибки: 2023-10-13T16:02:03Z E [rs3/shard03:27017] [restore/2023-10-13T13:46:51.684551381Z] restore: mongorestore: restore mongo dump (successes: 236433292 / fails: 2): sponsore.intereste: error restoring from archive on stdin: bulk write exception: write errors: [E11000 duplicate key error collection: sponsore.intereste index: _id_ dup key: { _id: { visitorId: "435fu2llsdj5k68fl5vn56l", categoryId: 44445 } }] 2023-10-13T17:29:26Z E [rs2/shard02:27017] [restore/2023-10-13T13:46:51.684551381Z] restore: mongorestore: restore mongo dump (successes: 284324699 / fails: 1): sponsore.intereste: error restoring from archive on stdin: bulk write exception: write errors: [E11000 duplicate key error collection: sponsore.intereste index: _id_ dup key: { _id: { visitorId: "7dfed5bab75efdsj345a17", categoryId: 2568 } }]

а в коллекции все чисто было перед восстановлением?

да, восстановление происходит в чистый подготовленный кластер.

при восстановлении явно указываются названия коллекций откуда куда? https://www.mongodb.com/community/forums/t/monogrestore-is-always-failing-with-e11000-error/249740

нет, не явно, восстановление происходит через pbm, восстанавливаю исходя из мануала: https://docs.percona.com/percona-backup-mongodb/reference/pbm-commands.html#pbm-restore командой: pbm restore <имя бэкапа> --mongodb-uri=localhost:27017

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

В любом случае спасибо за помощь :)

по перконе нашлось такое https://jira.percona.com/browse/PBM-1197

Да) это мой тикет)

хех)) а какой ключ шардирования?

По ключу id

тогда мои варианты все) остаются баги выборок на границах чанков или если чанки в этот момент в состоянии миграции и почемуто доступны на разных шардах для чтения, надо шерстить ченжлоги фиксов с 5 версии мож где чего такое и всплывало. Плюс в версиях которые указаны в тикете точно есть проблемы, поэтому стоит начать с обновлением до актуальной 5.0.21

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

а можно как то рассчитать, сколько монге нужно ОЗУ,для хорошей работы? или руководствуемся тем, чем больше тем лучше?)

а можно как то рассчитать, сколько монге нужно ОЗУ,для хорошей работы? или руководствуемся тем, чем больше тем лучше?)

Решил, оказывается в url для mongoose нужно было указать конкретную базу данных, а иначе он просто создавал пустую коллекцию в базе данных test

приветь как исправит ?

приветь как исправит ?

молодец, хорошо обрезаешь

Смотри логи. Может база corrupted.

😂 status =4

Логи нет ничего

всем бобра, подскажите, есть задать реквизиту уникальность, и при этом не заполнить его 1 раз, то все будет ок правильно ? а есть вот уже второй обьект будет без этого свойства, то будет еррор ?) хотя по логике значения не повторялись, но и там и там их ОДИНАКОВО нет, оно на это ругается или я это придумал уже

Хоть ты и не указываешь, но там не явно будет null и из-за этого ошибка. Когда создаешь индекс, надо прописать при каких условиях проводить проверку на уникальность.

Ты как смотрел?

в логах системы смотри

Парни, а как мне переносить данные с одной таблицы в другую? У меня по тз надо перенести из сотрудников данные в отпуск

таково условие тз

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

ну, вроде же в акссесе это поля привязывать и переносить