- Склонируйте репозиторий, загрузите зависимости и создайте
.envфайл из шаблона:
git clone https://github.com/bleschunov/python_test_task.git
cd python_test_task
pdm sync
cat .env.template >> .env- В
.envзаполните переменные окружения.- В
POSTGRES_USERиPGUSERможно поставить одинаковые значения. - В
POSTGRES_HOSTнужно поставить postgres [название сервиса в docker-compose.yml], так как далее будет запускать в контейнере. DATA_FOLDER— это путь к папке/path/to/python_test_task/data.- В этой папке находятся XML файлы для обработки и данные для PostgreSQL.
- Это папка маунтится в контейнеры.
TARGET_FILENAME– это название XML внутри data для обработки сервисом.
- В
docker compose up postgres -d
docker compose run serviceПосле запуска вы увидите прогресс бар.
Tip
В /path/to/python_test_task/data лежит файл test.xml, состоящий из 5 <offer>. Файл удобно использовать для быстрого теста.
Tip
Важно запускать сервис через команду run, чтобы увидеть прогресс–бар.
- Положите ваш файл в
/path/to/python_test_task/data. - Укажите название вашего файла в
.envв переменнойTARGET_FILENAME. - Запустите сервис.
- Вы великолепны.
- Про I/O bound — это правда, потому что у нас из тяжёлых операций — это чтение XML и записи в БД. Однако не на всех платформах доступен асинхронный доступ к файловой системе.
- Можно было бы асинхронно скачивать XML чанками, а не читать из файловой системы синхронно. Тогда нужно будет решать проблему «разрыва» тега внутри одного чанка.
- Да, можно использовать несколько процессов.
- В этом решении будет один главный процесс, который будет парсить XML и для каждого тега
<offer>создавать джобы на выполнение. - Процессы из пула будут брать эти джобы и выполнять.
- Для экстремально больших файлов уместно будет использовать распределённую очередь, к которой будут обращаться несколько инстансов сервиса.
Выполните команду:
python -m unittest discoverПосчитал, что в решении не будет сложных SQL запросов, так что нет необходимости тащить тяжёлую зависимость. Достаточно ограничиться более низкоуровневой psycopg2.