데이터베이스는 여러 사용자가 공유하여 사용할 목적으로 통합 관리되는 데이터의 집합입니다. DBMS(Database Management System)는 데이터베이스를 관리하고 운영하는 소프트웨어입니다. 데이터베이스를 사용하는 이유는 데이터 중복을 최소화하고 일관성을 유지하며, 데이터 독립성을 보장하여 응용 프로그램과 데이터를 분리할 수 있기 때문입니다. 또한 동시성 제어를 통해 여러 사용자가 동시에 접근할 수 있고, 보안과 무결성을 보장하며, 장애 발생 시 백업과 복구 기능을 제공합니다.

💡 동시성 제어

여러 사용자가 같은 데이터에 동시에 접근/수정할 때 충돌이 나지 않도록 순서·잠금·격리수준 등을 써서 정확성을 보장하는 기능.

• 예: 두 사람이 같은 계좌를 동시에 이체해도 잔액이 틀어지지 않게 함

💡 무결성(데이터 무결성)

데이터가 정확하고 일관되게 유지되도록 하는 규칙/제약.

• 예: 기본키는 중복 금지, 외래키는 존재하는 값만 참조, 나이 컬럼은 음수 금지 등

💡 백업

장애나 실수에 대비해 데이터를 복사해 보관하는 것.

• 예: 전체 백업, 변경분만 저장하는 증분/차등 백업 → 나중에 복구에 사용

관계형 데이터베이스는 데이터를 2차원 테이블 형태로 저장하고 관리하는 데이터베이스입니다. 테이블 간의 관계를 외래키로 연결하여 데이터의 무결성을 보장합니다. 주요 특징으로는 ACID 속성을 만족하여 트랜잭션의 안정성을 보장하고, SQL이라는 표준화된 질의 언어를 사용합니다. 장점으로는 데이터 일관성과 무결성이 우수하고, 복잡한 질의와 조인 연산이 가능하며, 성숙한 기술로 안정성이 높습니다. 단점으로는 수직적 확장만 가능하여 대용량 데이터 처리에 한계가 있고, 스키마 변경이 어려우며, 빅데이터나 비정형 데이터 처리에 적합하지 않습니다.

💡 외래키(Foreign Key)

다른 테이블의 기본키를 참조하는 열. 존재하는 값만 참조하게 해서 관계/무결성 보장.

💡 ACID(트랜잭션의 4특성)

• Atomicity(원자성): 전부 되거나 전부 롤백
• Consistency(일관성): 제약 조건 항상 만족
• Isolation(격리성): 동시에 실행돼도 서로 간섭 최소
• Durability(지속성): 커밋 후 영구 저장

💡 트랜잭션

논리적으로 하나인 작업 단위(예: 이체: 출금+입금). ACID로 안전하게 처리.

💡 질의(Query)

DB에 데이터를 요청/조작하는 명령. 보통 SQL로 작성.

💡 조인 연산(Join)

공통 키로 여러 테이블을 결합해 원하는 형태로 결과를 얻는 것(INNER/LEFT/RIGHT 등).

💡 성숙한 기술

오랜 기간 사용·검증되어 안정성, 도구, 커뮤니티, 베스트프랙티스가 풍부함.

💡 수직적 확장(Scale Up)

한 서버의 CPU·RAM·스토리지를 키워 성능을 높이는 방식(반대: 수평 확장).

💡 스키마(Schema)

테이블 구조(컬럼 이름/타입/제약 등). 데이터 형식과 규칙을 정의.

💡 비정형 데이터

정해진 표 구조가 없는 데이터.

• 예: 텍스트, 이미지, 로그, 동영상 등(열·행로 딱 맞추기 어려움).

NoSQL은 관계형 데이터베이스의 제약을 극복하기 위해 등장한 비관계형 데이터베이스입니다. 키-값 스토어는 Redis, DynamoDB가 대표적이며 단순한 구조로 빠른 읽기/쓰기가 가능합니다. 문서 지향 데이터베이스는 MongoDB, CouchDB가 있으며 JSON 형태의 문서를 저장하여 스키마 유연성이 좋습니다. 컬럼 패밀리는 Cassandra, HBase가 있으며 대용량 데이터의 분산 저장에 적합합니다. 그래프 데이터베이스는 Neo4j, Amazon Neptune이 있으며 관계 데이터 분석에 특화되어 있습니다. 각각은 수평적 확장성과 고성능을 제공하지만 ACID 보장이 약하고 복잡한 질의가 어렵습니다.

💡 키-값 스토어? 왜 나왔나

“NoSQL 분류” 중 하나이다. 키(Key)로 값(Value)을 바로 찾는 가장 단순·고속 모델이라 NoSQL의 대표 예로 나온 것.

💡 Redis, DynamoDB

• Redis: 인메모리 키-값 DB. 극저지연, 캐시/세션/큐에 많이 씀.
• DynamoDB: AWS의 완전관리형 키-값/문서 DB. 자동 스케일, 서버리스 과금.

💡 MongoDB, CouchDB

문서 지향 DB. 문서(보통 JSON 계열) 단위로 저장·조회. 스키마가 유연하고 계층 구조 표현이 쉬움.

💡 JSON

키-값 쌍과 배열로 데이터를 표현하는 텍스트 포맷. 사람이 읽기 쉽고, 대부분 언어에서 다루기 쉬움.

💡 스키마 유연성

테이블처럼 컬럼이 고정되지 않고, 문서마다 필드 구조가 달라도 허용(진화적 스키마).

💡 컬럼 패밀리도 DB 종류인가? 그렇다면 Cassandra, HBase는 무엇인가?

컬럼 패밀리도(NoSQL 분류) DB이다.

• Cassandra: 분산·고가용성에 특화, 쓰기·확장 강함(마스터리스).
• HBase: Hadoop/HDFS 위에서 동작, 대용량 랜덤 읽기/쓰기 지원.

💡 Neo4j, Amazon Neptune

그래프 DB. 노드(점)와 엣지(관계)로 모델링해 관계 탐색/경로 질의에 최적.

💡 수평적 확장성(Scale Out)

한 서버를 키우는 게 아니라 서버 대수를 늘려 처리량을 키우는 것(샤딩/파티셔닝, 분산 처리).

