데이터베이스

SQLite는 애플리케이션 안에서 실행되는 SQL 데이터베이스 엔진이다. 이 문서는 파일과 연결의 관계, 자료형과 제약, 트랜잭션·쓰기 경쟁·WAL·백업을 실제 예제로 살펴보고, 로컬 저장소를 설계하고 운영할 때의 판단 기준을 설명한다. SQLite는 애플리케이션 내부에서 실행되는 관계형 데이터베이스 엔진이다. 별도의 데이터베이스 서버에 네트워크 요청을 보내는 대신, 프로세스에 연결된 라이브러리가 SQL을 처리하고 파일을 읽고

SQL은 관계형 데이터베이스의 구조와 데이터를 조회·변경하는 언어다. 이 문서는 고객과 주문 예제를 통해 조회·조인·집계·트랜잭션의 결과를 추적하고, NULL·중복·동시성·실행 계획에서 자주 생기는 오류와 해결 방법을 설명한다. SQL은 관계형 데이터베이스에서 자료 구조를 정의하고 데이터를 조회·변경하며 접근과 트랜잭션을 다루는 언어다. 테이블에서 필요한 행과 열을 고르고, 여러 테이블의 관계를 연결하고, 그룹별 합계나 순위를

인덱스와 정렬은 데이터베이스가 결과의 순서를 만드는 두 접근의 관계이다. 적절한 인덱스 순회로 별도의 정렬 단계를 줄일 수 있다. PostgreSQL의 B-tree는 키 순서로 결과를 제공할 수 있다. 옵티마이저는 인덱스 접근과 테이블 읽기 후 정렬의 비용을 비교한다. 최신 주문 20건을 ORDER BY created_at DESC LIMIT 20으로 찾을 때 적절한 인덱스가 필요한 앞부분만 읽도록 도울 수 있다. 인덱스가 있

GiST는 PostgreSQL에서 다양한 검색 구조를 구현하도록 제공하는 균형 트리 기반의 확장 가능한 인덱스 틀이다. 자료형과 연산자 클래스가 검색 의미를 제공하고 공통 접근 방식이 트리 관리를 담당한다. 공간 자료나 범위 등 여러 종류의 검색에 응용할 수 있다. 지리적 영역의 겹침이나 범위 포함 관계처럼 단순 동등 비교와 다른 조건을 해당 연산자 클래스와 연결해 검색할 수 있다. GiST라는 이름만으로 지원 연산이나 정확도

BRIN은 PostgreSQL에서 인접한 테이블 블록 범위의 요약 정보를 저장하는 인덱스 방식이다. 각 범위의 최솟값·최댓값 같은 요약으로 조건에 맞을 가능성이 없는 범위를 제외한다. 후보 범위 안의 실제 행은 다시 검사하므로 손실성 접근 방식이다. 시각 순서대로 쌓인 대용량 로그에서 날짜 조건을 조회할 때 물리적 배치와 값의 상관관계를 활용해 읽을 범위를 줄일 수 있다. 값이 물리적으로 뒤섞이면 제외할 범위가 줄어든다. 범위

GIN은 PostgreSQL의 Generalized Inverted Index로, 하나의 값 안에 들어 있는 구성 요소를 검색하는 데 사용하는 인덱스 방식이다. 키와 그 키가 나타나는 행의 목록을 연결한다. 자료형별 연산자 클래스가 값에서 키를 추출하고 질의 조건을 판정하는 방법을 정의한다. 문서에 특정 단어가 포함됐는지, 배열이 특정 값을 포함하는지, JSONB가 지원되는 조건에 맞는지 검색할 때 활용할 수 있다. 지원 연산

커버링 인덱스는 특정 질의가 필요로 하는 데이터를 인덱스 안에서 확보할 수 있도록 구성한 인덱스이다. 질의와의 관계로 판단하는 개념이다. 검색 키 외의 반환 열을 포함하면 원본 테이블 접근을 줄일 가능성이 생긴다. PostgreSQL의 index-only scan은 MVCC 가시성 조건도 함께 고려한다. 사용자 번호로 표시 이름만 읽는 질의에서 이름을 INCLUDE 열로 보관하면 인덱스에서 결과를 얻을 기회가 생긴다. 필요한

