오늘 여러 분들의 도움으로 결론에 도달 했습니다.
api 속도가 느리면 캐시로는 어떠한 방법을 써도 누군가 한명은 느린속도로 접속하게 됩니다.
그래서 고심 끝에 결론을 내렸는데요.
먼저 api 받아온 데이터를 수치화 시켜서 db에 저장 시킵니다.
그럼 db에 저장되는 순간에 접속한 사람은 에러가 나지 않냐? 생각이 들었습니다.
db에 데이터를 저장되는 시간을 피해서 캐시기능을 넣어주면
완벽하게 지연 없는 서비스가 완성 될것 같습니다.
결론. 1차 적으로 DB에 데이터를 넣고
DB에 있는 데이터를 불러온 페이지에 캐시 기능을 넣으면 완벽하겠네요!!
테이블에 칼럼을 추가하고 그 칼럼에 새로운 데이터를 덮어 쓰는 방식으로 만들어볼까 해서요. 그래서 데이터가 덮어씌워지는 순간 잠시의 찰나에는 접속이 안되는 증상이 있지 않을까 하는 노파심이 들어서요.
반대로 15일이 지난 행을 지우는 방법도 생각해봤는데 뭔가 앞의방식이 심플할것 같아요.
https://inpa.tistory.com/entry/MYSQL-%F0%9F%93%9A-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98Transaction-%EC%9D%B4%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC
트랜잭션을 사용해보세요
데이터를 삭제하고, 새롭게 넣는 작업을 하나의 단위(트랜잭션)로 묶으시고
커밋을 하시면 "찰나의 순간" 없이 바로 데이터가 적용됩니다.
라이믹스에서는 트랜잭션 기능을 잘 제공하고있는데, 처음 들으면 어려운 개념이기는 해서..
BEGIN
데이터 삭제
새로운 데이터 삽입
COMMIT
하시면 우선은 중간에 데이터가 없어서 오류나는 일은 없다고 보시면 됩니다.
If) 데이터 삭제하고, 새로운 데이터를 삽입하기 전에 혹여나 다른 사람이 들어온다면 서비스가 안되는거 아닌가요?
트랜잭션 단위가 끝나기 전, 즉 commit 되기 전에는 실제로 데이터가 삭제, 수정되는게 아니라 "이론상 수정"만 된다고 보시면 됩니다. (정확히는 해당 DB를 조작하고 있는 세션에서만 데이터 변경된게 보인다 보시면 됩니다)
따라서 다른 사용자는 데이터 삭제하기 전의 예전 데이터를 그대로 불러올 것이고, 서비스는 정상 작동한다는 의미입니다.
그리고 COMMIT을 한다면 데이터는 실제로 교체가 일어나게 되고, 그 후부터는 다른 사용자도 새로운 데이터를 읽게 됩니다.
즉 트랜잭션을 잘 활용하신다면 말씀하시는 "찰나의 순간"은 발생하지 않습니다.
와 트랜잭션에 대해 설명해주신 덕분에 트랜잭션으로 db화에 성공했습니다.(캐시도 필요없겠네요)
타임스탬프값으로 중복되는 행에 잘 덮어씌워지고
db로 접속하니 정말 속도가 0.0001초만에 팍팍뜨니 속이다 후련하네요 ㅎㅎ
그나저나 유료로 결제한 날씨 API 인데 뭐가 뻥 날씨 느낌이 엄청강하네요.. ㅠㅠ
DB에 저장하는 순간 에러가 왜 나지요? "순간"이 아니라 일단 삭제해 놓고 한참 있다가 다시 넣어주나요?