DDL(Data Definition Language)은 데이터베이스 구조를 정의하는 언어로 CREATE, ALTER, DROP, TRUNCATE가 있습니다. 테이블, 인덱스, 뷰 등의 객체를 생성하고 수정, 삭제할 때 사용하며 자동으로 커밋됩니다. DML(Data Manipulation Language)은 데이터를 조작하는 언어로 SELECT, INSERT, UPDATE, DELETE가 있습니다. 실제 데이터를 조회하고 추가, 수정, 삭제할 때 사용합니다. DCL(Data Control Language)은 데이터 접근 권한을 제어하는 언어로 GRANT, REVOKE가 있습니다. 사용자에게 권한을 부여하거나 회수할 때 사용합니다. TCL(Transaction Control Language)은 트랜잭션을 제어하는 언어로 COMMIT, ROLLBACK, SAVEPOINT가 있으며 트랜잭션의 시작과 종료를 관리합니다.

💡 CREATE / ALTER / DROP / TRUNCATE

• CREATE: 객체 생성 (예: CREATE TABLE users (...))
• ALTER: 구조 변경 (컬럼 추가/수정 등)
• DROP: 객체 자체 삭제(메타데이터 포함, 복구 어려움)
• TRUNCATE: 테이블 모든 행 삭제(로그 최소, 빠름, 구조는 유지)

💡 뷰(View)

실제 데이터를 저장하지 않고 SELECT 결과를 이름으로 묶어둔 가상 테이블로, 복잡한 조회 단순화, 컬럼 제한으로 보안·캡슐화에 유용하다.

💡 커밋(Commit)

현재 트랜잭션에서 한 변경을 영구 저장하는 것으로 커밋 전에는 롤백 가능, 커밋 후엔 되돌리기 어렵다.

💡 SELECT / INSERT / UPDATE / DELETE

• SELECT: 조회
• INSERT: 행 추가
• UPDATE: 값 수정
• DELETE: 행 삭제

💡 GRANT / REVOKE

• GRANT: 사용자/역할에 권한 부여
• REVOKE: 부여했던 권한 회수

💡 권한의 의미?

• DB에서 허용되는 행동/접근 범위.
• 예: SELECT(읽기), INSERT/UPDATE/DELETE(쓰기), EXECUTE(프로시저 실행), CREATE TABLE, 특정 스키마/테이블 접근 등.

💡 COMMIT / ROLLBACK / SAVEPOINT

• COMMIT: 변경 확정(영구화)
• ROLLBACK: 트랜잭션 전체 취소
• SAVEPOINT: 트랜잭션 중간에 되돌림 지점 설정 → ROLLBACK TO savepoint로 부분 취소 가능.

JOIN은 두 개 이상의 테이블을 연결하여 데이터를 조회하는 SQL 기법입니다. INNER JOIN은 양쪽 테이블에 모두 존재하는 데이터만 반환하며 가장 일반적으로 사용됩니다. LEFT OUTER JOIN은 왼쪽 테이블의 모든 데이터와 오른쪽 테이블의 매칭되는 데이터를 반환하고, 매칭되지 않으면 NULL로 채웁니다. RIGHT OUTER JOIN은 그 반대입니다. FULL OUTER JOIN은 양쪽 테이블의 모든 데이터를 반환하며, 매칭되지 않는 부분은 NULL로 처리됩니다. CROSS JOIN은 카테시안 곱으로 모든 조합을 반환하고, SELF JOIN은 같은 테이블을 자기 자신과 조인하는 방식입니다.

💡 NULL

“값이 없음/미정/모름”을 뜻하는 특수 값이다. 0이나 빈 문자열과 다르다. 비교 연산도 일반값처럼 하지 않고 IS NULL, IS NOT NULL로 확인한다.

💡 카테시안 곱(Cartesian product)

두 테이블의 모든 행 조합을 만든 결과이다. A에 3행, B에 4행이면 결과는 3×4=12행. CROSS JOIN이나 JOIN에 조건(ON)이 없을 때 발생한다.

인덱스는 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조입니다. 테이블의 특정 컬럼값과 해당 레코드의 주소를 키-값 쌍으로 저장합니다. 대부분 B+Tree 구조를 사용하여 O(log n)의 시간복잡도로 빠른 검색이 가능합니다. 클러스터 인덱스는 테이블 데이터 자체가 인덱스 순서로 정렬되고, 논클러스터 인덱스는 별도의 구조로 관리됩니다. 장점으로는 SELECT 성능이 크게 향상되고 ORDER BY, GROUP BY의 성능도 개선됩니다. 단점으로는 추가 저장공간이 필요하고, INSERT, UPDATE, DELETE 시 인덱스도 함께 수정되어 성능 저하가 발생할 수 있습니다. 또한 잘못 설계된 인덱스는 오히려 성능을 떨어뜨릴 수 있습니다.

💡 레코드(ROW)

테이블의 한 줄 데이터. 한 사람, 한 주문 같은 개별 엔트리.

💡 B+Tree 구조

균형 트리의 한 종류. 모든 데이터가 리프 노드에 연속적으로 저장되고, 내부 노드는 탐색용 키만 가짐 → 범위 조회·정렬에 유리, 검색 평균 O(log n).

💡 ORDER BY / GROUP BY

• ORDER BY: 결과 정렬.
• GROUP BY: 같은 값끼리 묶어 집계(COUNT, SUM 등).

인덱스가 정렬·범위 기반이라 이 연산들이 더 적은 정렬/스캔으로 끝남.

💡 클러스터 인덱스 vs 논클러스터 인덱스 (왜 나왔나?)

• 클러스터 인덱스: 테이블 자체가 인덱스 순서로 정렬됨(=데이터 물리 배치가 키 순). 범위 스캔/정렬이 매우 빠름(일반적으로 테이블당 1개).
• 논클러스터 인덱스: 테이블과 별도 구조로 키+포인터(또는 리프에 포함 데이터 일부)를 가짐. 여러 개 만들 수 있어 조회 패턴별 최적화 가능.

👉 즉, 동작 원리/구조의 차이로 분류된 것(서로 보완).

💡 추가 저장공간이 필요한 이유

인덱스는 테이블과 별개의 자료구조(트리 노드, 키, 포인터/리프 데이터 등)를 유지해야 해서 추가 디스크/메모리가 듭니다. (논클러스터 인덱스는 특히 다수 생성 시 공간 증가)

정규화는 데이터의 중복을 최소화하고 일관성을 유지하기 위해 테이블을 분해하는 과정입니다. 제1정규형(1NF)은 테이블의 모든 속성이 원자값을 가져야 하며, 반복 그룹이 없어야 합니다. 즉, 하나의 셀에는 하나의 값만 들어가야 합니다. 제2정규형(2NF)은 1NF를 만족하면서 부분적 함수 종속을 제거한 형태입니다. 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되어야 합니다. 제3정규형(3NF)은 2NF를 만족하면서 이행적 함수 종속을 제거한 형태입니다. 기본키가 아닌 속성들 간에 종속 관계가 없어야 합니다. 정규화를 통해 데이터 중복과 갱신 이상을 방지할 수 있지만, 과도한 정규화는 조인 연산을 증가시켜 성능 저하를 일으킬 수 있습니다.