부분 인덱스는 조건을 만족하는 일부 행만 포함하는 데이터베이스 인덱스이다. PostgreSQL에서는 인덱스 정의의 WHERE 절로 대상을 정한다. 전체 자료 중 자주 검색하는 부분을 작게 유지한다. 질의 조건이 인덱스의 조건을 만족한다고 계획 단계에서 판단할 수 있어야 유용하다. 미처리 주문만 자주 조회한다면 처리 완료 행을 제외하는 인덱스로 크기와 유지 비용을 줄이는 구성을 검토할 수 있다. 임의의 조건식을 항상 자동으로 동

표현식 인덱스는 원래 열 값 대신 함수나 식으로 계산한 값을 인덱싱하는 방식이다. 조회 때 자주 사용하는 변환 결과를 저장해 탐색에 활용한다. PostgreSQL에서는 lower(column) 같은 표현식에 인덱스를 만들 수 있다. 대소문자를 구분하지 않고 이름을 찾는 질의가 lower(name)을 사용한다면 같은 표현식의 인덱스를 검토할 수 있다. 조회에 쓰는 표현식과 인덱스 조건의 호환성을 확인해야 한다. 입력이 바뀔 때

유일 인덱스는 인덱스 키의 중복을 제한하는 데이터베이스 구조이다. 검색 지원과 함께 데이터의 유일성 규칙을 강제한다. 여러 열의 인덱스라면 그 값 조합의 중복을 검사한다. PostgreSQL은 기본 키나 유일 제약을 정의할 때 이를 구현하는 인덱스를 자동으로 만들 수 있다. 같은 조직 안에서 사용자 이름이 중복되면 안 된다면 (organization_id, username)의 조합을 유일하게 만들 수 있다. NULL을 같은 값

복합 인덱스는 두 개 이상의 열을 함께 키로 사용하는 데이터베이스 인덱스이다. 열 순서와 인덱스 종류가 사용 방식에 영향을 준다. B-tree에서는 앞쪽 열의 동등 조건과 그다음 범위 조건이 탐색 범위를 줄이는 데 중요하다. 뒤쪽 조건도 도움이 되지만 항상 같은 방식으로 범위를 좁히지는 않는다. 고객 번호와 주문 시각을 함께 조회한다면 (customer_id, created_at) 인덱스를 고려할 수 있다. 고객별 기간 조회의

데이터베이스 인덱스는 조건에 맞는 행을 효율적으로 찾도록 별도로 유지하는 접근 구조이다. 여기서는 PostgreSQL을 예로 설명한다. 열이나 식에 대한 검색 구조를 만들면 전체 행을 읽는 대신 필요한 위치를 좁힐 수 있다. 옵티마이저는 통계와 비용을 고려해 실제 사용 여부를 결정한다. 주문 번호로 한 건을 찾는 질의가 많다면 해당 열의 인덱스가 탐색 비용을 줄일 수 있다. 조인이나 갱신 대상 검색에도 활용된다. 인덱스는 저장

쿼리 실행 계획은 데이터베이스가 질의를 처리하기 위해 선택한 스캔·조인·정렬 등의 연산 구조이다. EXPLAIN으로 추정 계획을 확인한다. 추정 행 수와 비용은 통계와 모형에 기반하며 실제 경과 시간과 같은 단위라고 가정하지 않는다. 전체 스캔 대신 인덱스 스캔을 선택했는지, 조인 전에 행이 얼마나 줄어드는지 살피면 느린 질의의 원인을 좁힐 수 있다. PostgreSQL의 EXPLAIN ANALYZE는 실제로 문장을 실행한다.

