📢 공지합니다
이 게시글은 메인 페이지에 항상 고정되어 표시됩니다.
📌 고정 게시글
최코딩의 개발
[3부] CS 과제 공부하기 본문
728x90
1. JDBC 대량 데이터 처리
1-1. 개요
https://balhae.tistory.com/118
섹션1 JDBC 이해
최코딩의 개발 섹션1 JDBC 이해 본문 스프링/스프링 DB 섹션1 JDBC 이해 seung_ho_choi.s 2023. 10. 22. 00:26
balhae.tistory.com
2년 5개월전에 JDBC 생태계를 작성해봤다. 해당 블로그에 레거시한 DB 커넥션 코드도 있다.
자바에서 데이터베이스에 대량의 데이터를 삽입하거나 수정할 때, executeUpdate()를 반복해서 호출하는 것은 성능에 치명적이다. 이를 해결하기 위해 JDBC는 여러 SQL을 묶어서 한 번에 보내는 Batch(배치) 방식을 지원한다.
1-2. 표준 Batch 처리 (addBatch, executeBatch)
pstmt = conn.prepareStatement(sql);
for (int i = 1; i <= 5000; i++) {
pstmt.setString(1, "Data_" + i);
pstmt.addBatch(); // 배치 실행 요청을 메모리에 누적
// 1000건 단위로 나누어 전송 (메모리 및 네트워크 효율 고려)
if (i % 1000 == 0) {
pstmt.executeBatch(); // 누적된 배치를 한 번에 DB로 전송
pstmt.clearBatch(); // 배치 버퍼 초기화
}
}
pstmt.executeBatch(); // 잔여 배치 처리
표준 JDBC 인터페이스에서 제공하는 방식으로, 대부분의 DBMS(MySQL, Oracle, PostgreSQL 등)에서 공통적으로 사용된다. 개발자가 명시적으로 전송 시점을 결정하는 점이 특징이다.
- 작동 원리: addBatch()를 통해 SQL을 메모리 큐에 쌓고, executeBatch()를 호출하는 순간 네트워크를 통해 DB로 전송한다.
- 장점: DB에 의존적이지 않아 코드 이식성이 높고, 전송 타이밍을 개발자가 정밀하게 제어할 수 있다.
즉, 다수의 SQL 실행 요청을 클라이언트 메모리에 누적하고, executeBatch() 호출 시 이를 하나의 요청으로 DB에 전달함으로써, 1,000건의 개별 SQL 실행으로 발생하던 네트워크 왕복 비용을 단 한 번으로 줄일 수 있다.
1-3. 오라클 전용 Batch 처리 (setExecuteBatch, sendBatch)
running batch statements in Oracle: sendBatch() vs executeBatch()
I'm writing Java code to execute a batch of insert statements into an Oracle database. I've seen in some of the documentation (http://docs.oracle.com/cd/B28359_01/java.111/b31224/oraperf.htm) that ...
stackoverflow.com
정보가 없어서 위 링크를 참고했다. (AI는 100% 신뢰 못하므로..!)
// 오라클 전용 방식 (캐스팅 필요)
OraclePreparedStatement opstmt = (OraclePreparedStatement) conn.prepareStatement(sql);
// 100건이 쌓이면 자동으로 전송하도록 설정
opstmt.setExecuteBatch(100);
for (int i = 1; i <= 250; i++) {
opstmt.setString(1, "Oracle_" + i);
// 100, 200번째에 자동으로 네트워크 전송 발생
opstmt.executeUpdate();
}
// 나머지 50건은 설정값에 도달하지 못했으므로 수동 전송
opstmt.sendBatch();
오라클 JDBC 드라이버(OraclePreparedStatement)에서만 제공하는 독자적인 기능이다. 드라이버가 내부적으로 설정된 개수만큼 데이터를 관리하다가 자동으로 전송하는 묵시적 방식으로 동작한다.
- setExecuteBatch(int size): 배치 크기를 미리 설정한다. 이 설정값만큼 executeUpdate()가 호출되면 드라이버가 알아서 DB로 데이터를 보낸다.
- sendBatch(): 설정된 크기(size)에 아직 도달하지 않았더라도, 현재 쌓여있는 데이터를 즉시 강제로 전송할 때 사용한다.
2. Oracle DB 동기화 및 이중화(RAC/HA)
DB를 운영할 때 가장 중요한 것은 "서비스가 중단되지 않는 것"과 "데이터를 잃지 않는 것"이다. 이 두 마리 토끼를 잡기 위한 핵심 기술들을 소개하겠다.
2-1. HA (High Availability: 고가용성)
개념: 운영 DB 인스턴스가 죽으면, 대기하고 있던 서버에서 인스턴스를 새로 올려 서비스를 이어받는 방식이다.
DB 매커니즘: OS 레벨의 클러스터 소프트웨어가 '인스턴스 A'를 감시합니다. 장애 시 A를 강제 종료하고, 공유 저장소의 소유권을 서버 B로 넘긴 뒤 '인스턴스 B'를 새로 기동(Cold Failover)한다.
비유: 요리사가 요리하다 쓰러지면, 집에서 쉬던 요리사가 연락받고 달려와 주방을 이어받는다. (출근 시간 동안 주방 정지)장점: 구성이 단순하고 라이선스 비용이 RAC보다 저렴하다.
단점: 대기 서버가 노는 자원 낭비가 발생하며, 장애 전환 시 DB가 다시 켜지는 수 분 동안 서비스가 끊긴다.
도식화:
# HA (High Availability) - 전체 구조
[ 유저 ]
│
├──▶ [WAS 서버 A] ──┐
│ │
└──▶ [WAS 서버 B] ──┤
│
├──▶ [DB 서버 A] [DB 서버 B]
│ └─ 인스턴스 A └─ 인스턴스 B
│ (Active) (Standby)
│ │ │
└────────────┴──▶ [공유 디스크] ◀───────┘
(DB 스토리지)
WAS는 1대여도 상관X2-2. OPS (Oracle Parallel Server): RAC의 조상
개념: 여러 개의 인스턴스가 하나의 데이터베이스(공유 저장소)를 공유하는 최초의 모델이다.
DB 매커니즘: 여러 인스턴스가 동시에 가동되지만, 인스턴스 간 데이터 교환 기능이 없다. A 인스턴스가 수정 중인 데이터를 B가 읽으려면 반드시 디스크(Storage)에 쓰고 읽는 과정이 필요했습니다. 이를 Disk Ping이라고 한다.
비유: 두 요리사가 한 주방에서 일하는데, 서로 대화를 안 하고 메모지를 벽(디스크)에 붙여서 소통한다. (답답하고 느림)
장점: 여러 서버를 동시에 사용(Active-Active)하는 개념을 처음 도입했다.
단점: 디스크 I/O가 빈번하게 발생하여 노드(서버)를 늘려도 성능이 오히려 떨어지는 병목 현상이 심했다.
도식화
# OPS (Oracle Parallel Server) - 전체 구조 (정리 버전)
[ User ]
|
v
[ WAS (1대든 여러대든 OK) ]
|
v
+------------------- Oracle OPS Cluster -------------------+
| |
| [DB Server A] [DB Server B] |
| (Instance A) (Instance B) |
| | | |
| | (인스턴스 간 전용 통신망 없음) | |
| | (메모리↔메모리 교환 없음) | |
| | | |
| +---------------> [ Shared Disk ] <--------------+ |
| (DB files on Storage) |
| |
| Disk Ping = 디스크를 중계로 데이터 동기화/교환 |
| (Instance A → Disk → Instance B) |
| |
+----------------------------------------------------------+
2-3. RAC (Real Application Clusters): 현대 가용성의 표준
개념: OPS의 성능 문제를 Cache Fusion 기술로 해결한 진보된 공유 구조이다.
DB 매커니즘: 인스턴스 간 고속 전용망(Interconnect)을 구축합니다. A 인스턴스 메모리(SGA)에 있는 데이터를 디스크를 거치지 않고 직접 B 인스턴스 메모리로 쏴줍니다. 이를 통해 '디스크 핑'을 제거했다.
비유: 요리사들이 무전기를 차고 실시간으로 대화하며 재료를 주고받음. 한 명의 요리사가 쓰러져도 옆 사람이 즉시 요리를 낚아챈다. (중단 없음, 고성능)
장점: 서비스 중단 없는 고가용성(High Availability)과 서버를 추가하면 성능이 올라가는 확장성(Scalability)을 동시에 만족한다.
단점: 라이선스 비용이 매우 비싸고, 인스턴스 간 통신을 관리하는 클러스터 웨어 설정이 복잡하다.
도식화
# RAC (Real Application Clusters) - 전체 구조 (정리 버전)
[ User ]
|
v
[ WAS (1대든 여러대든 OK) ]
|
v
+------------------- Oracle RAC Cluster -------------------+
| |
| [DB Server A] [DB Server B] |
| (Instance A) (Instance B) |
| | | |
| |<========= Interconnect (Private) ========>| |
| | (Cache Fusion: 메모리 블록 전송) | |
| | | |
| +---------------> [ Shared Disk ] <--------------+ |
| (DB files on Storage) |
| |
+----------------------------------------------------------+
2-4. 데이터 동기화
2-4-1. 개요
데이터베이스 동기화는 두 개 이상의 데이터베이스 간에 데이터를 일치시키는 과정이다. 서로 다른 위치나 시스템에 있는 데이터베이스들이 동일한 정보를 유지하도록 하는 것이 목적이다.
2-4-2. 주요 동기화 방식
단방향 동기화는 하나의 마스터 데이터베이스에서 하나 이상의 슬레이브 데이터베이스로 데이터가 흐른다. 주로 읽기 성능을 향상시키기 위한 복제(Replication)에 사용된다.
양방향 동기화는 여러 데이터베이스가 모두 쓰기와 읽기가 가능하며, 변경사항이 서로 동기화된다. 충돌 해결 메커니즘이 필요하다.
2-4-2. 동기화 시점
실시간 동기화는 트랜잭션이 발생하는 즉시 동기화가 이루어지며, 데이터 일관성이 높지만 성능 부담이 있다.
배치 동기화는 일정 주기마다 변경사항을 묶어서 동기화하며, 성능은 좋지만 일시적인 데이터 불일치가 발생할 수 있다.
3. DataBase CDC (Change Data Capture ) 개념
3-1. 개념
Change Data Capture (CDC)는 데이터베이스의 변화를 실시간으로 감지하고 캡처하는 기술이다. 이를 조금더 직관적으로 해석 한다면, 데이터베이스에서의 삽입(insert), 수정(update), 삭제(delete)와 같은 이벤트가 발생할 때마다 순서대로 기록한다.
3-2. 동작
위 그림은 DMS( Database Migration Service) 를 통해 Kafka 가 MySQL 의 CDC 이벤트를 받은 메시지의 예시이다. 데이터 변경의 타입, 데이터, 테이블, 시간, 트랜젝션ID 등의 정보가 담겨있다. “x 테이블의 x 데이터가 언제 어떤 순서로 변경 되었다” 판단하는데 도움을 준다.
insert, update, delete 를 흔히 데이터 조작어 (DML: Data Manipulation Language)라고 부른다. CDC 는 DML 뿐 아니라 데이터 정의어 (DDL: Data Definition Language) 도 기록된다. DDL 이벤트를 활용하면 완전히 같은 스키마를 유지하는 데이터를 복제하여 유지 할수 있다.
CDC가 구현되기 위해서는 DBMS (DataBase Management System) 의 도움이 필요한다. DBMS 는 관계형 데이터베이스인 PostgreSQL, MySQL 또는 No SQL 인 MongoDB, Cassandra, DynamoDB 등이 있다. 이 중에서 PostgreSQL 은 pg_wal 폴더 안에 WAL 파일에 CDC 이벤트를 기록한다.
정리하자면
- MySQL: binlog (Binarly Log)
- PostgreSQL: WAL(Write Ahead Log)
- MongoDB: Oplog(Operations Log)
- Apache Cassandra: commitlog
- DynamoDB: DynanaDB Streams / ON
이와 같다.
3-3. CDC로 할 수 있는거
3-3-1. 특정시점으로 복구
데이터베이스에 문제가 생겼을 때, 단순히 '어제의 백업본'으로 돌아가는 것이 아니라 "오늘 오후 2시 10분 5초"와 같이 아주 정밀한 시점으로 복구하는 기술이다.
3-3-2. 실시간 데이터 복제(위쪽에 동기화)
운영 중인 메인 DB의 데이터를 타겟 시스템(분석용 DB, 검색 엔진, 캐시 서버 등)에 실시간으로 똑같이 맞추는 작업이다.
3-3-3. 무중단 데이터 이관
서비스를 멈추지 않고 운영 중인 DB를 새로운 서버나 클라우드로 옮기는 고난도 작업이다.
3-4. 참고
https://monday9pm.com/what-is-the-cdc-and-what-can-it-do-2cd4a002b061
1차로 개념적으로 간단하게 정리했지만 추후 원리까지 다시 공부해서 포스팅하겠다.
4. Oracle 주요 객체와 트랜잭션 메커니즘 정리
(Function / Procedure / Package / Trigger / Redo·Undo / Commit·Rollback)
4-1. PL/SQL 객체 (Function, Procedure, Package, Trigger)
4-1-1. Function(함수)
특정 연산을 수행하고 결과를 반드시 하나의 값으로 돌려주는 객체다
| 구분 | 장점 | 단점 |
| Function | SQL 문장(SELECT, WHERE 등) 안에서 직접 호출할 수 있어 계산 로직의 재사용성이 매우 높다 | 대량의 데이터를 조회할 때 각 행마다 함수가 실행되면 성능이 급격히 떨어질 수 있다 |
CREATE OR REPLACE FUNCTION fn_get_tax_price(p_price NUMBER)
RETURN NUMBER IS
BEGIN
-- 가격에 1.1을 곱해 부가세 포함 금액 반환
RETURN (p_price * 1.1);
END;
-- 사용 예시: SELECT name, fn_get_tax_price(price) FROM products;
실제 예시: 상품 가격을 입력하면 부가세(10%)가 포함된 금액을 계산해 주는 함수
4-1-2. Procedure (프로시저)
특정 비즈니스 로직을 일괄 처리하기 위한 실행 단위다.
| 구분 | 장점 | 단점 |
| Procedure | 여러 개의 쿼리를 하나의 묶음으로 처리하여 네트워크 부하를 줄이고 로직을 캡슐화할 수 있다. | 일반적인 SQL문(SELECT) 내부에서 함수처럼 호출하여 값을 가져올 수는 없다. |
- 실제 예시: 특정 부서 사원들의 급여를 일괄적으로 10% 인상하는 로직
CREATE OR REPLACE PROCEDURE sp_raise_salary(p_dept_id NUMBER) IS
BEGIN
UPDATE employees
SET salary = salary * 1.1
WHERE department_id = p_dept_id;
COMMIT; -- 절차 완료 후 확정
END;
-- 사용 예시: EXEC sp_raise_salary(10);
==> 즉 함수는 “값을 계산해 돌려주는 것”이고, 프로시저는 “작업을 수행하는 것”이다.
4-1-3. Package (패키지)
관련 있는 함수와 프로시저를 하나의 그룹으로 묶어 관리하는 저장소다.
| 구분 | 장점 | 단점 |
| Package | 관련 로직을 모듈화하여 관리가 쉽고, 패키지 내 변수를 공유할 수 있으며 메모리 효율이 좋다. | 선언부(Spec)와 본체(Body)를 따로 작성해야 해서 초기 설계와 구현에 공수가 더 든다. |
-- 1. 선언부 (명세서)
CREATE OR REPLACE PACKAGE emp_admin_pkg AS
PROCEDURE add_emp(p_name VARCHAR2);
FUNCTION get_emp_count RETURN NUMBER;
END emp_admin_pkg;
-- 2. 본체 (실제 구현)
CREATE OR REPLACE PACKAGE BODY emp_admin_pkg AS
PROCEDURE add_emp(p_name VARCHAR2) IS BEGIN ... END;
FUNCTION get_emp_count RETURN NUMBER IS BEGIN ... END;
END emp_admin_pkg;
4-1-4. Trigger (트리거)
특정 사건(Insert, Update, Delete)이 일어날 때 자동으로 실행되는 감시자다.
| 구분 | 장점 | 단점 |
| Trigger | 데이터 무결성을 강제하거나, 로그 기록(Auditing) 등 수동으로 누락하기 쉬운 작업을 자동화한다. | 너무 많아지면 "왜 데이터가 바뀌었지?"를 추적하기 어렵고 전체적인 DB 성능을 예측하기 힘들다. |
실제 예시: 사원 테이블의 정보가 삭제될 때, 누가 삭제했는지 이력 테이블에 자동으로 저장함
CREATE OR REPLACE TRIGGER trg_emp_delete_log
AFTER DELETE ON employees FOR EACH ROW
BEGIN
-- 삭제된 사원의 이름과 현재 시간을 로그 테이블에 기록
INSERT INTO emp_history(emp_name, del_date, user_id)
VALUES (:OLD.first_name, SYSDATE, USER);
END;
-- 사용자가 DELETE 문만 실행해도 위 로직이 자동 실행됨~~꼸
4-2. Redo Log vs Undo Log
이 두 로그는 데이터의 안전과 일관성을 책임지는 "기록장"이다.
- Redo Log (다시 하기):
- 역할: 변경된 모든 내용을 기록합니다. DB가 갑자기 꺼졌을 때, 로그를 보고 마지막 상태로 재현한다.
- 장점: 장애 시 데이터 유실 방지 (복구용)
- 내 작업이 절대로 사라지지 않게 기록하는 것이다.
- Undo Log (되돌리기):
- 역할: 변경 전의 데이터를 보관합니다. 사용자가 작업을 취소하거나, 다른 사용자가 수정 중인 데이터를 조회할 때 사용한다.
- 장점: 작업 취소 가능, 작업 중에도 다른 사람에게 이전 데이터 보여준다.
- 즉, 내가 한 작업을 없던 일로 하거나, 남들에게 예전 데이터를 보여주기 위해 원본을 기록 하는 것이다.
4-3. Commit vs Rollback
트랜잭션을 끝내는 두 가지 방법이다.
- Commit:
- 의미: "지금까지 한 작업을 DB에 진짜로 반영해!"
- 결과: Undo 세그먼트의 정보가 불필요해지고, Redo 로그에 기록된 내용이 영구 저장된다. 다른 사용자도 내가 수정한 데이터를 볼 수 있게 된다.
- 장점: 데이터 변경을 확정 짓고 다른 사용자에게 공유한다. 작업 결과가 영구적으로 보존된다.
- 단점: 한 번 커밋하면 이전 상태로 되돌리기가 매우 까다롭다(복구 작업 필요)
- Rollback:
- 의미: "아차, 실수했다! 작업하기 전으로 다 돌려놔!"
- 결과: Undo Log에 저장해뒀던 '변경 전 데이터'를 다시 덮어써서 원래 상태로 복구한다.
- 장점: 실수하거나 오류가 난 작업을 즉시 취소하여 데이터 오염을 막을 수 있다.
- 단점: 이미 커밋된 데이터는 롤백할 수 없다. 즉 커밋 완료 시점 전으로 갈 수가 없다.
==> 즉 Commit과 Rollback은 사용자가 내리는 '명령'이고, Redo와 Undo는 그 명령을 수행하기 위해 DB가 뒤에서 움직이는 '수단'이라고 보면 된다. 더군다나 Redo는 '결과'만 기록하고 Undo는 '과거의 데이터 자체'를 들고있다.
300원에서 100원으로 수정하고 커밋(Commit)을 완료한 시점의 최종 정리다.
| 구분 | 저장된 값 | 핵심 역할 |
| 현재 잔고 | 100원 | 커밋을 했으므로 현재 공식 데이터가 됨 |
| Redo | 100원 | "100원으로 바꿨음"을 기록 (DB가 깨지면 100원으로 복구하기 위함) |
| Undo | 300원 | "원래 300원이었음"을 기록 (하지만 커밋 후엔 버려지는 데이터) |
728x90
'회사 > 갤럭시아머니트리' 카테고리의 다른 글
| [2부] CS 과제 공부하기 (0) | 2026.01.22 |
|---|---|
| [1부] CS 과제 공부하기 (0) | 2026.01.21 |
| 서브쿼리와 조인 전략 (0) | 2026.01.19 |
'회사/갤럭시아머니트리' Related Articles
more