💡 부분적 함수 종속 / 완전 함수 종속 / 이행적 함수 종속

• 부분적 함수 종속: 복합 기본키 (A,B) 중 일부(A만) 로도 속성 X가 결정됨. → X는 키의 전체가 아니라 일부에만 의존
• 예: (학번, 과목) → 학과 가 학번만으로 결정된다면 부분 종속
• 완전 함수 종속: 복합 기본키 전체(A와 B 모두) 에 의존해야만 X가 결정됨. → 키의 모든 속성 필요
• 예: (학번, 과목) → 성적 은 둘 다 필요(완전 종속)
• 이행적 함수 종속: A → B, B → C 이면 A → C 가 되는 간접 의존. 기본키가 아닌 속성끼리 이런 간접 종속이 있으면 3NF 위반
• 예: 학번 → 학과, 학과 → 학과사무실전화 ⇒ 학번 → 학과사무실전화 (이행 종속)

💡 기본키(Primary Key)

테이블에서 각 행을 유일하게 식별하는 키. NULL 불가, 중복 불가. (예: 학번, 주문번호.)

💡 갱신 이상(Anomaly) : 정규화가 부족할 때 생기는 비정상 현상.

• 삽입 이상: 일부 정보만 넣고 싶은데 쓸데없는 컬럼도 강제로 필요
• 삭제 이상: 한 행을 지웠더니 원치 않는 정보까지 소실
• 갱신 이상: 같은 정보가 여러 군데 중복되어 한 곳만 수정하면 불일치 발생

트랜잭션은 데이터베이스에서 하나의 논리적 작업 단위로 실행되는 일련의 연산들입니다. 모든 연산이 성공하거나 모든 연산이 실패하는 All-or-Nothing 방식으로 동작합니다. ACID는 트랜잭션이 만족해야 하는 네 가지 속성입니다. 원자성(Atomicity)은 트랜잭션의 연산들이 모두 성공하거나 모두 실패해야 함을 의미합니다. 일관성(Consistency)은 트랜잭션 실행 전후에 데이터베이스가 일관된 상태를 유지해야 함을 뜻합니다. 격리성(Isolation)은 동시에 실행되는 트랜잭션들이 서로 영향을 주지 않아야 함을 의미합니다. 지속성(Durability)은 성공적으로 완료된 트랜잭션의 결과가 시스템 장애가 발생해도 영구적으로 보존되어야 함을 의미합니다.

💡 논리적 작업 단위란?

함께 성공하거나 함께 실패해야 의미가 있는 연산 묶음”을 말한다.

• 계좌 이체: A 계좌 출금 + B 계좌 입금 → 둘 다 성공해야 이체가 성립. 하나만 되면 안 됨.
• 주문 처리: 주문 생성 → 재고 차감 → 결제 승인 → 영수증 기록 → 전부 성공해야 주문 완료.

즉, 여러 SQL을 하나의 트랜잭션으로 묶어 “전부 성공(커밋) / 전부 취소(롤백)”로 다루는 단위를 뜻한다.

격리 수준은 동시에 실행되는 트랜잭션들 간의 격리 정도를 나타냅니다. READ UNCOMMITTED는 가장 낮은 격리 수준으로 커밋되지 않은 데이터도 읽을 수 있어 Dirty Read가 발생할 수 있습니다. READ COMMITTED는 커밋된 데이터만 읽을 수 있지만 Non-Repeatable Read가 발생할 수 있습니다. REPEATABLE READ는 트랜잭션 동안 같은 데이터를 반복 읽으면 같은 결과를 보장하지만 Phantom Read가 발생할 수 있습니다. SERIALIZABLE은 가장 높은 격리 수준으로 완전한 격리를 보장하지만 성능이 가장 떨어집니다. Dirty Read는 커밋되지 않은 데이터를 읽는 현상, Non-Repeatable Read는 같은 데이터를 다시 읽었을 때 다른 값이 읽히는 현상, Phantom Read는 같은 조건으로 조회했을 때 이전에 없던 레코드가 나타나는 현상입니다.

💡 읽기 현상(Read Phenomena) or 동시성 이상(Concurrency Anomalies)

Dirty Read / Non-Repeatable Read / Phantom Read = 동시 실행 중에 발생할 수 있는 이상 현상
격리 수준은 이 현상들이 발생하지 않도록 막는 정도를 정한 규칙

• Dirty Read: 아직 커밋되지 않은 값을 읽음 → 나중에 롤백되면 읽은 값이 존재하지 않았던 값이 됨.
• Non-Repeatable Read: 같은 행을 트랜잭션 안에서 두 번 조회했는데, 그 사이에 다른 트랜잭션이 값을 바꿔 결과가 달라짐.
• Phantom Read: 같은 조건으로 집합 조회를 두 번 했는데, 그 사이에 다른 트랜잭션이 행을 추가/삭제해서 새(혹은 사라진) 행이 나타남.

Lock은 동시에 실행되는 트랜잭션들이 같은 데이터에 접근할 때 일관성을 보장하기 위한 메커니즘입니다. Shared Lock(S-Lock)은 읽기 전용 잠금으로 다른 트랜잭션의 읽기는 허용하지만 쓰기는 차단합니다. Exclusive Lock(X-Lock)은 배타적 잠금으로 다른 트랜잭션의 읽기와 쓰기를 모두 차단합니다. 범위에 따라 행 수준 잠금, 페이지 수준 잠금, 테이블 수준 잠금으로 구분됩니다. Deadlock은 두 개 이상의 트랜잭션이 서로가 보유한 자원을 기다리며 무한정 대기하는 상황입니다. 예방 방법으로는 Lock 순서를 일정하게 유지하거나, Lock 타임아웃을 설정하는 방법이 있습니다. 탐지 및 해결 방법으로는 Wait-for Graph를 이용한 탐지나 희생자 선택을 통한 해결이 있습니다.

💡 배타적 잠금(Exclusive Lock, X-Lock)

해당 데이터에 대해 나만 읽고/쓸 수 있게 하는 잠금. 다른 트랜잭션의 읽기·쓰기 모두 차단.

💡 행/페이지/테이블 수준 잠금

