Да я перед этим создаю индекс по 3 ключам группировке

let creditDeleted = 0; const creditCursor = db.transaction.aggregate([ { $match: { type: "CREDIT", creditRrn: { $ne: null } } }, { $group: { _id: { userGuid: "$userGuid", creditGuid: "$creditGuid", creditRrn: "$creditRrn" }, ids: { $push: "$_id" }, count: { $sum: 1 } } }, { $match: { count: { $gt: 1 } } } ]); creditCursor.forEach(group => { const idsToDelete = group.ids.slice(1); if (idsToDelete.length > 0) { db.transaction.deleteMany({ _id: { $in: idsToDelete } }); creditDeleted += idsToDelete.length; } }); print(`Deleted ${creditDeleted} CREDIT duplicates`);

Про индексы уже сказали. Еще можно собирать все триплеты в батчи например по 10к и уже его большой отправить на удаление в базу. Раз агрегация такая долгая, то стоит результат выгрузить во временную коллекцию чтоб не тратить время

Привет. MongoDb 7.0.9. Данные периодически удаляются (не нужны в долгосрочной перспективе). Понятно, что место операционной системе не возвращается без компактирования. Скоро закончится свободное место и, если я правильно понимаю, место, которое было использовано ранее данными, будет переиспользовано. И мне ничего с этим делать не нужно. Я прав?

всем привет есть ли крупные примеры использования mongodb, если необходимы ACID? какие подводные камни и недостатки использования mongo с транзакциями? case: проект с часто меняющейся структурой, но есть крупная логика с фин-операциями

https://www.mongodb.com/docs/manual/core/transactions/ ?

уже ознакомился

всем привет есть ли крупные примеры использования mongodb, если необходимы ACID? какие подводные камни и недостатки использования mongo с транзакциями? case: проект с часто меняющейся структурой, но есть крупная логика с фин-операциями

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

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

всем привет есть ли крупные примеры использования mongodb, если необходимы ACID? какие подводные камни и недостатки использования mongo с транзакциями? case: проект с часто меняющейся структурой, но есть крупная логика с фин-операциями

фин операции лучше хранить в SQL

почему?

acid

фин операции лучше хранить в SQL

когда у тебя меняются мелкие значения то SQL если у тебя меняется раз за разом вся JSON структура то видимо MongoDB 😄

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

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

Всё верно, но * если большое приложение - описывать это на языке со строгой типизацией и сразу возникает ситуация, что надо данные как-то размечать и структурировать * в Postgres есть JSONB

2тб MySQL Вроде проблем нет

2тб MySQL Вроде проблем нет

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

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

всем привет. Настраиваю pbm для нешардированной монги (реплика-сет из 3 нод). При попытке выполнить pbm status или pbm config выдает сообщение Error: connect to mongodb: get config server connection URI: mongo: no documents in result . URI в переменной окружения задан так: PBM_MONGODB_URI="mongodb://pbmuser:pass@localhost:27017/?authSource=admin&replicaSet=rs0"в mongosh с этим URI pbmuser успешно заходит. Сам pbmuser имеет следущие роли: user: 'pbmuser', db: 'admin', roles: [ { role: 'clusterMonitor', db: 'admin' }, { role: 'backup', db: 'admin' }, { role: 'restore', db: 'admin' }, { role: 'pbmAnyAction', db: 'admin' }, { role: 'readWrite', db: 'admin' } ], Кто-то сталкивался? Для шардированных кластеров такие же настройки ожидаемо работают. Ощущение, что пбм считает мой реплика сет шардированной монгой и пытается запросить ее Версия монги 7.0.12, версия PBM 2.9.1

export переменной PBM_MONGODB_URI перед запуском агента PBM делали?

Если конфиг pbm настраивали в pbm_config.yaml, то запускать нужно соответственно, например: pbm config --file /etc/pbm_config.yaml

затем только запуск самого pbm-agent

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

а что в конфиге?

Всем привет, могу ли я настроить шардинг только на одной машине? По определенным причинам я пока не могу выносить БД за пределы одной машины, а коллекция стала очень большой (более миллиарда записей). Поэтому ищу любые способы оптимизировать запросы, буду благодарен советам 🙏

без разницы, хоть с3 хранилище, хоть локальное. Можно даже несуществующий файл ему дать на вход - он просто не обращается в файл, потому что заканчивает выполнение раньше. Утилита обращается в монгу, не получает откуда-то ожидаемых документов и прекращает выполнение # ls ~/foo.yml ls: cannot access '/root/foo.yml': No such file or directory # pbm config --file ~/foo.yml Error: connect to mongodb: get config server connection URI: mongo: no documents in result

Ну, если я передаю ему несуществующий файл то он хотя бы такое пишет: # pbm config --file ~/foo.yml Error: unable to get new config: open "open /root/foo.yml: no such file or directory": open /root/foo.yml: no such file or directory Или так: # pbm config Error: get: mongo: no documents in result

Что в конфиге самой монги?

а что конкретно интересует? Нешардированная монга, реплика сет из трех нод