SQL 뷰는 질의에 이름을 붙여 테이블처럼 참조할 수 있게 하는 데이터베이스 객체이다. 일반 뷰는 결과를 영구 저장하는 물리화된 뷰와 다르다. 반복되는 조인과 필요한 열의 선택을 정의해 인터페이스를 단순화한다. 뷰를 조회할 때 실제 데이터 접근 방식은 실행 계획으로 결정된다. 직원 테이블에서 공개 가능한 이름과 부서만 선택한 뷰를 만들어 소비자가 원본의 모든 열을 직접 다루지 않도록 할 수 있다. 뷰의 존재만으로 보안이 완성되

SQL 제약 조건은 저장되는 데이터가 지켜야 할 규칙을 데이터베이스에 선언하는 기능이다. NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK 등이 있다. 애플리케이션의 사전 검사와 함께 데이터 무결성을 지키는 경계가 된다. 주문 행의 고객 번호에 외래 키를 두면 존재하지 않는 고객을 참조하는 저장을 막을 수 있다. NULL과 고유성의 관계, CHECK의 NULL 결과 처리, 제약 검사 시점

SQL 집합 연산은 여러 질의의 결과 행을 합치거나 공통·차집합 부분을 구하는 기능이다. UNION, INTERSECT, EXCEPT가 대표적이다. 각 질의의 열 수와 대응하는 타입이 호환되어야 한다. 기본적인 UNION은 중복을 제거하고 UNION ALL은 중복 행을 유지한다. 올해 고객과 지난해 고객 목록을 UNION하면 양쪽에 속한 고객을 포함한 집합을 얻을 수 있다. 중복 제거 기준은 선택한 전체 열이다. UNION A

SQL 윈도 함수는 현재 행과 관련된 여러 행을 대상으로 계산하면서도 행별 결과를 유지하는 기능이다. OVER 절의 PARTITION BY, ORDER BY와 프레임으로 계산 범위를 정한다. 일반 GROUP BY 집계처럼 여러 행을 한 행으로 줄이지 않는다. 부서별 급여 순위를 계산해 각 직원 행에 함께 표시하거나 날짜순 누적 합계를 구할 수 있다. 윈도 안의 ORDER BY는 최종 출력 순서를 보장하지 않는다. 동률 처리와

공통 테이블 식은 WITH 절에서 이름을 붙인 보조 질의를 정의하고 같은 SQL 문장 안에서 참조하는 기능이다. 복잡한 질의를 단계별로 나누어 읽기 쉽게 만들 수 있다. 이름을 붙였다고 항상 결과가 별도 저장되거나 한 번만 계산되는 것은 아니다. 월별 매출을 먼저 계산하는 CTE를 만들고 바깥 질의에서 특정 기준 이상의 월만 선택할 수 있다. 최적화와 물리화 여부는 DB 및 질의 형태에 따라 다르다. 읽기 쉬운 표현과 빠른 실

SQL HAVING은 그룹화 및 집계 결과에 조건을 적용하는 절이다. 개별 입력 행을 거르는 WHERE와 구별한다. WHERE를 통과한 행들이 그룹화된 뒤 HAVING 조건으로 결과 그룹을 선택한다. 집계 함수의 결과를 조건에 사용할 수 있다. GROUP BY customer_id HAVING COUNT(*) >= 3은 주문 수가 3 이상인 고객 그룹을 찾는 형태이다. 행 조건을 HAVING으로만 처리하면 의도가 흐려질 수 있

SQL GROUP BY는 같은 그룹 키를 가진 행을 묶어 그룹 단위 집계를 수행하는 절이다. SUM, COUNT, AVG 등의 집계 함수가 각 그룹에 적용된다. 윈도 함수와 다르다. SELECT category, COUNT(*) FROM products GROUP BY category는 분류별 상품 행 수를 구하는 예이다. COUNT(*)는 행을 세지만 COUNT(column)은 해당 열의 NULL을 제외한다. 그룹에 속하지