• 행(Row) 잠금: 특정 행만 잠금 → 병행성↑, 오버헤드↑
• 페이지(Page) 잠금: 여러 행이 담긴 페이지 단위 잠금 → 중간
• 테이블(Table) 잠금: 테이블 전체 잠금 → 병행성↓, 오버헤드↓(단순)

💡 Lock 타임아웃

잠금을 얻으려고 얼마나 기다릴지 정하는 시간. 시간 초과 시 에러/롤백하여 무한 대기 방지.

💡 Wait-for Graph

“누가 누구의 잠금을 기다리는지”를 그래프로 표현. 사이클(순환)이 발견되면 교착상태(Deadlock) 발생으로 판단.

💡 희생자 선택(Victim Selection)

데드락 해소를 위해 트랜잭션 하나를 강제 종료/롤백해 잠금을 풀어주는 것. 보통 작업량이 작은 쪽, 비용이 적은 쪽을 희생자로 선택.

MVCC는 동시성 제어를 위해 데이터의 여러 버전을 유지하는 기법입니다. 각 트랜잭션마다 고유한 타임스탬프나 버전 번호를 할당하고, 데이터를 수정할 때 새로운 버전을 생성합니다. 읽기 트랜잭션은 자신의 시작 시점에 존재했던 데이터 버전을 읽어 일관된 스냅샷을 제공합니다. 이를 통해 읽기 작업에서는 Lock을 사용하지 않아도 되므로 읽기와 쓰기 간의 충돌을 줄일 수 있습니다. PostgreSQL, Oracle, MySQL의 InnoDB 엔진에서 사용되며, 동시성은 향상되지만 과거 버전 데이터를 저장하기 위한 추가 공간이 필요하고, 가비지 컬렉션이 필요합니다. 또한 Write Skew와 같은 특수한 이상 현상이 발생할 수 있습니다.

💡 무슨 트랜잭션이 존재하는가? (MVCC 맥락)

• 읽기 트랜잭션(읽기 전용 / 스냅샷 읽기): 시작 시점의 일관된 스냅샷만 읽음(다른 트랜잭션의 미커밋 변경 안 봄).
• 쓰기 트랜잭션(읽기-쓰기): 수정 시 새 버전을 만들고 커밋하면 이후 트랜잭션에서 보이게 됨.

요약 👉 MVCC는 읽기(스냅샷) 와 쓰기(버전 생성) 를 분리해 충돌을 줄임.

💡 InnoDB 엔진

MySQL의 기본 스토리지 엔진. 트랜잭션, MVCC, 행 단위 잠금, 외래키, 크래시 복구(redo/undo 로그), 클러스터 인덱스를 지원해 일반적인 OLTP에 적합.

💡 Write Skew

스냅샷 격리에서 생길 수 있는 이상 현상. 두 트랜잭션이 같은 조건을 읽을 때는 충돌 없지만, 서로 다른 행을 수정해 전역 제약을 깨뜨리는 상황.

• 예: 당직 의사 최소 1명 규칙: T1과 T2가 각각 “이미 1명 있음”이라 보고 각자 다른 의사를 off로 바꿔 커밋 → 결과적으로 0명이 됨.

데이터베이스 설계 시 가장 먼저 요구사항 분석을 통해 필요한 데이터와 기능을 파악해야 합니다. 개념적 설계에서는 ER 다이어그램을 작성하여 엔티티와 관계를 정의하고, 논리적 설계에서는 테이블 구조와 스키마를 설계합니다. 물리적 설계에서는 인덱스, 파티션, 클러스터링 등을 고려합니다. 성능 측면에서는 쿼리 패턴을 분석하여 적절한 인덱스를 설계하고, 정규화와 반정규화의 균형을 맞춰야 합니다. 확장성을 위해 파티셔닝이나 샤딩을 고려하고, 보안을 위해 접근 권한과 암호화를 설계해야 합니다. 또한 백업과 복구 전략, 모니터링 방안도 함께 계획해야 합니다.

Primary Key는 테이블에서 각 행을 유일하게 식별하는 컬럼 또는 컬럼들의 조합입니다. NULL 값을 가질 수 없고, 중복될 수 없으며, 한 테이블에 하나만 존재할 수 있습니다. 자동으로 인덱스가 생성되어 검색 성능이 향상되고, 클러스터 인덱스의 기준이 됩니다. Foreign Key는 다른 테이블의 Primary Key를 참조하는 컬럼으로, 테이블 간의 관계를 나타내고 참조 무결성을 보장합니다. 참조하는 값이 참조되는 테이블에 반드시 존재해야 하며, NULL 값을 가질 수 있습니다. CASCADE, SET NULL, RESTRICT 등의 옵션으로 참조되는 데이터 변경 시의 동작을 정의할 수 있습니다. 이를 통해 데이터의 일관성과 무결성을 자동으로 보장할 수 있습니다.

💡 외래키 참조 동작(Referential Actions)

ON DELETE / ON UPDATE 시에 적용되는 외래키 동작 옵션

• CASCADE: 참조된 행이 삭제/수정되면, 그 행을 참조하던 자식 행도 함께 삭제/수정된다.
• 예: 부모 PK가 바뀌면 자식 FK도 같이 바뀜, 부모가 삭제되면 자식도 삭제.
• SET NULL: 부모가 삭제/수정될 때 자식의 FK 값을 NULL로 변경힌다. (FK 컬럼이 NULL 허용이어야 함)
• RESTRICT: 자식이 참조하고 있으면 부모의 삭제/수정 자체를 거부힌다.

뷰는 하나 이상의 테이블로부터 유도되는 가상 테이블입니다. 실제 데이터를 저장하지 않고 정의만 저장하며, 조회 시 기본 테이블로부터 동적으로 데이터를 가져옵니다. 장점으로는 복잡한 쿼리를 단순화하고, 보안을 위해 특정 컬럼만 노출할 수 있으며, 논리적 데이터 독립성을 제공합니다. 또한 여러 사용자가 다른 관점에서 동일한 데이터를 볼 수 있게 해줍니다. 단점으로는 뷰를 통한 삽입, 수정, 삭제가 제한적이고, 복잡한 뷰는 성능이 떨어질 수 있습니다. 종류로는 일반 뷰와 구체화된 뷰(Materialized View)가 있으며, 구체화된 뷰는 실제 데이터를 저장하여 성능을 향상시키지만 데이터 동기화 문제가 있습니다.

