Search

[DB] 데이터 적재 및 문제 해결방법 (1)

순서
8
사람
상태
Done
태그
DB
날짜
2023/05/06
2023년 01월 7일
오늘은 실무에서 이야기 했던 내용들을 정리하려고한다.

[상황발생]

운영하는 웹사이트가 데이터가 4년동안 1개의 테이블에 1억개의 row를 적재하고 있다.
문제
1.
많은 데이터를 조회 하기때문에 부하 및 슬로우 커리 발생
2.
요청사항으로 1년치, 분기마다 데이터를 정제해서 엑셀로 다운받고 싶어함.
한달 데이터를 조회하는 것 조자 슬로우쿼리 + 부하가 발생하는데, 이를 어떻게 해결해야 할지 많은 고민을 했지만, 확실하게 해답을 찾지못하여, 다른 개발자와 회의를 진행하게됨.

[해결방법]

1.
RDBMS로 1억개를 조회해서 슬로우쿼리 부하가 발생하는것은, 샤딩, 파티션분할로 충분히 가능하다고 생각한다. 이를 하둡이나, 몽고DB로 변환하는 것은 닭잡는데 소잡는 칼을 사용하는 것과 같다.
2.
현재 ORM을 사용하는데, 조회하는 부분은 mybayis로 변경하고, DBA분과 인덱싱, 튜닝을 하는게 정답인것 같다.
3.
[일괄 데이터 처리]위에 언급한 테이블을 업데이트 할때마다 API를 전송해야되는데, 이를 일괄로 처리하고 있다. 일반유저를 대상으로 하는 웹사이트가 아니기때문에 쓰레드로 하는게 맞다고 생각하는데, 일반유저가 사용하는 부분이라면 비동기 방식으로 작업을 진행해야된다.

샤딩

파티션

[후기]

첫째로 든 생각은, 내가 좀 더 프로젝트의 환경과 소스를 잘 이해하고 있어야 된다고 생각했다. 서로 이야기를 진행하는데, 상대방이 물어 봤을 때 ‘원하는 대답을 해줄수 있었을까? ‘라는 생각을 하였다. 상대방은 궁금한 대답을 듣기위해 질문을 하는 것인데, 질문을 했을때 시원하게 대답을 못해 줄 것 같은 생각이 들었다. 좀 더 프로젝트의 환경과, 소스를 이해하는 부분이 필요하다.! 웹사이트의 환경, was, web 서버의 구조 등등에대한 지식이 많이 필요!
둘째, 경험이 많이 부족하다고 느꼇다. RDB의 문제인지, ORM의 문제인지 정확하게 파악하지 못했다는 것이다. 데이터가 많다고 RDB의 문제는 아니다. DBA와 이야기를 해보는 것도 하나의 좋은 해결 방법이될수 있다.
오늘은 처음으로 외부의 해박한 개발자와 회으를 진행하였는데, 아직도 배울것은 많고 해야될 것은 많다고 생각하였다. 더 열심히 해보자.!
2023년 3월 06일
오늘은 DB 메모리가 93%로 가득 찬 상황이 발생했다. 기존에 프로젝트를 만들 때 예상 수치보다 너무 높은 데이터가 유입되었고(한 달에 30만 건이 유입될 것을 기준으로 프로젝트를 진행), 하지만 평균적으로 하루에 30만 건 정도의 데이터가 유입되고, 삭제 정책도 마련되지 않았다. 때문에 데이터가 계속 쌓였고, 결국은 93%까지 차는 상황이 발생했다.
해결방법
1.
일단은 과거의 히스토리 데이터를 삭제하는 방법으로 메모리 여유를 만들고
2.
기획자 분들과 의견을 조율해서 삭제정책을 마련한다.
3.
삭제 정책에 따른 개발을 착수한다.
작업을 진행하면서 배웠던 점
1.
데이터를 delete하면 데이터가 증가할 것으로 기대했지만, delete문으로는 데이터가 증가되지 않는다. 이는 데이터가 직접 삭제되는 것이 아니라, 데이터를 삭제했다고 표기를 해두고 새로운 데이터가 들어왔을 때 표기한 데이터 위에 덮어씌우기가 되기 때문이다. 이를 해결하려면 얼터문과 테이블 재구성이 필요하다.
2.
파티셔닝을 하면 데이터를 삭제할 때 유리하다. 파티션 단위로 나누어 놓으면, 해당하는 파티션만 삭제하면 되기 때문이다. 파티셔닝을 하지 않고 데이터를 삭제할 때는, 얼터문을 작성해야하고, 테이블 재구성이 불가피하게 발생된다. 때문에 파티셔닝을 해야될 때에는, 삭제 정책과 보관해야하는 기간을 미리 알아두는 것이 유리하다.
3.
기획자와 이야기를 진행하였는데, 데이터를 유지하면서 (보관하는 방법)에 대해 이야기하였다. 하지만 계속되는 데이터 적재 문제로 DB 관련 부서에서는 삭제를 해야 한다는 쪽으로 이야기가 진행되면서 업무가 진행되지 않았다. 이를 해결하기 위해, 유의미한 데이터는 인덱스의 날짜를 변경하여 데이터를 올리고, 불필요한 데이터는 삭제하는 방식으로 파티셔닝을 나누는 방법을 선택하였다. 이렇게 하면 유지한 데이터는 최신 날짜로만 업데이트 되어 보관될 수 있으며, 불필요한 데이터는 삭제되면서 메모리 부족 문제 또한 해결할 수 있다.
파티셔닝 인덱스 → idx_createAt 때문에 불필요한 데이터는 그대로 유지, 필요한 데이터는 최신 날짜로 업데이트
이렇게 하게 되면 유지한 데이터는 최신 데이터와 별개로 파티셔닝이 분리되기 때문에 삭제하기가 편하게 된다.
현재 데이터
1
2021-02-01
유의미한 데이터
2
2021-02-02
불필요한 데이터
3
2021-02-03
유의미한 데이터
변경 데이터
1
2023-02-01
유의미한 데이터
2
2021-02-02
불필요한 데이터
3
2023-02-03
유의미한 데이터
불필요한 데이터와 유의미한 데이터가 파티셔닝으로 나뉘어져있으므로, 과거 데이터 파일을 삭제하기만 하면 된다. 이와 같은 작업을 java batch 로 계속 진행한다.
후기
오늘은 DB 메모리 적재 문제에 대해서 작성하게 되었다. 직접 작업을 진행하지 않았지만, 옆에서 회의 및 해결방법에 듣고 이해하는 것으로도, 다음에 발생하는 문제에 대해 미리 생각할 수 있었고, 차후에도 이러한 문제가 발생할 때 어떻게 대처하면 좋을지 배울 수 있어서 좋았던 것 같다.