deepblack

Что значит "как"? Ответь на вопрос: как получить все файлы, связанные с моделью? Вот теперь оформи это в метод модели

def get_all_my_files(self) -> list[str]:
    result = []
    result.extend(get_from_here())
    result.extend(and_from_there())
    return result

И повесь на pre_delete сигнал получение файлов, а потом удаление

Этот вопрос стоит задать поддержке Сбера.

Странный вопрос.
На собеседовании все уместно. Ты же не забывай, что собеседование это не ЕГЕ.
Это диалог двух сторон. Если кандидату не понравился вопрос, он может встать и уйти.
Если он не знает ответ, он может что-то насочинять, и если ты грамотный специалист ты увидишь что он тут отгадывает или точно знает.

У меня для собеседований есть небольшой опросник, в котором чуть ли не каждый второй вопрос идет с небольшим подвохом, и по полноте ответов я понимаю насколько глубоко кандидат шарит. Но мне не всегда необходимо найти того, кто ответит на все 100% вопросов развернуто.
Я просто оцениваю что кандидат знает, а с чем сталкивался настолько регулярно что прям помнит наизусть детали без мануала.

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

Присоединюсь.
Разработчики забросили поддержку youtube-dl и гугл довольно оперативно заблочил нормальную скорость его работы (намеренно, либо ютуб просто "развивается", и парралельно поломал работу утилиты).

Сейчас активно развивается форк yt-dlp, у которого и скорость скачивания на уровне, и в дальнейшем его пока еще не забрасывают.
Так, как это форк, то обратная совместимость полная. Меняете youtube-dl на yt-dlp и все работает.

На своем сайте можно самостоятельно собирать по логам базу рефереров, придется самостоятельно же ее анализировать

Читать учебник.

Стандартный прод сейчас выглядит так: кластер серверов, поверх которых натянуто облако, в котором запускаются контейнеры. Конечный продукт, соответственно, работает как и в любом гугловском облаке - тупо запускается. Остальное - не ваши проблемы.

p.s.
Хотя с другой стороны очень часто встречаются бородатые дядки, которые, разумеется на Windows 10 Enterprise edition, запускают виртуалку WMVare Workstation, в которую устанавливают докер, в котором запускают ваш контейнер. Но это уже их проблемы, что всё через одно место сделано.

Систему мониторинга нужно выносить на отдельную железку. Иначе, если упадет основной сервер, на котором, собственно, и живет мониторинг, то вы об этом не узнаете.
А на счет того, что использовать, я топлю за Prometheus - простой в установке и настройке, уведомления в телеграм, слак, почту и т.д. Графана + прометеус = любовь.

Я использую связку grafana + influxdb + (telegraf/collectd).
1) не нужно практически ничего настраивать, ну кроме самих графиков и url подключание я influxdb
2) все ставится за 15 минут, с раскомментированием нужных модулей в конфигах.
3) в telegraf полно плагинов для сбора статистики с практически любого ПО, в collectd также.
4) если нужны оповещения ставлю kapacitor из то-го же стека. вот с ним нужно немного повозиться, чтобы слал что и куда нужно.
5) да, все можно запустить в контейнерах
Мониторю кластер из порядка 40 вычислительных серверов и хранилище CEPH.

1)https://habr.com/ru/post/575460/
2)Делаете по инструкции и повторяете запросы
3) PROFIT

Конечно может, вопрос в железе. И микроскопом можно забить гвоздь.
Но на слова "хочу быстро вставлять и быстро читать потоком" так и хочется ответить "а зачем тебе БД?"

Поэтому хотелось бы уточнить у автора: а вот кроме описанного "вставить миллион, считать миллион" - что предполагается делать с данными? Менять их построчно? Искать по какому-то ключу? это все надо? Если нет - я бы все же рекомендовал не использовать БД.

Тут следует понимать что любая нормальная БД это [почти] всегда двойная запись на диск: вы пишите в таблицу И в лог базы данных. Именно поэтому файл или Kafka или иной MQ будет всегда быстрее.

Ну а если БД все равно нужно - ну тогда BULK режимы вам в помощь. Обычно они используются для пакетной инициализирующей загрузки. В некоторых БД они на время своей работы могут отключать какие-то фичи или даже логирование в лог транзакций.
----------------------------
Вообще по всем признакам в вашем случае идеальным будет вариант писать в MQ (RabbitMQ или Kafka или см аналоги), а уже из нее в БД. "Все так делают", по крайней мере в крупных компаниях это довольно типовое решение для подобных вашей задач. Причем БД в этой истории нужна только если вам потом нужно хранить и селектить. Если после первой операции данные вам более не нужны, либо нужен только бэкап, то БД не нужна - пишите в файл, пакуйте в zip (в энтерпрайзе - кидайте файлы в Hadoop в каком нибудь Parquet формате).