SQL JOIN은 관계 사이의 조건을 이용해 행들을 결합하는 연산이다. 내부 조인과 외부 조인 등 여러 종류가 있다. 한 행에 대응하는 상대 행이 여러 개면 결과도 여러 행으로 늘어난다. 조인 조건과 관계의 일대일·일대다 성질을 함께 확인해야 한다. 주문 테이블의 customer_id와 고객 테이블의 id를 연결하면 주문 정보와 고객 이름을 함께 조회할 수 있다. 의도하지 않은 다대다 조인은 합계의 중복을 일으킬 수 있다. 외

SQL SELECT는 테이블이나 질의 결과에서 필요한 열과 행을 선택하는 질의문이다. 표현식 계산과 집계 등도 함께 수행할 수 있다. FROM으로 입력 관계를 정하고 WHERE로 행을 거르며 SELECT 목록으로 결과 열을 표현한다. SQL의 논리적 처리 설명과 실제 실행 계획은 구별한다. SELECT name FROM users WHERE active = true는 활성 사용자 이름을 조회하는 예이다. 문법과 불리언 표현은

데이터베이스 백업은 장애나 실수 뒤 데이터를 복원하기 위해 별도로 보관하는 복구 자료이다. 논리 백업은 테이블 정의와 행 등을 추출하고 물리 백업은 데이터 파일과 복구에 필요한 정보를 보관한다. 일관된 시점과 복원 절차를 확보해야 한다. 운영 데이터와 같은 디스크에만 복사본을 두면 디스크 손실을 함께 겪을 수 있다. 별도 보관 후 실제 복원해 내용과 소요 시간을 확인한다. 복제본도 잘못된 삭제를 그대로 받을 수 있어 백업을 완

시점 복구는 기본 백업과 이후 로그를 이용해 데이터베이스를 특정 시각이나 복구 지점까지 되돌리는 복구 방식이다. 복원 가능한 기본 백업에서 시작해 필요한 로그를 순서대로 재실행하고 지정한 지점에서 멈춘다. PostgreSQL에서는 연속 WAL 아카이빙과 연결된다. 오후 2시의 잘못된 삭제 직전으로 복구하려면 그 이전 백업과 해당 지점까지 이어지는 로그가 필요하다. 로그 일부가 빠지면 원하는 시점에 도달하지 못할 수 있다. 복구

파티셔닝은 하나의 논리적인 테이블을 규칙에 따라 여러 물리적 부분으로 나누는 기법이다. 범위·목록·해시 기준 등을 사용한다. 질의 조건이 파티션 경계와 맞으면 관련 없는 부분을 제외하는 파티션 가지치기를 활용할 수 있다. 월별 주문을 주문일 기준으로 나누면 특정 월 조회와 오래된 데이터 관리 단위를 명확히 할 수 있다. 파티션이 늘었다고 모든 질의가 빨라지지는 않는다. 키와 맞지 않는 질의, 고유 제약 조건, 파티션 생성 및

비관적 잠금은 충돌 가능성을 고려해 데이터에 접근할 때 잠금을 획득하고 다른 작업의 접근을 조정하는 방식이다. 읽고 갱신할 행에 SELECT FOR UPDATE 같은 잠금을 사용하는 구현이 대표적이다. 잠금 종류와 유지 기간은 데이터베이스 및 트랜잭션 경계에 따른다. 좌석 예약에서 한 행을 잠근 뒤 예약 가능 여부를 검사하고 갱신하면 같은 행의 경쟁 처리를 조정할 수 있다. 오래 잠근 채 사용자 입력이나 외부 통신을 기다리면

데이터베이스 교착 상태는 여러 트랜잭션이 서로가 가진 잠금의 해제를 기다려 어느 쪽도 진행하지 못하는 상태이다. 순환 대기가 원인이다. 데이터베이스는 교착 상태를 탐지해 관련 트랜잭션 중 하나를 중단시키는 방식으로 진행을 회복할 수 있다. T1이 행 A를 잠그고 B를 기다리며, T2가 B를 잠그고 A를 기다리면 순환이 생긴다. 여러 객체의 잠금을 일정한 순서로 획득하면 위험을 줄일 수 있다. 중단된 트랜잭션은 전체 업무 단위로