데이터베이스 백업은 시스템 장애나 데이터 손실에 대비하여 데이터를 안전한 곳에 복사하는 작업입니다. 전체 백업은 데이터베이스 전체를 백업하는 방식으로 복구가 간단하지만 시간과 저장공간이 많이 필요합니다. 증분 백업은 이전 백업 이후 변경된 부분만 백업하여 효율적이지만 복구가 복잡합니다. 차등 백업은 전체 백업 이후 변경된 모든 부분을 백업합니다. 핫 백업은 데이터베이스 운영 중에 수행하고, 콜드 백업은 데이터베이스를 정지한 상태에서 수행합니다. 복구 전략으로는 Point-in-Time Recovery를 통해 특정 시점으로 복구하거나, 트랜잭션 로그를 이용한 복구가 있습니다. RTO(Recovery Time Objective)와 RPO(Recovery Point Objective)를 고려하여 적절한 백업 주기와 방법을 선택해야 합니다.

💡 Point-in-Time Recovery (PITR)

백업 + 로그를 이용해 원하는 시점(예: 2025-09-23 14:30:00) 까지 DB를 정밀 복구하는 방법.

💡 트랜잭션 로그를 이용한 복구

전체/차등/증분 백업으로 기준 시점까지 복원한 뒤, 트랜잭션 로그(변경 이력) 를 순서대로 재적용(또는 되돌림)해 최신 또는 특정 시점으로 복구.

💡 RTO / RPO

• RTO: 복구에 허용되는 최대 다운타임(복구 완료까지 걸려도 되는 시간).
• RPO: 복구 시 잃어도 되는 데이터의 최대 허용 시간 범위(예: 5분 → 최대 5분치 데이터 유실 허용).

👉 RTO↓/RPO↓를 원할수록 백업 주기 단축, 로그 보존, 이중화 등 비용/복잡도 ↑.

스토어드 프로시저는 데이터베이스에 저장되는 프로그램으로, 여러 SQL 문을 하나의 단위로 묶어 실행할 수 있습니다. 매개변수를 받아 처리하고 결과를 반환할 수 있으며, 조건문과 반복문 등의 제어 구조를 사용할 수 있습니다. 장점으로는 성능 향상(컴파일된 코드 재사용), 네트워크 트래픽 감소, 보안 강화, 비즈니스 로직 중앙 집중화가 있습니다. 단점으로는 데이터베이스 의존성이 높고 디버깅이 어려우며, 버전 관리가 복잡합니다. 트리거는 특정 이벤트(INSERT, UPDATE, DELETE)가 발생할 때 자동으로 실행되는 특수한 프로시저입니다. BEFORE 트리거는 이벤트 발생 전에, AFTER 트리거는 발생 후에 실행되며, 데이터 무결성 유지, 로깅, 알림 등에 사용됩니다.

파티셔닝은 대용량 테이블을 작은 단위로 분할하여 관리하는 기법입니다. 논리적으로는 하나의 테이블이지만 물리적으로는 여러 개의 세그먼트로 분할됩니다. 수평 파티셔닝은 행을 기준으로 분할하는 방식으로, 범위 파티셔닝은 특정 컬럼의 값 범위로, 해시 파티셔닝은 해시 함수로, 리스트 파티셔닝은 특정 값 목록으로 분할합니다. 수직 파티셔닝은 컬럼을 기준으로 분할합니다. 장점으로는 쿼리 성능 향상(파티션 제거), 관리 용이성(파티션별 백업/복구), 가용성 향상이 있습니다. 단점으로는 조인 성능 저하 가능성, 관리 복잡성 증가, 파티션 키 선택의 중요성이 있습니다. 적절한 파티션 키 선택이 성능에 결정적 영향을 미칩니다.

쿼리 최적화는 실행 시간을 단축하고 자원 사용량을 줄이는 것이 목표입니다. 인덱스를 적절히 활용하여 WHERE, ORDER BY, GROUP BY 절의 성능을 향상시킬 수 있습니다. SELECT절에서 필요한 컬럼만 조회하고, WHERE절에서 조건을 최대한 활용하여 데이터를 줄여야 합니다. JOIN 순서를 최적화하고, 가능하면 INNER JOIN을 사용하며, 서브쿼리보다는 JOIN을 사용하는 것이 좋습니다. LIKE 연산자는 앞부분 와일드카드(%)를 피하고, 함수 사용을 최소화해야 합니다. DISTINCT 대신 GROUP BY를 사용하고, UNION ALL이 UNION보다 빠릅니다. 실행 계획을 분석하여 비효율적인 부분을 찾고, 통계 정보를 최신으로 유지해야 합니다. 배치 처리 시에는 큰 트랜잭션을 작은 단위로 나누는 것이 좋습니다.

💡 UNION

두 결과 집합을 합치고 중복 행을 제거합니다(= DISTINCT 적용).
→ 중복 제거/정렬 과정이 있어 더 느릴 수 있음.

💡 UNION ALL

두 결과 집합을 그대로 이어 붙임(중복 허용).
→ 중복 제거가 없어서 더 빠름.

요령 👉 중복 제거가 필요 없으면 UNION ALL, 중복을 없애야 하면 UNION을 쓰면 된다.

커넥션 풀은 데이터베이스 연결을 미리 생성하여 풀에 저장해두고 재사용하는 기법입니다. 애플리케이션에서 데이터베이스에 접근할 때마다 새로운 연결을 생성하고 해제하는 오버헤드를 줄일 수 있습니다. 주요 매개변수로는 최소 연결 수, 최대 연결 수, 연결 대기 시간, 유휴 연결 타임아웃이 있습니다. 장점으로는 연결 생성/해제 비용 절약, 동시 연결 수 제한으로 데이터베이스 부하 방지, 응답 시간 단축이 있습니다. 적절한 풀 크기 설정이 중요한데, 너무 작으면 대기 시간이 길어지고, 너무 크면 메모리 낭비와 데이터베이스 부하가 증가합니다. 일반적으로 동시 사용자 수, 평균 쿼리 실행 시간, 서버 리소스를 고려하여 설정하며, 모니터링을 통해 지속적으로 조정해야 합니다.

💡 무엇과 ‘연결/해제’하나?

애플리케이션 ↔ 데이터베이스 서버 사이의 DB 연결(보통 TCP 세션 + 인증/프로토콜 핸드셰이크)을 만들고 닫는 걸 말한다. 커넥션 풀은 이 연결을 미리 만들어 보관했다가 재사용한다(닫지 않고 풀에 반납).

💡 주요 매개변수

• 최소 연결 수(min / initial size): 풀에 항상 유지할 최소 연결 개수(기본 워밍업).
• 최대 연결 수(max size): 동시에 빌려줄 최대 연결 개수(상한)—이 이상은 새로 못 빌림.
• 연결 대기 시간(max wait / timeout): 풀이 가득 찼을 때, 연결을 빌리기 위해 기다릴 최대 시간(초과 시 예외).
• 유휴 연결 타임아웃(idle timeout): 오래 놀고 있는 연결을 끊어 정리하기까지의 시간(자원 회수/누수 방지).