да, настраивал. При вызове pbm status или pbm config успешно аунтифицируется в базе юзер (видно в логе) . Так же успешно проходит соединение, если вызвать mongosh $PBM_MONGODB_URI Current Mongosh Log ID: 6891fc12dece6a9f8ce3e840 Connecting to: mongodb://<credentials>@<host>:27017/admin?replicaSet=rs0&appName=mongosh+2.5.1 Using MongoDB: 7.0.12-7 Using Mongosh: 2.5.1 rs0 [primary] admin>

Здравствуйте! А вы уже кофигурировали хранилище резервных копий? https://docs.percona.com/percona-backup-mongodb/install/backup-storage.html#procedure Вероятно no documents in result по причине что коллекция admin.pbmConfig пустая или её вообще нет

Здравствуйте! А вы уже кофигурировали хранилище резервных копий? https://docs.percona.com/percona-backup-mongodb/install/backup-storage.html#procedure Вероятно no documents in result по причине что коллекция admin.pbmConfig пустая или её вообще нет

Всем привет, могу ли я настроить шардинг только на одной машине? По определенным причинам я пока не могу выносить БД за пределы одной машины, а коллекция стала очень большой (более миллиарда записей). Поэтому ищу любые способы оптимизировать запросы, буду благодарен советам 🙏

Всем привет, могу ли я настроить шардинг только на одной машине? По определенным причинам я пока не могу выносить БД за пределы одной машины, а коллекция стала очень большой (более миллиарда записей). Поэтому ищу любые способы оптимизировать запросы, буду благодарен советам 🙏

Даже при свежей раскатке PBM, когда в БД admin ещё нет коллекций относящихся к перконе, он не должен выдавать ошибку подключения

no documents in collection это не ошибка подключения, это ошибка чтения конфигурации бэкапов pbm config это просто обёртка вокруг чтения admin.pbmConfig https://github.com/percona/percona-backup-mongodb/blob/dev/pbm/config/config.go#L485

Параметры шардирования там точно отключены?

{"t":{"$date":"2025-08-05T03:23:16.952+03:00"},"s":"I", "c":"REPL", "id":3873113, "ctx":"ReplCoordExtern-2","msg":"Cannot select sync source which is not ahead of me","attr":{"syncSourceCandidate":"rnd-eu-d b3.foo.com:27017","syncSourceCandidateLastAppliedOpTime":{"ts":{"$timestamp":{"t":1754353395,"i":25}},"t":4},"lastOpTimeFetched":{"ts":{"$timestamp":{"t":1754353396,"i":10}},"t":4}}} {"t":{"$date":"2025-08-05T03:23:17.962+03:00"},"s":"I", "c":"REPL", "id":3873113, "ctx":"ReplCoordExtern-2","msg":"Cannot select sync source which is not ahead of me","attr":{"syncSourceCandidate":"rnd-eu-d b3.foo.com:27017","syncSourceCandidateLastAppliedOpTime":{"ts":{"$timestamp":{"t":1754353395,"i":25}},"t":4},"lastOpTimeFetched":{"ts":{"$timestamp":{"t":1754353397,"i":18}},"t":4}}} {"t":{"$date":"2025-08-05T03:23:18.942+03:00"},"s":"E", "c":"ASSERT", "id":23077, "ctx":"ftdc","msg":"Assertion","attr":{"error":"BSONObjectTooLarge: BSONObj size: 22162576 (0x1522C90) is invalid. Size must be between 0 and 16793600(16MB) First element: start: new Date(1754353398000)","file":"src/mongo/bson/bsonobj.cpp","line":129}} "ctx":"ftdc","msg":"Assertion","attr":{"error":"BSONObjectTooLarge ключевой момент кто-то сталкивался с подобным? в гугле ток 1 страница про это, все что предлагают повысить уровень логироавния нужен вообще этот ftdc или мб его вырубить нафиг? что можно сделать?

Вот ваша ошибка: Size must be between 0 and 16793600(16MB) https://www.mongodb.com/docs/manual/reference/limits/#mongodb-limit-BSON-Document-Size

Привет, есть коллекция с документами такого вида: { "_id": ..., "characteristics":{ "foo": { "name_id": ObjectId(), "value_id": ObjectId(), }, "bar": ..., "baz": ... } } и бывают фильтр запросы по типу {$match: {"characteristics.foo.value_id": ObjectId()}} Записей полтора миллиона, без индекса такая фильтрация происходит несколько десятков секунд. Таких характеристик у обьектов много, поэтому вешать индекс на все не выглядит целесообразным решением. Есть ли какие то варианты, как можно ускорить поиск малыми жертвами?

гнать в эластик

поиск по всем измерениям херня конечно, а много это сколько?

Привет, есть коллекция с документами такого вида: { "_id": ..., "characteristics":{ "foo": { "name_id": ObjectId(), "value_id": ObjectId(), }, "bar": ..., "baz": ... } } и бывают фильтр запросы по типу {$match: {"characteristics.foo.value_id": ObjectId()}} Записей полтора миллиона, без индекса такая фильтрация происходит несколько десятков секунд. Таких характеристик у обьектов много, поэтому вешать индекс на все не выглядит целесообразным решением. Есть ли какие то варианты, как можно ускорить поиск малыми жертвами?

привет ребят вопрос! у меня есть каталог товаров и сами товары к товарам что лучше сделать Link чтобы был dbref? или просто ObjectID на айдишник каталога?

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