1. 상황(or 요구사항)
엑셀 데이터를 배치 처리하여 DB에 업로드하는 과정에서, 엑셀 파일 내에 이미 DB에 있는 데이터가 있을 경우, 중복해서 데이터를 입력하지 않기 위한 방법이 필요했다. 시도해 본 방법 중 주어진 상황에 가장 효율적으로 보이는 것이 Upsert 기법이었다. 이제부터 소개해보도록 하자.
2. 접근법
1) DB 제약사항 설정
첫번째 방법은 필요한 데이터베이스에 Unique 제약사항을 추가하는 것이다.(Upsert에서도 필요한 기법이라고 생각한다.)
장점
- DB 정합성이 보장된다.
단점
- 여러 데이터를 한번에 올리는 쿼리를 수행할 수 없다.(데이터 중 중복값이 있을 경우 예외를 던지기 때문에)
2) 서버 체크 - 레코드 단위
첫번째 방법은 서버에 예외를 던지기 때문에 Row Data를 개별 업로드를 해서 중복 예외처리를 해주는 방법으로 처리해야 한다. 이 방법을 개선하기 위해 엑셀파일의 데이터를 파싱한 Row 단위로 체킹 로직을 개발했다. Sheet의 Row Data 만큼 반복문을 돌리는 과정에서, Unique하게 잡은 컬럼 값들을 기준으로 DB 레코드를 불러와서 엑셀 파일에서 불러온 Row 데이터의 Unique 컬럼 값과 확인하는 과정이다.
장점
- 코드가 직관적이다.
단점
- 첫번째 방법과 동일한 메커니즘으로 매 컬럼마다의 쿼리 과정에서는 Select 쿼리 자체 코스트보다 DB 커넥션을 열고 닫는 매 과정의 오버헤드가 더 크다. Redundancy가 RawData 개수에 비례하여 증가한다.
- DB에서 제약사항이 설정되지 않은 경우, 조건 설정이 되어 있지 않은 프로그램의 DB접근에 의해 데이터 정합성이 깨질 수 있다.
pseudocode
//수도코드
for row_data from sheet:
record_from_db = get_data_from_db(u_column1, ...);
is_same_data = compare(row_data, record_from_db);
if(is_same_data) continue;
else push_to_db(row_data);
적은 수의 데이터를 처리할 때는 직관성 측면이나 개발 난이도 측면에서 매우 간단하지만, 데이터가 많은 상황에서는 사용하기 어려운 접근법이라고 생각한다.
위 코드의 개선점 및 upsert기법, JPA 코드구현은 다음 포스팅에 남기겠다.
'Computer Science > 데이터베이스' 카테고리의 다른 글
[Mysql] DB 성능 최적화 - 1. Explain이란? (1) | 2025.01.20 |
---|---|
[MariaDB] 데이터 타입 종류 정리해서 보자! (0) | 2023.07.28 |
Transaction이란? - 1 (정의, 특징-ACID) (0) | 2023.05.02 |
[SQL, MariaDB] 한 테이블의 특정 컬럼에 있는 값이 다른 컬럼에 없는 레코드 탐색. (0) | 2023.03.14 |
1. 상황(or 요구사항)
엑셀 데이터를 배치 처리하여 DB에 업로드하는 과정에서, 엑셀 파일 내에 이미 DB에 있는 데이터가 있을 경우, 중복해서 데이터를 입력하지 않기 위한 방법이 필요했다. 시도해 본 방법 중 주어진 상황에 가장 효율적으로 보이는 것이 Upsert 기법이었다. 이제부터 소개해보도록 하자.
2. 접근법
1) DB 제약사항 설정
첫번째 방법은 필요한 데이터베이스에 Unique 제약사항을 추가하는 것이다.(Upsert에서도 필요한 기법이라고 생각한다.)
장점
- DB 정합성이 보장된다.
단점
- 여러 데이터를 한번에 올리는 쿼리를 수행할 수 없다.(데이터 중 중복값이 있을 경우 예외를 던지기 때문에)
2) 서버 체크 - 레코드 단위
첫번째 방법은 서버에 예외를 던지기 때문에 Row Data를 개별 업로드를 해서 중복 예외처리를 해주는 방법으로 처리해야 한다. 이 방법을 개선하기 위해 엑셀파일의 데이터를 파싱한 Row 단위로 체킹 로직을 개발했다. Sheet의 Row Data 만큼 반복문을 돌리는 과정에서, Unique하게 잡은 컬럼 값들을 기준으로 DB 레코드를 불러와서 엑셀 파일에서 불러온 Row 데이터의 Unique 컬럼 값과 확인하는 과정이다.
장점
- 코드가 직관적이다.
단점
- 첫번째 방법과 동일한 메커니즘으로 매 컬럼마다의 쿼리 과정에서는 Select 쿼리 자체 코스트보다 DB 커넥션을 열고 닫는 매 과정의 오버헤드가 더 크다. Redundancy가 RawData 개수에 비례하여 증가한다.
- DB에서 제약사항이 설정되지 않은 경우, 조건 설정이 되어 있지 않은 프로그램의 DB접근에 의해 데이터 정합성이 깨질 수 있다.
pseudocode
//수도코드
for row_data from sheet:
record_from_db = get_data_from_db(u_column1, ...);
is_same_data = compare(row_data, record_from_db);
if(is_same_data) continue;
else push_to_db(row_data);
적은 수의 데이터를 처리할 때는 직관성 측면이나 개발 난이도 측면에서 매우 간단하지만, 데이터가 많은 상황에서는 사용하기 어려운 접근법이라고 생각한다.
위 코드의 개선점 및 upsert기법, JPA 코드구현은 다음 포스팅에 남기겠다.
'Computer Science > 데이터베이스' 카테고리의 다른 글
[Mysql] DB 성능 최적화 - 1. Explain이란? (1) | 2025.01.20 |
---|---|
[MariaDB] 데이터 타입 종류 정리해서 보자! (0) | 2023.07.28 |
Transaction이란? - 1 (정의, 특징-ACID) (0) | 2023.05.02 |
[SQL, MariaDB] 한 테이블의 특정 컬럼에 있는 값이 다른 컬럼에 없는 레코드 탐색. (0) | 2023.03.14 |