OLTP(Online Transaction Processing)는 일상적인 거래 처리를 위한 시스템으로, 짧고 빈번한 트랜잭션을 처리합니다. 정규화된 데이터베이스 구조를 사용하고, 삽입, 수정, 삭제 작업이 많으며, 응답 시간이 매우 중요합니다. 동시성과 일관성이 핵심이고, 상세한 실시간 데이터를 다룹니다. 예시로는 온라인 뱅킹, 주문 처리, 재고 관리 시스템이 있습니다. OLAP(Online Analytical Processing)는 의사결정 지원을 위한 분석 시스템으로, 복잡한 집계 쿼리를 처리합니다. 반정규화된 스타 스키마나 스노플레이크 스키마를 사용하고, 주로 읽기 작업이며, 대용량 데이터를 처리합니다. 과거 데이터의 추세와 패턴 분석이 주목적이며, 응답 시간보다는 처리량이 중요합니다. 예시로는 데이터 웨어하우스, 비즈니스 인텔리전스, 리포팅 시스템이 있습니다.

💡 반정규화된 스타 스키마(Star Schema)

스타 스키마는 중앙에 사실 테이블(Fact), 주변에 차원 테이블(Dimension) 이 별 모양으로 연결된 모델이다. 조인을 줄이려고 차원 테이블을 반정규화(중복 허용) 해서 조회를 빠르게 만든다.

💡 스노플레이크 스키마(Snowflake Schema)

스타 스키마의 차원 테이블을 정규화해 하위 차원으로 나눈 모델(눈꽃 모양). 중복 ↓, 저장공간 ↓ 장점이 있지만 조인 단계 ↑로 쿼리 복잡도/지연이 늘 수 있음.

💡 데이터 웨어하우스(DW) / 비즈니스 인텔리전스(BI) / 리포팅 시스템

• DW: 여러 운영 DB에서 정제·통합한 분석 전용 저장소(히스토리컬 데이터, ETL/ELT).
• BI: DW 데이터를 사용해 대시보드, 분석, 의사결정 지원을 하는 도구/프로세스 전반.
• 리포팅 시스템: 정기/요청 기반으로 보고서 생성·배포(월간 매출, KPI 리포트 등).

요약 👉 DW에 모아두고 → BI로 분석 → 리포팅으로 공유.

분산 데이터베이스는 여러 노드에 걸쳐 데이터를 저장하고 관리하는 시스템입니다. CAP 정리는 분산 시스템에서 일관성(Consistency), 가용성(Availability), 분할 내성(Partition tolerance) 중 최대 두 가지만 동시에 보장할 수 있다는 이론입니다. 일관성은 모든 노드가 동시에 같은 데이터를 보는 것이고, 가용성은 시스템이 계속 동작하는 것이며, 분할 내성은 네트워크 장애에도 시스템이 동작하는 것입니다. CP 시스템은 일관성과 분할 내성을 보장하지만 가용성을 포기하고, AP 시스템은 가용성과 분할 내성을 보장하지만 일관성을 포기합니다. 실제로는 네트워크 분할이 발생할 수 있으므로 CA 시스템은 현실적으로 불가능하며, 대부분 CP 또는 AP 시스템 중 선택해야 합니다.

샤딩은 대용량 데이터베이스를 수평으로 분할하여 여러 서버에 분산 저장하는 기법입니다. 각 샤드는 독립적인 데이터베이스 인스턴스로 동작하며, 전체 데이터의 일부분을 담당합니다. 구현 방법으로는 해시 기반 샤딩, 범위 기반 샤딩, 디렉토리 기반 샤딩이 있습니다. 해시 샤딩은 샤드 키를 해시하여 균등 분산하지만 범위 쿼리가 어렵고, 범위 샤딩은 범위 쿼리에 유리하지만 핫스팟이 발생할 수 있습니다. 장점으로는 선형적 확장성, 성능 향상, 장애 격리가 있습니다. 문제점으로는 크로스 샤드 조인의 복잡성, 리샤딩의 어려움, 트랜잭션 처리 복잡성, 데이터 일관성 문제가 있습니다. 샤드 키 선택이 매우 중요하며, 애플리케이션 레벨에서의 복잡성이 증가합니다.

데이터베이스 복제는 데이터의 복사본을 여러 서버에 유지하는 기법입니다. 동기 복제는 모든 복제본에 동시에 쓰기가 완료되면 트랜잭션이 커밋되어 강한 일관성을 보장하지만 성능과 가용성이 떨어집니다. 비동기 복제는 마스터에서 커밋된 후 복제본에 비동기적으로 전파되어 성능은 좋지만 데이터 손실 가능성이 있습니다. 반동기 복제는 적어도 하나의 슬레이브에는 동기적으로 전파하는 절충안입니다. 마스터-슬레이브 구조에서는 마스터가 쓰기를 처리하고 슬레이브가 읽기를 처리하여 읽기 성능을 향상시킵니다. 마스터 장애 시 슬레이브를 마스터로 승격하는 페일오버 과정이 필요하며, 이때 일시적인 데이터 불일치가 발생할 수 있습니다. 스플릿 브레인 문제를 방지하기 위한 적절한 장애 감지와 조치가 필요합니다.

데이터 웨어하우스는 의사결정 지원을 위해 여러 소스로부터 수집된 통합 데이터를 저장하는 중앙 저장소입니다. 주제 중심적이고, 통합되어 있으며, 시간에 따라 변하지 않고, 비휘발성의 특징을 가집니다. 스타 스키마나 스노플레이크 스키마를 사용하여 차원 테이블과 팩트 테이블로 구성됩니다. ETL은 Extract, Transform, Load의 과정으로 데이터 웨어하우스 구축의 핵심입니다. Extract는 다양한 소스로부터 데이터를 추출하고, Transform은 데이터를 정제, 변환, 집계하며, Load는 데이터 웨어하우스에 적재합니다. 최근에는 ELT(Extract, Load, Transform) 방식도 사용되며, 클라우드 환경에서는 대용량 처리를 위해 분산 처리 엔진을 활용합니다. 데이터 품질 관리, 메타데이터 관리, 증분 로딩 전략이 중요한 고려사항입니다.

