Data / Infrastructure: Оновлення даних з ISB

[ndrhzn]

Задокументую тут проблему, повʼязану з використанням даних ISB

• Наразі ми синхронізуємо базу даних BI з API DREAM раз на добу. Ми дивимось, які проєкти, обʼєкти, і т.д. були оновлені за останню добу, і підтягуємо оновлення. Це так зване інкрементальне оновлення. Іноді ми також робимо повне перезавантаження бази, але це ad hoc задача, вона у нас наразі не автоматизована (тобто, не привʼязана до якогось розкладу).

• Для даних ISB у нас відсутні будь-які сигнали щодо того, чи оновились там дані чи ні. Умовно, ми зараз взяли в даних проєкту код завдання на проєктування. Пішли з цим кодом в API ISB.

Уявімо, що на момент запиту в даних ISB ще не було жодної інформації щодо ПД, тому ми собі не підтягнули в базу даних нічого. Або ж там була інформація за кодом завдання на проєктування, ми бачимо, що вже є ПД, однак ще нема затвердження чи експертизи.

Наступного дня чи тижня ця інформація в даних ISB може зʼявитись, однак ми не дізнаємось про це допоки проактивно не звернемось з кодом завдання на проєктування до до ISB повторно

Які в нас можуть бути опції:

• Звертатися до ISB щодоби. Це може створювати зайве навантаження на АРІ. І в реальності ми не очікуємо, що за всіма нашими запитами оновлення будуть щодоби.
• Робити повне перезавантаження бази даних щотижня. В такому разі ми приймаємо факт, що дані щодо ПКД можуть оновлюватися з затримкою, однак принаймні у нас буде передбачуваний спосіб оновлення даних

[andrzejbeletsky]

FYI.

Наразі завантаження даних з різних поінтів таке:

сутність	тип завантаження	звідки
budgetsubmissions	incremental	https://public-api.dream.gov.ua/marketplace/public/dream/budgetsubmissions
companies	incremental	https://public-api.dream.gov.ua/marketplace/public/companies
ifiprojects	incremental	https://public-api.dream.gov.ua/marketplace/public/dream/ifiprojects
investmentprojects	incremental	https://public-api.dream.gov.ua/marketplace/public/dream/investmentprojects
objects	incremental	https://public-api.dream.gov.ua/marketplace/public/dream/objects
prequalifications	incremental	https://public-api.dream.gov.ua/marketplace/public/dream/prequalifications
projects	incremental	https://public-api.dream.gov.ua/marketplace/public/dream/ideas
submissions	incremental	https://public-api.dream.gov.ua/marketplace/public/dream/submissions
budgetProgramKVK	full	https://public-isb.dream.gov.ua/isb/openbudget/classifiers/KVK?code=
related_invest	full	https://public-api.dream.gov.ua/marketplace/public/dream/investmentprojects/project_id/projects
classifications	not exist	https://standards.dream.gov.ua/classifications/schema:id
contracts	not exist	https://public-isb.dream.gov.ua/isb/contracts
design_documentation	not exist	https://public-isb.dream.gov.ua/isb/e-construction/design-documentation?design-task-code=
tenders	not exist	https://public-api.prozorro.gov.ua/api/2.5/tenders

incremental - поінт має властивість updated, тому маємо змогу робити інкрементальне завантаження

full - поінт не має властивості updated, тому повне завантаження необхідних даних

not exist - поінт не має властивості updated, тому завантаження необхідних даних , якщо раніше вони не завантажувались. цей варіант може бути хибним, якщо наповнення даних змінилось.

[ndrhzn]

Дякую, @andrzejbeletsky, це дуже корисно!

Чи правильно я розумію, що коли ми робимо full reload, тоді це заторкає і ті ендпойнти, для котрих тип завантаження = not exist? Тобто, скрипт повторно звернеться за всіма посиланнями?

[ndrhzn]

І також чи можна налаштовувати окремо оновлення для цих ендопйнтів? Умовно, чи може бути варіант, за якого скрипт звертається до design_documentation кожні N днів?

[andrzejbeletsky]

Наразі усі ендпоінти завантажуються кожен день, але для кожного при необхідності можна окремий розклад. Різниця між full і not exist тільки в тому, що для full це безумовне завантаження, тобто навіть якщо є файли від попереднього завантаження, вони ігноруються і перетираються. not exist - маємо перелік елементів для завантаження, але реально з апі запрошуємо тільки такі, які не мають файлів від попереднього завантаження.