읽기 커밋은 다른 트랜잭션의 아직 커밋되지 않은 변경을 읽지 않도록 하는 격리 수준이다. PostgreSQL의 일반 SELECT는 문장이 시작할 때의 스냅샷을 읽는다. 같은 트랜잭션이라도 다음 문장은 새로 커밋된 내용을 볼 수 있다. 첫 조회에서 재고가 10이었더라도 다른 트랜잭션이 갱신하고 커밋하면 다음 조회에서는 9가 보일 수 있다. 한 번 읽은 값이 트랜잭션 내내 유지된다고 가정하면 안 된다. 읽고 판단한 뒤 쓰는 업무는

트랜잭션 격리 수준은 동시에 실행되는 트랜잭션 사이에서 어떤 읽기와 결과를 허용할지 정하는 보장 수준이다. 읽기 미커밋·읽기 커밋·반복 읽기·직렬화 가능 등이 대표적이다. 같은 이름이라도 데이터베이스 구현이 더 강한 보장을 제공할 수 있다. PostgreSQL의 반복 읽기는 같은 트랜잭션의 스냅샷을 유지하고 팬텀 읽기도 방지하지만 모든 직렬화 이상을 막지는 않는다. 강한 격리는 대기나 실패 후 재시도 비용을 만들 수 있다. 이

MVCC는 데이터의 여러 버전을 관리해 동시 트랜잭션이 적절한 시점의 데이터를 읽도록 하는 동시성 제어 방식이다. 각 읽기에 어떤 버전이 보일지 스냅샷과 트랜잭션 상태를 기준으로 결정한다. 읽기와 쓰기의 충돌을 줄일 수 있지만 모든 잠금이 없어지는 것은 아니다. 다른 트랜잭션이 행을 갱신 중이어도 독자는 자신에게 보이는 이전 버전을 읽을 수 있다. 정확한 가시성 범위는 격리 수준에 따라 달라진다. 오래 열린 트랜잭션은 이전 버

체크포인트는 데이터베이스의 복구 진행 기준을 마련하기 위해 메모리의 변경 상태를 저장 장치에 반영하는 과정과 그 기준점을 가리킨다. PostgreSQL은 변경된 버퍼의 쓰기를 분산해 수행하고 복구에 필요한 로그 범위를 관리한다. 체크포인트 주기는 입출력 부담과 복구 시간에 영향을 준다. 체크포인트가 너무 자주 발생하면 쓰기 부하가 증가하고, 간격이 길면 장애 뒤 재실행할 로그가 늘어날 수 있다. 체크포인트는 사용자 트랜잭션의

WAL은 변경 내용을 데이터 페이지보다 먼저 지속성 있는 로그에 기록하는 복구 원칙이다. Write-Ahead Logging의 약자이다. 장애가 나도 기록된 로그를 이용해 필요한 변경을 재실행할 수 있게 한다. 데이터 파일의 모든 변경을 매 커밋마다 즉시 같은 방식으로 쓰는 것과 구별된다. 커밋된 변경의 로그는 남았지만 데이터 페이지가 아직 저장되지 않았다면 재시작 복구에서 로그를 적용할 수 있다. 로그가 있다는 사실만으로 백

Apache Cassandra는 여러 노드에 데이터를 분산하고 복제하는 데이터베이스이다. 파티션을 중심으로 데이터를 배치하고, 쿼리에서 필요한 접근 경로에 맞추어 테이블을 설계한다. CQL의 표면적인 문법이 SQL과 비슷하더라도 관계형 데이터베이스의 조인 중심 설계와는 차이가 있다. Cassandra는 Dynamo 계열 분산 설계와 LSM 계열 로컬 저장 구조를 결합한다. 파티션 키에 따른 데이터 배치, 복제, 노드 상태 전파