데이터베이스 성능 튜닝은 체계적인 접근이 필요합니다. 먼저 성능 지표를 수집하여 병목지점을 식별해야 합니다. 응답시간, 처리량, 자원 사용률, 대기 이벤트를 모니터링하고, AWR(Automatic Workload Repository)이나 Performance Schema 등의 도구를 활용합니다. SQL 튜닝에서는 실행계획을 분석하여 비효율적인 접근 방법을 찾고, 인덱스 스캔 대신 풀 테이블 스캔이 발생하는 이유를 파악합니다. 인덱스 튜닝에서는 사용되지 않는 인덱스 제거, 복합 인덱스 컬럼 순서 최적화, 커버링 인덱스 활용을 고려합니다. 시스템 튜닝에서는 메모리 할당, I/O 서브시스템, CPU 사용률을 최적화하고, 병렬 처리와 파티셔닝을 활용합니다. 지속적인 모니터링과 성능 테스트를 통해 개선 효과를 검증해야 합니다.

NewSQL은 NoSQL의 확장성과 RDBMS의 ACID 속성을 결합한 새로운 데이터베이스 유형입니다. 전통적 RDBMS의 SQL 지원과 트랜잭션 보장을 유지하면서 수평적 확장성을 제공합니다. 기존 RDBMS가 단일 노드 또는 제한적인 클러스터에서 동작하는 반면, NewSQL은 분산 아키텍처를 기본으로 설계되었습니다. 전통적 RDBMS는 잠금 기반 동시성 제어를 사용하지만, NewSQL은 MVCC나 최적화된 잠금 메커니즘을 사용합니다. 스토리지 엔진도 SSD에 최적화되거나 인메모리 처리를 지원합니다. 대표적인 NewSQL로는 Google Spanner, CockroachDB, VoltDB, MemSQL 등이 있습니다. 하지만 복잡성 증가, 운영 비용 상승, 상대적으로 짧은 검증 기간 등의 단점도 있어 신중한 선택이 필요합니다.

데이터베이스는 조직의 핵심 정보를 담고 있어 다양한 보안 위협에 노출됩니다. SQL 인젝션은 가장 일반적인 공격으로 prepared statement와 입력값 검증으로 방지할 수 있습니다. 권한 상승 공격은 최소 권한 원칙과 역할 기반 접근 제어로 대응합니다. 내부자 위협은 감사 로그와 접근 모니터링으로 탐지하고, 중요 데이터는 암호화합니다. 데이터 유출 방지를 위해 DLP(Data Loss Prevention) 솔루션을 도입하고, 네트워크 세분화를 통해 데이터베이스 접근을 제한합니다. 백업 데이터의 보안도 중요하며, 암호화와 접근 제어를 적용해야 합니다. 정기적인 보안 감사, 취약점 스캐닝, 침투 테스트를 통해 보안 수준을 점검하고, 개인정보보호법 등 관련 규정을 준수해야 합니다.

인메모리 데이터베이스는 모든 데이터를 메모리에 저장하여 극도로 빠른 성능을 제공하는 데이터베이스입니다. 디스크 I/O를 제거하여 마이크로초 단위의 응답시간을 달성할 수 있지만, 메모리 비용이 높고 휘발성이라는 단점이 있습니다. 지속성을 위해 스냅샷이나 트랜잭션 로그를 디스크에 저장하며, 클러스터링을 통해 고가용성을 보장합니다. 컬럼 지향 저장, 압축, 병렬 처리 등의 기술을 활용하여 분석 성능을 극대화합니다. 실시간 분석, 고빈도 트레이딩, 실시간 추천 시스템, 세션 스토어, 캐싱 등에 활용됩니다. SAP HANA, Redis, Apache Ignite, VoltDB 등이 대표적이며, 최근에는 하이브리드 방식으로 자주 사용되는 데이터만 메모리에 두고 나머지는 디스크에 저장하는 방식도 사용됩니다.

클라우드 데이터베이스는 클라우드 환경에서 제공되는 관리형 데이터베이스 서비스입니다. 주요 장점으로는 초기 투자 비용 절감, 자동 확장성, 관리 부담 경감, 고가용성 및 재해 복구 기능 제공이 있습니다. 하드웨어 구매나 설치 없이 바로 사용할 수 있고, 사용량에 따른 탄력적 요금제가 적용됩니다. 자동 백업, 모니터링, 보안 패치 등이 제공되어 운영 복잡성이 줄어듭니다. 하지만 네트워크 지연 시간, 벤더 종속성, 데이터 보안 및 컴플라이언스 문제를 고려해야 합니다. 특히 금융이나 의료 분야에서는 데이터 거버넌스가 중요한 이슈입니다. 비용 최적화를 위해 적절한 인스턴스 타입 선택과 리소스 모니터링이 필요하며, 멀티 클라우드 전략을 통해 벤더 종속성을 완화할 수 있습니다.

시계열 데이터베이스는 시간 순서로 정렬된 데이터를 효율적으로 저장하고 처리하는 특화된 데이터베이스입니다. IoT 센서 데이터, 서버 메트릭, 주식 가격, 로그 데이터 등을 처리하는 데 최적화되어 있습니다. 주요 특징으로는 높은 쓰기 처리량, 시간 기반 압축, 자동 데이터 보존 정책, 시간 창 기반 집계 기능이 있습니다. 과거 데이터는 압축하거나 다운샘플링하여 저장 공간을 절약하고, TTL(Time To Live)을 통해 오래된 데이터를 자동 삭제합니다. 특화된 쿼리 언어를 제공하여 시간 범위 조회, 집계, 보간 등을 효율적으로 수행할 수 있습니다. InfluxDB, TimescaleDB, OpenTSDB, Amazon Timestream 등이 대표적이며, 모니터링, IoT, 금융 데이터 분석 등의 분야에서 널리 사용됩니다.

그래프 데이터베이스는 노드(엔티티)와 엣지(관계)로 데이터를 표현하는 NoSQL 데이터베이스입니다. 관계형 데이터베이스에서 복잡한 JOIN으로 처리해야 하는 관계 데이터를 직관적이고 효율적으로 저장할 수 있습니다. 노드는 속성을 가질 수 있고, 엣지는 방향성과 타입, 속성을 가질 수 있습니다. 그래프 순회 알고리즘을 통해 최단 경로, 중심성 분석, 커뮤니티 탐지 등의 복잡한 분석이 가능합니다. Cypher(Neo4j), Gremlin(Apache TinkerPop) 등의 그래프 쿼리 언어를 사용합니다. 소셜 네트워크 분석, 추천 시스템, 사기 탐지, 지식 그래프, 네트워크 분석, 바이오인포매틱스 등에 활용됩니다. Neo4j, Amazon Neptune, ArangoDB, TigerGraph 등이 대표적이며, 관계의 깊이나 복잡성이 중요한 도메인에서 관계형 데이터베이스보다 우수한 성능을 보입니다.

