qwertyv

사담데이터 파이프라인을 개선하기 위해 JPA에서 JDBC로 변환하면서DB 접근하는 기술에 대해서 맥락과 이해없이 기계적으로만 사용하고 있다는 것을 깨달았다. JDBC는 자바에서 DB를 다루는 근본이기 때문에 이해부터 해야겠다고 판단했다. JDBC배경- 과거에는 애플리케이션에서 DB에 접근하는 방식이 DB마다 달랐다.- DB가 변경되면 애플리케이션 로직도 변경되어야 했다.- 개발자는 DB마다 접근 기술을 학습해야 했다. 등장- 이를 해결하기 위해 JDBC가 등장했다.- JDBC는 자바에서 DB에 접근하는 표준 API이다. 해결- 애플리케이션은 JDBC 추상화에만 의존한다.- 개발자는 JDBC만 배우면 된다.- DB를 변경해도 로직을 수정할 필요없이, 구현 라이브러리만 변경하면 된다. 한계- DB마다 일부 ..

문제데이터 양이 늘어날수록 속도가 느려져, 인텔리제이 프로파일러 기능을 사용해서 스레드를 분석해보았다.가장 오래 걸릴 것이라 예상했던 api 호출작업이 가장 적은 시간이 걸리고, DB 삽입 작업에 어마어마한 시간을 쏟고 있었다. 문제 원인로그를 보니, 데이터 1개마다 DB 쿼리를 생성하고 날리고 있었다.이는 JPA의 saveAll()이 내부적으로는 Iterator를 돌며 save()를 호출하고 있어, 데이터 개별적으로 쿼리가 생성되었다. 해결JDBC는 배치처리를 지원하기 때문에, DB 접근 기술을 JDBC로 변경하였다.100개당 1개의 쿼리를 생성하고 DB 통신을 하게 바꾼 결과,1만 개당 1분에서 2분으로 속도가 개선되었다.

기존 : 데이터 개수별 비동기 처리 기존의 멀티스레드는 데이터 개수를 기준으로 나누었다.데이터를 100개마다 하나의 스레드를 할당해서 수집, 가공, 저장을 하게 했다. 문제1만 개당 30분이라는 긴 시간이 소요되었다. 문제 원인- 멀티스레드 비동기 구조를 의미없이 사용했다.- 하나의 스레드에서 I/O bound 작업과 CPU bound 작업이 섞여있다.- I/O bound 작업이 이루어지고 있을 때는 CPU가 놀면서 자원 낭비를 하게된다.- 앞 작업이 끝날 때까지 다음 작업이 기다려야 하니 결국 스레드 안에서 작업들끼리 blocking이 일어났다.개선 : 작업별 비동기 처리작업별로 스레드를 할당해서, 각 스레드는 맡은 작업만 한다.스레드는 비동기적으로 동시에 이루어진다.수집 스레드가 처리한 결과는 가공 ..

아이디어 1️⃣원본 테이블과 운영테이블(데이터 가공 테이블)로 분리하여 관리하기 도입 이유- 전처리 방식을 유연하게 변경할 수 있다. - 데이터 가공 시 오류가 발생해도 원본 데이터를 보존할 수 있다.  과정데이터 읽어오기 (API 데이터 호출 → 원본 테이블에 저장)데이터 가공하기 (원본 테이블 → 가공한 데이터를 운영 테이블에 저장)아이디어 2️⃣데이터 업데이트시, 해시값을 저장해서 데이터 변경 감지 도입 이유- 오직 변경만을 감지하기 위해 데이터를 파싱하여 저장할 필요가 없다.- 운영테이블에는 변경이 감지된 데이터만 저장하면 된다.- 업데이트 된 값만 변경하고 저장하여 속도를 개선할 수 있다.과정원본 테이블에는 원본 데이터(json), 해시, 변경 플래그 컬럼이 존재한다.해시만을 비교하여 달라진 레..