[feature/server2] 크롤링, API 자동화 최적화

[solyourock]

Issue

• 현재 크롤링, API는 작업 마친 후 csv 파일로 저장되는 매커니즘으로 코드가 짜여져 있지만, csv 파일로 저장 하지 않고 바로 데이터베이스화 시켜서 그것을 가져와서 camping DB를 만드는 작업을 하는 방향에 대한 논의 필요

[SeyoungKo]

07.13 혼잡도 API 자동화 완료

• 과거 방문객 수
• 미래 예측 수

[solyourock]

이슈 사항 (as of 16 July)

• 관광지 API와 고캠핑 API, 고캠핑 크롤링을 축제 API와 같이 가져오지 않을 경우 기존에 있던 데이터베이스에서 관광지 API와 고캠핑 API, 고캠핑 크롤링 내용을 가져와서 place 테이블을 만들어야 하는 어려움이 있음

이슈 해결책 (as of 16 July)

• 관광지 API에서 'createdtime' 컬럼을 추가로 가져와서 지난번 업데이트 날짜 후에 새로 추가한 정보만 가져와서 기존 테이블에 append하는 방법이 있음 -> 자동화 주기를 알아야 함

[SeyoungKo]

이슈 해결책 (as of 16 July)

• 관광지 API에서 'createdtime' 컬럼을 추가로 가져와서 지난번 업데이트 날짜 후에 새로 추가한 정보만 가져와서 기존 테이블에 append하는 방법이 있음 -> 자동화 주기를 알아야 함

고캠핑 API - 리뷰 크롤링 자동화를 함께 수행하고 축제 API는 별도의 주기에 따라 수행하는게 좋을 듯 한데, @solyourock 님의 의견이 궁금합니다. 축제 API는 특별한 이슈가 없으면 7일 단위로 설정하는게 좋을 것 같습니다.

---

추가 요청 사항 (07.17)

1. 축제 API 요청 자동화 수행 전 현재일 기준 종료된 축제 데이터 row drop (datetime.now(), event_end_date 비교)

[solyourock]

이슈 해결책 (as of 16 July)

• 관광지 API에서 'createdtime' 컬럼을 추가로 가져와서 지난번 업데이트 날짜 후에 새로 추가한 정보만 가져와서 기존 테이블에 append하는 방법이 있음 -> 자동화 주기를 알아야 함

고캠핑 API - 리뷰 크롤링 자동화를 함께 수행하고 축제 API는 별도의 주기에 따라 수행하는게 좋을 듯 한데, @solyourock 님의 의견이 궁금합니다. 축제 API는 특별한 이슈가 없으면 7일 단위로 설정하는게 좋을 것 같습니다.

• 고캠핑 API , 고캠핑 크롤링, 네이버+카카오 리뷰 크롤링 자동화 함께 수행 (기존 주기인 주 2회)
• 축제 API 14일 단위
• 관광지 API 7일 단위

자동화 수행 어떨지 제안 드립니다.

[SeyoungKo]

축제보다 관광지 데이터 자동화 주기가 짧은 이유가 있을까요? 관광지 API 요청 자동화의 경우 약 9000건의 관광지를 새로 재수집하는건가요?

[solyourock]

축제보다 관광지 데이터 자동화 주기가 짧은 이유가 있을까요?

-> 7월 17일 기준 관광지 데이터 약 한달간 약 100개의 정보가 새로 추가된 것을 확인하였습니다. 생각보다 자주 업데이트 되는 것 같아서 관광지의 자동화 주기를 짧게 설정하였습니다. (7월 17일 기준 관광지 API 총 9532 로우). 축제는 생각보다 업데이트 되는 양이 적고 보통 축제 시작 약 한달전에 등록되는 경우가 많아보여서 그랬습니다. (6월 기준 총 8로우 업데이트)

관광지 API 요청 자동화의 경우 약 9000건의 관광지를 새로 재수집하는건가요?

-> 앞서 언급한 이슈 해결책에 있듯이 관광지 API에서 'createdtime' 컬럼을 추가로 가져와서 대조하여서 append하는 방식으로 진행하면 어떨까 싶습니다!

[solyourock]

자동화 주기

• 고캠핑 API , 고캠핑 크롤링, 네이버+카카오 리뷰 크롤링 자동화 함께 수행 -> 7일 단위
• 축제, 관광지 API -> 14일 단위

관광지 API 관련 이슈

• 'createdtime'을 대조해서 새롭게 업데이트된 정보만 가져와서 append하는 방식

[solyourock]

추가 요청 사항 (07.17)

축제 API 요청 자동화 수행 전 현재일 기준 종료된 축제 데이터 row drop (datetime.now(), event_end_date 비교)

자동화 수행 일에 맞춰서 지난 축제 이벤트 데이터 삭제를 한 후에 업데이트 작업을 수행하려고 했으나 이렇게 되면 축제 정보가 있는 place 테이블 (부모 테이블)의 제한키 설정을 모두 다 풀고 다시 설정을 해줘야하는 번거로움이 있습니다. 데이터가 쌓인다고 해도 그렇게 많지는 않을 거 같아서 우선 그냥 두는 것이 어떠한지 의견 여쭤봅니다!

[SeyoungKo]

추가 요청 사항 (07.17)

축제 API 요청 자동화 수행 전 현재일 기준 종료된 축제 데이터 row drop (datetime.now(), event_end_date 비교)

자동화 수행 일에 맞춰서 지난 축제 이벤트 데이터 삭제를 한 후에 업데이트 작업을 수행하려고 했으나 이렇게 되면 축제 정보가 있는 place 테이블 (부모 테이블)의 제한키 설정을 모두 다 풀고 다시 설정을 해줘야하는 번거로움이 있습니다. 데이터가 쌓인다고 해도 그렇게 많지는 않을 거 같아서 우선 그냥 두는 것이 어떠한지 의견 여쭤봅니다!

말씀해주신 방향으로 우선 진행하겠지만, 제한키 설정을 풀고 다시 설정을 해주기만 한다면 이 방법도 가능한 것인가요? 추후 작업에 참고하고자 미리 여쭈어봅니다.

[solyourock]

말씀해주신 방향으로 우선 진행하겠지만, 제한키 설정을 풀고 다시 설정을 해주기만 한다면 이 방법도 가능한 것인가요? 추후 작업에 참고하고자 미리 여쭈어봅니다.

제한키 설정들의 문제는 해결할 수 있을거 같은데 문제는 지난 축제들의 데이터를 지우려면 DELETE FROM 쿼리 이용해야하는데 이러면 하나하나 대조를 해가면서 지워야해서 쿼리 연산량이 늘어나는지 gcp가 뻑나가는 현상이 자꾸 일어납니다 . 그래서 다른 방법이 있지 않을까해서 계속 찾아보는 중입니다. 우선 축제API도 생성순으로 가져올수 있어서 자동화 날짜 기준으로 업데이트된 것으로만 가져오게 해두긴 했습니다. 제 생각에 축제 데이터는 그렇게 많이 쌓일거 같진 않아서 그냥 업데이트 순으로 가져오고 쌓이도록 두어도 괜찮을거 같긴한데 방법을 조금 더 찾아보도록 하겠습니다!

[SeyoungKo]

넵 답변감사합니다.