MyRocks는 RocksDB를 기반으로 SQL 서버의 테이블과 인덱스를 저장하는 엔진이다. 쓰기 증폭과 압축 효율을 중요한 설계 대상으로 삼는다. RocksDB 자체와 달리 관계형 데이터를 키·값 레코드로 변환하는 계층이 포함된다. SQL 서버는 문장 처리와 관계형 인터페이스를 제공하고, MyRocks는 테이블·인덱스 표현을 RocksDB의 키와 값으로 대응시킨다. 예를 들어 기본 키로 행을 찾는 연산과 보조 인덱스로 후보를

RocksDB는 응용 프로그램 안에서 사용하는 키·값 저장 라이브러리이다. 독립적인 SQL 서버와 달리 저장 기능을 프로그램에 연결해 사용하는 구성 요소이며, LSM 계열 구조와 컴팩션을 중심으로 저장 성능을 조정한다. 응용 프로그램은 Put, Get, Delete와 같은 연산으로 키·값 데이터에 접근한다. 네트워크 프로토콜, 사용자 권한, 데이터 분산 같은 기능은 RocksDB를 사용하는 상위 시스템이 별도로 구성할 수 있다

InnoDB는 MySQL에서 행 저장, 인덱스, 트랜잭션과 동시성 제어를 담당하는 저장 엔진이다. 커밋과 롤백, 장애 복구, 다중 버전 동시성 제어를 제공한다. 여기서는 MySQL 8.4 문서를 기준으로 구조와 동작을 설명한다. InnoDB의 테이블 데이터는 클러스터형 인덱스의 리프에 저장된다. 일반적으로 기본 키가 그 기준이 되므로 기본 키 설계는 행의 배치와 보조 인덱스 비용에도 영향을 준다. 기본 키가 없을 때 내부 식별

MySQL은 SQL을 사용해 테이블의 데이터를 정의하고 조회·변경하는 관계형 데이터베이스 관리 시스템이다. SQL을 처리하는 서버 계층과 실제 데이터를 저장하는 스토리지 엔진을 구별하는 구조가 특징이다. MySQL과 InnoDB는 밀접하게 연결되지만 같은 대상을 가리키는 이름은 아니다. 응용 프로그램은 연결을 열고 SQL을 서버에 전달한다. 서버는 문장을 해석하고 실행 계획을 세우며, 저장 엔진은 레코드와 인덱스에 접근한다.

MongoDB는 BSON 문서를 컬렉션에 저장하는 데이터베이스이다. 문서는 중첩 객체와 배열을 포함할 수 있으며, 같은 컬렉션의 문서가 반드시 동일한 필드를 가질 필요는 없다. 이러한 유연성은 스키마 설계가 불필요하다는 뜻이 아니다. 자주 함께 읽는 데이터를 함께 저장하면 필요한 정보를 적은 접근으로 가져올 수 있다. 반면 함께 바뀌지 않거나 크기가 계속 커지는 데이터는 별도 문서와 참조로 나눌 수 있다. 임베딩과 참조의 선택

Redis는 키를 통해 여러 종류의 자료 구조를 다루는 메모리 중심 저장소이다. 문자열 값만 저장하는 캐시로 한정되지 않으며, 해시·리스트·집합·정렬 집합 등 데이터 형태에 맞는 명령을 제공한다. 사용자별 설정처럼 필드가 있는 값은 해시로, 점수 순위는 정렬 집합처럼 문제에 맞는 자료 구조로 표현할 수 있다. 설계할 때는 키 수만 세기보다 값의 크기와 각 명령이 처리하는 원소 수를 함께 본다. 한 번의 명령이라고 해서 모든 연

MariaDB는 MySQL에서 갈라져 발전한 관계형 데이터베이스 서버이다. SQL을 통한 데이터 정의·조회·갱신을 제공하며, 서버 기능과 저장 엔진을 구별해서 이해해야 한다. MySQL과 관련이 깊지만 별개의 제품과 릴리스 체계를 가진다. 응용 프로그램은 연결과 SQL을 통해 서버를 사용하고, 저장 엔진은 테이블 데이터를 다루는 하위 계층을 맡는다. 테이블의 엔진에 따라 트랜잭션과 저장 기능의 지원 범위가 달라질 수 있다. 서