В .env.example - находится конфиг по умолчанию для docker
- cp .env.example .env
- docker-compose up -d
- Не очевидные моменты есть в комментариях
- Если дернуть update, произойдет синхронизация, а далее еще раз дернуть update, то старые записи у нас сохраняться (возможно так и надо)
- Считается, что uid приходит числовой и помещается в bigint, а firstName и lastName поместяться в varchar(300). (Это поведение легко изменить)
- При работе я столкнулся с проблемой, что подключение с сервером https://www.treasury.gov устанавливается относительно медленно(Данная проблема может быть только у меня, тем не менее я опишу, как бы я ее решил + далее поможет решить еще один кейс). Мы можем при парсинге скачивать этот фаил(в s3, или на локальную машину, смотря где запускать) в отдельной горутине. Либо, если содержимое изменяется относительно редко(По хедерам etag и last_modified это можно определять), то отдельной задачей с некоторым таймаутом проверять не изменился ли фаил, если изменился, скачивать его на локальную машину. И парсинг будет выполняться быстрее, за счет того что будет читать с локального файла/s3, к которой доступ будет быстрее. Таким образом, это поможет помочь и при повтором update. Во-первых, мы можем проверять, что если etag и last_modified не изменились, то при повтором запросе update, пропускать парсинг. Но при таком варианте, нужно убедится, что данные все синхронизировались корректно. (В решений, которое я представил допустимы ошибки бд, которые логируются, но не прерывают работу парсера. В комментариях в коде я указал где именно. Это не сделано, так как в данном случае продумать, что делать с уже синхронизированными данными. Удалять/добавить поля, где указана актаульность.). Во-вторых, при повторном update, сохраненный фаил, также ускорит повторный парсинг.
Замечение: Данное решение подойдет, если мы доверяем заголовкам(что чаще всего правильно, но не всегда + заголовки могут изменится)
- Если первый вариант по каким-то причинам не подходит. При этом допустима погрешность в 1-2 минуты(я беру размеры файла соизмеримые с примером). То можно делать тоже самое, что в пункте 1, но опираться не на хедеры. А предварительно скачивать фаил, считать sha сумму. Если она не изменилась и приходит повторный запрос - не обновляем данные.
- (Поможет, если в xml будут часто добавляться данные). Кешировать id, которые есть в бд и новые данные сохранять в батч для multi insert(). В таком случае можно будет убрать ON CONFICT UPDATE и updateOrInsert (Заменить на просто INSERT и UPDATE)
- Взять блог sdnEntry для конкретно uid. Хешировать его и записывать в кеш. Убедится, что данная запись сохранилась в бд. (в кеше хранить следующие значения uid, hash, status, last_check_at. До записи status=wail, после ok) При парсинге, если хеш блока старый, не обновлять запись(то есть не делаем запрос в бд). Если появляется слишком много значений, вытесняем по last_check_at(Уверен есть лучшие решения с таким подходом. Как именно вытеснять, оправдывается на практике)