mayton2019

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

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

Поищи по ключевому слову upsert. Это типа insert + update.

Существует только одна рекомендация по безопасности в таком случае. Ты не должен хранить ключи,
токены, и пароли в исходнике самого приложения а ты должен его получать откуда-то из специального
сейфа (Vault).

API позволяет взять ключ по имени.

Каждый хостинг-провайдер или платформа предоставляет такой сейф как услугу. Например для Microsoft
Azure Cloud это Key Vault. Для облака Амазон это AWS Secrets Manager.

Технически - можно. Но MongoDb оптимизирована для хранения документов. И если вместо документов
туда складывать фильмы то может оказаться так что вы платите очень много за такие блобы которые
выгоднее держать на файловой системе или на сторедже. Привету пример. Если вы храните
документ в котором десяток текстовых полей и 11 поле - это блоб с фильмом длиной 1.5Гб то
получается что реально полезная для поиска и индексирования информация составляет
менее 1% (!) от общего размера БД. А все остальное - это балласт. Я как бывший базовик
привык что в таблицах БД лежит только полезная и нужная для SELECT ... WHERE информация.
Если эта информация не полезна для поиска - то ей не место в БД.

Хуже того что эти блобы будут вовлечены в процесс планового бэкапа. Даже если они не изменялись.
Может возникнуть кейс когда скопировать БД все таки надо. А копировать тяжело. БД уже превысила
пета-байт просто потому что кто-то захотел фильмы хранить рядом с данными.

Я не специалист конкретно по Монге но вот тут пишут о реализациях хранения блобов https://www.mongodb.com/developer/products/mongodb...

Почитайте.

Никто не захочет разбираться с твоими ботами.
Если ты пишешь что проблема в Монго - то вот бери 100% рабочий пример

https://www.mongodb.com/languages/python

Там 4 строчки которые демонстрируют создание коннекта получение БД и вставку документа.

Деплой 4 строчки на replit и доказывай что они не работают. Все остальное что ты привел - это рандомный
шум который мешает пониманию главной причины. Root cause.

Вот ответ https://stackoverflow.com/questions/32582244/how-t...

Возможно у UI есть ограничения. Посмотри вот другая утилита есть https://www.mongodb.com/docs/database-tools/mongoi...

Перетащил это всё на MongoDB с такой структурой:

Справочники остались в MySQL.
.......
Какие есть идеи?

Думаю попробовать перенести структуру на PostgreSQL аналогично MongoDB и использовать

Дружище. Так жеж не делается в мире Документно-ориентированных БД! В монге ты делаешь не таблицы. А хранилища документов. Где каждый документ - самодостаточен и полностью хранит в себе всю информацию. Грубо говоря никаких СПРАВОЧНИКОВ и СВЯЗНЫХ таблиц у тебя быть не должно. И нельзя джойнить документы. И нельзя джойнить документы с таблицами MySQL.

Почитай про модель АГРЕГАТОВ в противовес реляционной модели. Это можно найти в книжках типа NoSQL и еще я находил это в доках по Cassandra.

Можно посмотреть стандартный туториал по Spring+Mongo https://spring.io/projects/spring-data-mongodb

Почти все гео-поисковые системы для хранения геометрии используют либо quad-tree либо R-tree. К чему здесь Mongo - вообще непонятно. Это бд другого типа. Для документов.

Бери деревья и используй. Мало памяти - ну решай это быстрыми дисками или просто покупай больше узлов для параллельных поисков.

Обсуждение типа в mongodb имеет смысл только в том случае если ты будешь индексировать эти фрагменты или делать с ними какие-то операции поиска. В остальных случаях (когда Mongo используется просто как хранилище строк) - храни как строки.