parsing 후 저장시 데이터 중복 문제

 

1. 스팀api의 appList를 받아서 파싱후 내db 에 저장하는 기능을 만듬

2. 정상 작동 확인

3. 블로그에 기록 후 잠듬

4. 다음날 파싱기능 수행 전에 테이블 row를 다 날리는 기능을 만듬

5. 정상 작동 확인

6. 어제 만든 파싱,저장 기능 불능 확인 (저장기능이 안되는거였다)

7. executeBatch() 기능에 addbatch 가 약15만5천번 수행 된다는것 확인

(총13MB 용량.. 15만개의 요청..)>> (27만개 였다)

DB의 제한설정을 늘린다 or 요청을 나눠서 수행 한다

8. executeBatch 분할 실행

9. Duplicate entry '736800' for key 'PRIMARY' 에러

10. 분할 후 나머지 쿼리 실행에서 기존의 데이터를 다시 insert해서 난 오류였다

11. 8번 과정 정상작동 확인

12. 의문 해결

 

 

내DB 는 aws ec2 클라우드에 있다 성능,트레픽 설정이 매우 적게 할당 되어있는 무료 서비스이고

지금 할당된 자원을 넘어서는 트레픽은 내 실수로 넘어서는것 말고는 없을것같아서

executeBatch 를 나눠서 요청 하기로 했다

for문이 끝난후 요청하는것이 아니고 끝나기 전에 요청 해야 한다

maxNum,count로 반복문 돌리는 부분을 투박하지않게 만들고 싶다

 

결론 : 

기존의 row를 싹 날리는기능은 정상이였다

처음에는 27만 쿼리가 30초 안에 요청 되는것이 무리가있어 DB가 커넥션을 끊은것이고

나중에는 내가 batch를 나눈후 나머지batch를 잘못 요청하여 1만개씩 보냈던 요청이 마지막에 한번더 요청 되면서

PK중복(app_id)이 뜬것이다

 

안그래도 aws서버가 프리티어라 appList갱신에 부담이 있었는데

다행히 DB 제한설정을 건들이지 않아도 돼서 다행이다

 

 

 

이상한건

15만개 의 executeBatch 와 나머지 7088개

총 15만7088개의 쿼리가 요청 되었지만

mysql 워크밴치에는

27만 개의 row 가 있다고 적혀있다

쿼리로 row 의 갯수를 새더라도 Table rows 값과 똑같이 나올것이고..

파싱 하기전 table을 완벽하게 날리는것은 확실하다

 

원인을 찾을시 업데이트 예정.. >> 원인 발견

 

+원인 추가 2023/03/24

 

처음 테이블을 싹 날리는것은 정상이였고

파싱후 DB 저장할때 잘못 저장 되는 문제가 있었는데

그때 문제가 어디서 일어나는지 알기위해

 

appList 를 갱신 하는 기능을

테이블삭제 , 파싱후저장 으로 구현부를 나뉘었었다

삭제 메서드 구현후 저장 메서드를 구현 할때

저장 메서드가 온전히 만들어지기 전이였고

일부의 데이터가 n번 저장 되었다

그 상태에서 저장 메서드를 완성후

바로 DB info를 체크하니 27만개가 쌓여있게 되었다

 

간단 하게 설명 하면

구현부를 목적 별로 나누어 구현 하고 있었기때문에

기능부가 전체 실행 되기전에 발견될수있는 상황이었다

완성한 기능을 한번돌려주기만 하면 깔끔하게 없어지는 문제다

 

test case를 짜고 롤백을 시키는 방법을 사용 했으면

무신경하게 만들어도 피할수 있는 문제 였다