Django - Как хранить все запросы/ответы с наименьшими накладными расходами?
Я работаю над промежуточным ПО Django для хранения всех запросов/ответов в моей основной базе данных (Postgres / SQLite). Но нетрудно догадаться, что накладные расходы будут сумасшедшими, поэтому я думаю использовать Redis для постановки запросов в очередь на определенное время, а затем медленно отправлять их в мою базу данных. Например, получаем 100 запросов, храним их в базе данных, ждем получения еще 100 запросов и делаем то же самое, или что-то вроде этого.
Мои вопросы: "хороший ли это подход? и как мы можем его реализовать? есть ли у вас какой-нибудь пример, который делает подобное?". И другой вопрос - "есть ли лучшее решение?"
Это не очень подходит для конкретного формата вопрос/ответ, к сожалению.
На вопрос"Хороший ли это подход" трудно ответить прямо "да" или "нет". Он будет работать и предложенная вами реализация выглядит разумной, но вы внедрите довольно много программного обеспечения и добавите довольно много сложности в ваш проект.
На вопрос, желательно ли это, нелегко ответить без контекста, который есть только у вас.
На некоторые вопросы вы захотите ответить:
- Что я делаю с этими сохраненными запросами? Отладка? Обеспечение аудиторского следа?
- Если для отладки, то что дает нам запись в базе данных, чего не дают журналы запросов нашего веб-сервера?
- Если это для аудиторского следа, является ли каждый отдельный HTTP-запрос лучшим представлением этого аудиторского следа? Интересует ли аудитора, что кто-то запросил
/favicon.ico? Передает ли он смысл и контекст, который им нужен?
Нужно ли хранить каждый запрос? В течение какого времени? Как мы справимся с превышением бюджета на хранение? Как мы будем действовать в таких крайних случаях, как клиент зависает до получения ответа, или мы обработали запрос, но потерпели крах до отправки ответа или регистрации записи?
- Представляет ли регистрация запроса в группе с самим запросом затраты на производительность, которые мы не можем себе позволить?
-
Сравните сильные и слабые стороны вашего подхода с некоторыми альтернативами:
- Мы можем полагаться на журналы веб-сервера, за которые мы уже платим деньги и которые созданы для обработки многих странных случаев здесь.
- Мы можем написать модель HTTPLog в группе с запросом с помощью простой промежуточной функции, что решает некоторые сложности типа "что если redis не работает, а django и база данных не работают?" .
- Мы пишем систему регистрации аудита, предоставляя любой необходимый контекст внеполосному процессу (возможно, через сигналы или redis+celery)
Прежде всего: сначала зафиксируйте ваши фактические требования, затем реализуйте самое простое решение, которое работает, и оптимизируйте только после того, как вы действительно увидите проблемы с производительностью.
Я бы не стал размещать эту функциональность в своем Django-приложении. Есть много инструментов для этого. Одним из них является NGINX, который представляет собой обратный прокси-сервер, который вы можете поставить перед Django. Затем вы можете использовать журнал доступа из NGINX. Также вы можете форматировать эти журналы в соответствии с вашими потребностями. Обычно для такого большого количества данных лучше не хранить их в базе данных, потому что эти данные будут использоваться редко. Вы можете хранить их в ведре S3 или просто в обычных файлах и использовать инструмент для разбора журналов.