데이터 레이크는 정형, 반정형, 비정형 데이터를 원본 형태 그대로 저장하는 중앙 저장소입니다. 스키마-온-리드 방식으로 데이터를 먼저 저장하고 사용할 때 스키마를 정의합니다. 확장성이 뛰어나고 비용이 저렴하며, 다양한 분석 도구와 연동이 가능합니다. 데이터 웨어하우스는 정형 데이터를 미리 정의된 스키마에 따라 저장하는 시스템으로, 스키마-온-라이트 방식을 사용합니다. 높은 성능과 일관성을 제공하지만 구조 변경이 어렵고 비용이 높습니다. 데이터 레이크는 탐색적 분석, 머신러닝, 실시간 스트리밍에 적합하고, 데이터 웨어하우스는 정형화된 비즈니스 보고서와 대시보드에 적합합니다. 최근에는 두 장점을 결합한 레이크하우스(Delta Lake, Apache Iceberg) 아키텍처가 주목받고 있으며, 데이터 거버넌스와 품질 관리가 핵심 과제입니다.

데이터베이스 마이그레이션은 시스템 업그레이드, 클라우드 전환, 벤더 변경 등의 이유로 수행됩니다. 마이그레이션 유형으로는 버전 업그레이드, 플랫폼 변경, 클라우드 마이그레이션이 있습니다. Big Bang 방식은 한 번에 전환하여 빠르지만 위험이 크고, 단계적 마이그레이션은 안전하지만 시간이 오래 걸립니다. 병렬 운영 방식은 두 시스템을 동시에 운영하며 점진적으로 전환합니다. 주요 고려사항으로는 데이터 타입 호환성, 스키마 변환, 애플리케이션 코드 수정, 성능 영향, 다운타임 최소화가 있습니다. 철저한 사전 테스트와 롤백 계획이 필수이며, 데이터 무결성 검증과 성능 테스트를 반복해야 합니다. AWS DMS, Azure Database Migration Service 등의 도구를 활용할 수 있으며, 전문 컨설팅을 통해 위험을 최소화하는 것이 좋습니다.

실시간 데이터 처리는 데이터가 생성되는 즉시 처리하여 결과를 제공하는 방식입니다. 배치 처리와 달리 지연 시간이 매우 중요하며, 스트리밍 데이터를 연속적으로 처리합니다. 스트림 처리 엔진은 Apache Kafka, Apache Storm, Apache Flink, Amazon Kinesis 등이 있으며, 이벤트 시간과 처리 시간의 차이를 고려한 윈도우 연산을 지원합니다. 스트림 데이터베이스는 실시간 쿼리를 지원하는 특수한 데이터베이스로, 시간 윈도우 기반 집계, 이벤트 패턴 매칭, 복합 이벤트 처리가 가능합니다. 실시간 추천, 사기 탐지, IoT 모니터링, 실시간 대시보드 등에 활용됩니다. 주요 고려사항으로는 처리량과 지연시간의 균형, 장애 처리와 정확성 보장, 백프레셀(backpressure) 처리가 있으며, 람다 아키텍처나 카파 아키텍처 등의 설계 패턴을 사용합니다.

데이터베이스 DevOps는 데이터베이스 변경을 애플리케이션 코드처럼 버전 관리하고 자동화하는 접근법입니다. 스키마 변경, 데이터 마이그레이션, 설정 변경을 코드로 관리하여 일관성과 추적성을 보장합니다. CI/CD 파이프라인에서는 데이터베이스 변경사항을 자동으로 테스트하고 배포합니다. 스키마 마이그레이션 스크립트를 버전 관리 시스템에 저장하고, Flyway나 Liquibase 같은 도구로 자동 적용합니다. 데이터베이스 단위 테스트, 통합 테스트, 성능 테스트를 자동화하고, 테스트 데이터를 일관되게 관리합니다. 환경별(개발, 테스트, 운영) 설정을 분리하고, 블루-그린 배포나 카나리 배포를 통해 무중단 배포를 구현합니다. 모니터링과 알람을 자동화하여 문제를 조기에 발견하고, 롤백 절차를 표준화합니다. 이를 통해 배포 속도 향상, 오류 감소, 협업 개선 효과를 얻을 수 있습니다.

개인정보보호법 강화로 데이터베이스에서 개인정보를 안전하게 처리하는 기법이 중요해졌습니다. 데이터 마스킹은 민감한 데이터를 실제값과 유사하지만 의미 없는 값으로 대체하는 기법입니다. 정적 마스킹은 테스트 환경 구축 시 사용하고, 동적 마스킹은 실시간으로 권한에 따라 다른 데이터를 제공합니다. 암호화는 데이터 자체를 변환하여 키 없이는 해독할 수 없게 만들며, 투명한 데이터 암호화(TDE)는 파일 레벨에서, 컬럼 레벨 암호화는 필드별로 적용됩니다. 토큰화는 민감 데이터를 무의미한 토큰으로 대체하고 별도 시스템에서 매핑 정보를 관리합니다. 차분 프라이버시는 통계적 분석 결과에 노이즈를 추가하여 개별 데이터를 보호하며, 동형 암호는 암호화된 상태에서 연산이 가능합니다. GDPR, CCPA 등의 규정 준수를 위해 데이터 생명주기 관리와 삭제 권한 지원도 중요합니다.

데이터베이스 모니터링은 시스템 안정성과 성능을 보장하기 위한 필수 활동입니다. 주요 모니터링 지표로는 응답시간, 처리량(TPS/QPS), 연결 수, CPU/메모리 사용률, I/O 대기시간, 락 대기시간이 있습니다. 슬로우 쿼리 로그를 통해 비효율적인 쿼리를 식별하고, 실행계획을 분석하여 최적화 포인트를 찾습니다. 대기 이벤트 분석으로 병목지점을 파악하고, 버퍼 캐시 히트율, 락 경합, 데드락 발생 빈도를 모니터링합니다. APM(Application Performance Monitoring) 도구나 데이터베이스 전용 모니터링 솔루션을 활용하여 실시간 모니터링과 알림을 설정합니다. 성능 기준선(baseline)을 설정하고 임계치 초과 시 자동 알림을 받습니다. 정기적인 성능 리포트를 통해 트렌드를 분석하고, 용량 계획과 성능 튜닝에 활용합니다. 장애 발생 시 신속한 원인 분석을 위해 성능 히스토리를 보관하고, 자동화된 진단 스크립트를 준비해야 합니다.