데이터베이스 기본 개념과 용어, 한 번에 정리하기
데이터베이스를 공부하다 보면 테이블, 스키마, 키, 트랜잭션, 인덱스, 정규화, ACID, 샤딩처럼 알 듯 모를 듯한 용어들이 끝없이 쏟아집니다. 하나하나 검색하면 그때는 이해되는데, 돌아서면 서로 어떻게 연결되는지가 다시 흐릿해집니다.
필요할 때마다 흩어진 글을 뒤지는 대신, 한 번 쭉 읽으면 전체 지도가 그려지는 정리가 있으면 좋겠다고 생각했습니다.
데이터베이스를 다루기 위해 알아야 할 기본 개념과 용어는 무엇이고, 서로 어떻게 이어질까요?
이 글에서 다루는 내용
이 글은 데이터베이스를 처음 배우는 사람을 독자로 상정한 기본 개념·용어 레퍼런스입니다. 데이터베이스가 무엇인지부터 시작해 관계형 모델의 구성요소, SQL, 관계와 정규화, 트랜잭션과 ACID, 인덱스, 그리고 관계형을 넘어선 NoSQL과 확장 전략까지 순서대로 짚습니다. 각 단원 끝의 Recap으로 핵심만 다시 잡을 수 있고, 마지막 용어 사전에서 개별 용어를 빠르게 찾아볼 수 있습니다. 특정 제품(MySQL·PostgreSQL 등)의 세부 문법보다 어디서나 통하는 개념에 초점을 둡니다.
- 1. 데이터베이스와 DBMS
- 2. 관계형 데이터베이스의 구성요소
- 3. SQL: 데이터베이스와 대화하는 언어
- 4. 관계와 정규화
- 5. 트랜잭션과 ACID
- 6. 인덱스: 빠른 조회의 비밀
- 7. 관계형을 넘어서: NoSQL과 확장
- 용어 사전
- References
1. 데이터베이스와 DBMS
데이터베이스(Database) 는 여러 사람이 함께 쓰기 위해 구조화하여 저장한 데이터의 모음입니다. 그런데 우리가 흔히 "DB를 쓴다"고 할 때 실제로 다루는 것은 데이터 그 자체가 아니라, 그 데이터를 관리해주는 소프트웨어입니다. 이 소프트웨어를 DBMS(Database Management System) 라고 부릅니다.
DBMS는 데이터를 저장·조회·수정·삭제하고, 여러 사용자가 동시에 접근해도 데이터가 깨지지 않도록 지키며, 권한과 백업까지 책임집니다. 파일에 직접 데이터를 쓰지 않고 DBMS를 거치는 이유가 여기에 있습니다.
DBMS는 데이터를 어떤 모델로 표현하느냐에 따라 갈립니다. 그중 가장 널리 쓰이는 것이 데이터를 표(table) 형태로 다루는 관계형 데이터베이스(RDBMS, Relational DBMS)입니다.
- RDBMS: MySQL, PostgreSQL, Oracle, SQL Server, SQLite 등. 데이터를 행과 열로 이루어진 테이블에 담고, 테이블 사이의 관계로 표현합니다. 이 글의 2~6장이 주로 다루는 대상입니다.
- NoSQL: MongoDB, Redis, Cassandra 등. 표가 아닌 다른 구조(문서·키값·그래프 등)로 데이터를 다룹니다. 7장에서 살펴봅니다.
Recap
데이터베이스는 구조화하여 저장한 데이터의 모음이고, 그것을 관리하는 소프트웨어가 DBMS입니다. DBMS는 데이터의 저장·조회·동시 접근·권한을 책임집니다. 데이터를 표 형태로 다루는 관계형 데이터베이스(RDBMS)가 가장 널리 쓰이며, 표가 아닌 구조를 쓰는 NoSQL이 그 대안으로 존재합니다.
2. 관계형 데이터베이스의 구성요소
관계형 데이터베이스에서 데이터는 테이블(table) 에 담깁니다. 테이블은 스프레드시트 한 장과 비슷하게 생겼습니다.
- 행(row, 레코드/튜플): 가로 한 줄. 하나의 데이터 항목입니다. 예를 들어 사용자 한 명.
- 열(column, 필드/속성): 세로 한 칸. 데이터의 속성입니다. 예를 들어 이메일, 이름.
- 스키마(schema): 테이블이 어떤 열들로, 각 열이 어떤 자료형(정수·문자열·날짜 등)으로 이루어지는지에 대한 설계도. 데이터가 지켜야 할 틀입니다.
키(Key): 행을 구별하는 기준
수많은 행 중에서 특정 행을 정확히 가리키려면 기준이 필요합니다. 그 기준이 키입니다.
- 기본키(Primary Key, PK): 각 행을 유일하게 식별하는 열. 중복될 수 없고 비어 있을 수 없습니다(NOT NULL). 테이블마다 보통 하나 둡니다.
id같은 열이 대표적입니다. - 외래키(Foreign Key, FK): 다른 테이블의 기본키를 가리키는 열. 테이블 사이를 잇는 다리 역할을 합니다. 예를 들어
주문테이블의user_id가사용자테이블의id를 가리킵니다. - 후보키·복합키: 기본키가 될 수 있는 후보를 후보키(candidate key), 여러 열을 묶어 하나의 키로 삼은 것을 복합키(composite key)라 합니다.
- 자연키 vs 대리키: 이메일처럼 업무상 의미가 있는 값을 키로 쓰면 자연키(natural key), 의미 없이 식별만을 위해 새로 만든
id를 쓰면 대리키(surrogate key)입니다. 실무에서는 대리키를 즐겨 씁니다.
제약조건(Constraint): 데이터의 규칙
테이블에는 "이런 데이터는 허용하지 않는다"는 규칙을 걸 수 있습니다. 이를 제약조건이라 하고, DBMS가 강제로 지켜줍니다.
| 제약조건 | 의미 |
|---|---|
PRIMARY KEY | 행을 유일하게 식별 (중복·NULL 불가) |
FOREIGN KEY | 다른 테이블의 키를 참조, 참조 무결성 보장 |
UNIQUE | 값이 중복되지 않도록 강제 |
NOT NULL | 값이 비어 있을 수 없음 |
CHECK | 특정 조건을 만족하는 값만 허용 (예: 나이 ≥ 0) |
DEFAULT | 값을 지정하지 않으면 쓰이는 기본값 |
여기서 NULL은 "값이 없음/알 수 없음"을 뜻하는 특별한 상태입니다. 숫자 0이나 빈 문자열과는 다르며, NULL을 다루는 방식은 종종 미묘한 버그의 원인이 되므로 개념을 정확히 잡아두는 것이 좋습니다.
Recap
관계형 데이터베이스는 데이터를 테이블에 담고, 테이블은 행(데이터 항목)과 열(속성)로 이루어지며 스키마가 그 틀을 정의합니다. 기본키(PK)는 각 행을 유일하게 식별하고, 외래키(FK)는 다른 테이블을 참조해 관계를 잇습니다. UNIQUE·NOT NULL·CHECK 같은 제약조건으로 데이터의 규칙을 DBMS가 강제하며, NULL은 "값이 없음"을 뜻하는 별도의 상태입니다.
3. SQL: 데이터베이스와 대화하는 언어
관계형 데이터베이스와 대화할 때 쓰는 언어가 SQL(Structured Query Language) 입니다. SQL 명령은 역할에 따라 몇 갈래로 나뉩니다.
| 분류 | 이름 | 대표 명령 | 하는 일 |
|---|---|---|---|
| DDL | 데이터 정의어 | CREATE, ALTER, DROP | 테이블·스키마 구조를 만들고 바꿈 |
| DML | 데이터 조작어 | INSERT, UPDATE, DELETE | 데이터를 넣고 바꾸고 지움 |
| DQL | 데이터 질의어 | SELECT | 데이터를 조회함 |
| DCL | 데이터 제어어 | GRANT, REVOKE | 권한을 부여·회수함 |
| TCL | 트랜잭션 제어어 | COMMIT, ROLLBACK | 트랜잭션을 확정·취소함 (5장) |
데이터를 다루는 가장 기본적인 네 가지 동작(생성·조회·수정·삭제)을 흔히 CRUD(Create, Read, Update, Delete)라 부르며, 각각 INSERT·SELECT·UPDATE·DELETE에 대응됩니다.
조회의 핵심: SELECT
가장 자주 쓰는 것은 조회(SELECT)입니다. 기본 형태는 다음과 같습니다.
-- users 테이블에서 나이가 20 이상인 행의 이름과 이메일을, 이름 순으로 조회
SELECT name, email
FROM users
WHERE age >= 20
ORDER BY name;
SELECT: 어떤 열을 가져올지FROM: 어떤 테이블에서WHERE: 어떤 조건의 행만ORDER BY: 어떤 순서로GROUP BY/HAVING: 특정 열 값으로 묶어 집계(합계·개수 등)하고, 집계 결과를 다시 거를 때
JOIN: 흩어진 테이블을 잇기
관계형 데이터베이스는 데이터를 여러 테이블에 나눠 담기 때문에, 조회할 때 이들을 다시 이어붙일 일이 많습니다. 이때 쓰는 것이 JOIN입니다.
-- 주문(orders)과 그 주문을 한 사용자(users)를 이어서 조회
SELECT orders.id, users.name
FROM orders
JOIN users ON orders.user_id = users.id;
| JOIN 종류 | 결과 |
|---|---|
INNER JOIN | 양쪽 모두에 매칭되는 행만 |
LEFT (OUTER) JOIN | 왼쪽 테이블은 전부, 오른쪽은 매칭되는 것만(없으면 NULL) |
RIGHT (OUTER) JOIN | 오른쪽 테이블은 전부, 왼쪽은 매칭되는 것만 |
FULL (OUTER) JOIN | 양쪽 모두 전부, 매칭 안 되는 쪽은 NULL |
CROSS JOIN | 두 테이블의 모든 조합(곱집합) |
Recap
SQL은 관계형 데이터베이스와 대화하는 언어로, 구조를 정의하는 DDL, 데이터를 조작하는 DML, 조회하는 DQL(SELECT), 권한을 제어하는 DCL, 트랜잭션을 제어하는 TCL로 나뉩니다. 데이터의 기본 네 동작은 CRUD이며, 조회는 SELECT ... FROM ... WHERE ... ORDER BY가 기본 골격입니다. 여러 테이블에 흩어진 데이터는 JOIN으로 이어붙이며, INNER·LEFT·RIGHT·FULL·CROSS로 매칭 방식이 갈립니다.
4. 관계와 정규화
관계형 데이터베이스의 이름이 "관계형"인 이유는, 데이터를 여러 테이블로 나누고 관계(relationship) 로 잇기 때문입니다. 관계는 세 종류로 정리됩니다.
- 1:1 (일대일): 한 행이 상대 테이블의 한 행과만 대응. 예: 사용자 ↔ 사용자 상세정보.
- 1:N (일대다): 한 행이 상대 테이블의 여러 행과 대응. 가장 흔합니다. 예: 사용자 한 명 ↔ 주문 여러 건.
- N:M (다대다): 양쪽 모두 여러 행과 대응. 예: 학생 ↔ 수강 과목. 이 관계는 보통 중간에 연결 테이블(join table)을 두어 두 개의 1:N으로 풀어냅니다.
정규화(Normalization): 중복을 줄이는 설계
정규화는 데이터의 중복과 이상 현상을 줄이기 위해 테이블을 잘 나누는 설계 과정입니다. 같은 정보가 여러 곳에 중복되면, 수정할 때 일부만 바뀌어 데이터가 어긋나는 문제(갱신 이상)가 생기기 때문입니다. 정규화는 단계(정규형, Normal Form)로 나뉩니다.
- 제1정규형(1NF): 각 칸에는 더 쪼갤 수 없는 하나의 값만. (한 칸에 여러 값을 콤마로 넣지 않기)
- 제2정규형(2NF): 1NF를 만족하고, 복합키의 일부에만 의존하는 열이 없도록 분리.
- 제3정규형(3NF): 2NF를 만족하고, 기본키가 아닌 열이 다른 일반 열에 의존(이행적 종속)하지 않도록 분리.
실무에서는 보통 3NF 정도까지를 기본으로 삼습니다. 다만 정규화를 지나치게 밀어붙이면 JOIN이 많아져 조회가 느려질 수 있어, 성능을 위해 일부러 중복을 허용하는 반정규화(denormalization) 를 선택하기도 합니다. 정규화와 반정규화는 옳고 그름이 아니라 트레이드오프입니다.
Recap
관계형 데이터베이스는 데이터를 여러 테이블로 나누고 1:1·1:N·N:M 관계로 잇습니다(N:M은 연결 테이블로 풀어냄). 정규화는 중복과 갱신 이상을 줄이려 테이블을 나누는 설계 과정으로, 1NF(값의 원자성)·2NF(부분 종속 제거)·3NF(이행적 종속 제거)의 단계를 밟습니다. 조회 성능을 위해 일부러 중복을 허용하는 반정규화도 있으며, 둘의 선택은 트레이드오프입니다.
5. 트랜잭션과 ACID
트랜잭션(transaction) 은 "하나의 논리적 작업으로 묶여, 전부 성공하거나 전부 실패해야 하는 여러 연산의 묶음"입니다. 계좌 이체가 고전적인 예입니다. A에서 돈을 빼고 B에 넣는 두 작업은 반드시 함께 성공해야 합니다. 하나만 성공하면 돈이 사라지거나 복제됩니다.
BEGIN; -- 트랜잭션 시작
UPDATE accounts SET balance = balance - 1000 WHERE id = 'A';
UPDATE accounts SET balance = balance + 1000 WHERE id = 'B';
COMMIT; -- 둘 다 성공하면 확정. 문제가 생기면 ROLLBACK으로 전부 취소
ACID: 트랜잭션이 지키는 네 가지 성질
믿을 수 있는 트랜잭션이 갖춰야 할 성질을 머리글자로 ACID라 부릅니다.
- 원자성(Atomicity): 전부 성공 아니면 전부 취소. 중간 상태로 남지 않습니다.
- 일관성(Consistency): 트랜잭션 전후로 데이터가 정해진 규칙(제약조건 등)을 항상 만족합니다.
- 격리성(Isolation): 동시에 실행되는 트랜잭션들이 서로 간섭하지 않습니다.
- 지속성(Durability): 커밋된 결과는 시스템이 꺼져도 사라지지 않습니다.
격리 수준(Isolation Level)
격리성을 완벽하게 지키면 안전하지만 성능이 떨어집니다. 그래서 DBMS는 안전성과 성능 사이에서 고를 수 있는 격리 수준을 제공합니다. 수준이 낮을수록 빠르지만 아래의 이상 현상이 나타날 수 있습니다.
- 더티 리드(dirty read): 아직 커밋되지 않은 다른 트랜잭션의 값을 읽음.
- 반복 불가능 읽기(non-repeatable read): 같은 행을 두 번 읽었는데 값이 달라짐.
- 팬텀 리드(phantom read): 같은 조건으로 두 번 조회했는데 행의 개수가 달라짐.
| 격리 수준 | 더티 리드 | 반복 불가능 읽기 | 팬텀 리드 |
|---|---|---|---|
| Read Uncommitted | 발생 | 발생 | 발생 |
| Read Committed | 방지 | 발생 | 발생 |
| Repeatable Read | 방지 | 방지 | 발생 |
| Serializable | 방지 | 방지 | 방지 |
동시성 문제를 막기 위해 DBMS는 내부적으로 잠금(lock) 을 사용합니다. 한 트랜잭션이 데이터를 다루는 동안 다른 트랜잭션의 접근을 막거나 대기시키는 장치입니다. 서로가 서로의 잠금을 기다리며 영원히 멈추는 상황을 교착 상태(deadlock) 라 합니다.
Recap
트랜잭션은 전부 성공하거나 전부 실패해야 하는 연산의 묶음이며, COMMIT으로 확정하고 ROLLBACK으로 취소합니다. 믿을 수 있는 트랜잭션의 네 성질이 ACID — 원자성·일관성·격리성·지속성입니다. 격리성은 성능과의 트레이드오프라 Read Uncommitted부터 Serializable까지 격리 수준으로 조절하며, 낮을수록 더티 리드·반복 불가능 읽기·팬텀 리드 같은 이상 현상이 나타납니다. 동시성은 잠금(lock)으로 제어되고, 서로를 기다리다 멈추면 교착 상태입니다.
6. 인덱스: 빠른 조회의 비밀
데이터가 수백만 건인 테이블에서 특정 행을 찾을 때, 처음부터 끝까지 전부 훑으면(풀 스캔, full scan) 느립니다. 인덱스(index) 는 이 조회를 빠르게 하기 위한 별도의 자료구조입니다. 책 뒤의 "찾아보기"와 정확히 같은 발상입니다 — 원하는 단어가 몇 페이지에 있는지 미리 정렬해 둔 목록이지요.
대부분의 DBMS에서 인덱스는 B-트리(B-Tree) 계열의 자료구조로 만들어집니다. 값이 정렬된 채로 트리에 담겨 있어, 전체를 훑지 않고도 원하는 값에 빠르게(로그 시간에) 도달할 수 있습니다.
클러스터드 vs 논클러스터드
- 클러스터드 인덱스(clustered index): 데이터 행 자체가 인덱스 순서대로 물리적으로 정렬되어 저장됩니다. 테이블당 하나만 가능하며, 보통 기본키가 이 역할을 합니다.
- 논클러스터드 인덱스(non-clustered index): 데이터와 별도로, 정렬된 키와 "실제 행의 위치"만 담아둡니다. 한 테이블에 여러 개 만들 수 있습니다.
인덱스는 공짜가 아닙니다
인덱스는 조회를 빠르게 하지만 대가가 있습니다.
- 쓰기 비용: 데이터를 넣거나 바꿀 때마다 인덱스도 함께 갱신해야 하므로
INSERT·UPDATE가 느려집니다. - 저장 공간: 인덱스 자체가 디스크를 차지합니다.
- 카디널리티(cardinality): 값의 다양성이 낮은 열(예: 성별)에 건 인덱스는 효과가 적습니다. 값이 다양한 열일수록 인덱스가 잘 듣습니다.
그래서 인덱스는 "많이 걸수록 좋은 것"이 아니라, 자주 조회하는 조건에 선별적으로 거는 것입니다. 조회와 쓰기 사이의 트레이드오프인 셈입니다.
Recap
인덱스는 전체를 훑지 않고 원하는 행에 빠르게 도달하기 위한 별도의 정렬된 자료구조로, 책의 찾아보기와 같습니다. 대부분 B-트리 계열로 구현되며, 데이터 자체를 정렬하는 클러스터드 인덱스(테이블당 하나)와 위치만 가리키는 논클러스터드 인덱스(여러 개)로 나뉩니다. 인덱스는 조회를 빠르게 하는 대신 쓰기 비용과 저장 공간을 늘리므로, 카디널리티가 높고 자주 조회하는 열에 선별적으로 거는 것이 요령입니다.
7. 관계형을 넘어서: NoSQL과 확장
지금까지 다룬 관계형 데이터베이스는 견고하지만, 데이터가 폭발적으로 늘거나 구조가 유연해야 할 때 다른 선택지가 필요해집니다. 그 대안이 NoSQL("Not Only SQL")입니다. NoSQL은 하나의 제품이 아니라 관계형이 아닌 여러 방식을 아우르는 이름입니다.
| 유형 | 데이터 형태 | 대표 제품 |
|---|---|---|
| 키-값(Key-Value) | 키에 값 하나를 대응 | Redis |
| 문서(Document) | JSON 같은 문서 단위 | MongoDB |
| 컬럼 패밀리(Wide-Column) | 행마다 다른 열을 가질 수 있는 대용량 테이블 | Cassandra |
| 그래프(Graph) | 노드와 간선(관계) 중심 | Neo4j |
NoSQL은 스키마가 유연하고 수평 확장(뒤에서 설명)에 유리한 경우가 많지만, 관계형만큼 강한 일관성이나 복잡한 JOIN·트랜잭션을 보장하지 않는 경우가 많습니다. 역시 트레이드오프입니다.
CAP 정리
분산 데이터베이스를 이야기할 때 자주 등장하는 것이 CAP 정리입니다. 여러 노드에 데이터를 나눠 담는 시스템은 다음 셋을 동시에 완벽히 만족할 수 없고, 네트워크 단절(P)이 생긴 순간 일관성과 가용성 중 하나를 택해야 한다는 원리입니다.
- 일관성(Consistency): 어느 노드에 물어도 같은 최신 값을 답한다.
- 가용성(Availability): 언제 요청해도 응답을 받는다.
- 분단 내성(Partition tolerance): 노드 사이 통신이 끊겨도 시스템이 동작한다.
관계형 DB가 ACID를 강조한다면, 많은 분산 NoSQL은 "지금 당장 완벽히 일관되진 않아도 결국 일관되게 수렴한다"는 결과적 일관성(eventual consistency), 즉 BASE 쪽 철학을 택합니다.
규모를 키우는 법: 확장과 분산
데이터와 트래픽이 늘 때 감당하는 방법도 용어로 정리됩니다.
- 수직 확장(scale-up): 서버 한 대의 사양(CPU·메모리)을 키움. 간단하지만 한계가 있음.
- 수평 확장(scale-out): 서버 대수를 늘려 부하를 나눔. 확장성이 좋지만 복잡함.
- 복제(replication): 같은 데이터를 여러 서버에 복사해 둠. 읽기 부하 분산과 장애 대비에 쓰임.
- 샤딩(sharding): 데이터를 기준에 따라 여러 서버에 쪼개어 나눠 담음. 수평 파티셔닝의 한 형태.
- 파티셔닝(partitioning): 큰 테이블을 여러 조각으로 나눔. 행 기준(수평)·열 기준(수직)으로 나뉨.
마지막으로 애플리케이션과 DB 사이에서 자주 만나는 두 용어를 덧붙입니다.
- 커넥션 풀(connection pool): DB 연결은 만드는 비용이 크므로, 미리 여러 연결을 만들어 두고 돌려 쓰는 방식.
- N+1 문제: 목록을 한 번 조회한 뒤(1번), 각 항목의 연관 데이터를 항목 수(N)만큼 개별 조회해 쿼리가 폭증하는 흔한 성능 함정. JOIN이나 일괄 조회로 해결합니다.
Recap
NoSQL은 관계형이 아닌 여러 방식(키-값·문서·컬럼 패밀리·그래프)을 아우르며, 유연한 스키마와 수평 확장에 유리한 대신 강한 일관성·복잡한 JOIN은 약한 트레이드오프를 가집니다. 분산 시스템은 CAP 정리에 따라 네트워크 단절 시 일관성과 가용성 중 하나를 택하며, 많은 NoSQL은 결과적 일관성(BASE)을 지향합니다. 규모는 수직·수평 확장, 복제, 샤딩, 파티셔닝으로 키우며, 커넥션 풀과 N+1 문제는 애플리케이션과 DB 사이에서 자주 만나는 개념입니다.
용어 사전
빠르게 찾아볼 수 있도록 이 글의 핵심 용어를 한자리에 모읍니다.
| 용어 | 한 줄 정의 |
|---|---|
| DBMS | 데이터베이스를 관리하는 소프트웨어 |
| RDBMS | 데이터를 테이블로 다루는 관계형 DBMS |
| 테이블 · 행 · 열 | 데이터를 담는 표, 그 안의 한 항목(행)과 속성(열) |
| 스키마 | 테이블의 구조·자료형을 정의한 설계도 |
| 기본키(PK) | 각 행을 유일하게 식별하는 열 |
| 외래키(FK) | 다른 테이블의 키를 참조해 관계를 잇는 열 |
| 제약조건 | UNIQUE·NOT NULL·CHECK 등 데이터가 지킬 규칙 |
| NULL | "값이 없음/알 수 없음"을 뜻하는 별도 상태 |
| SQL | 관계형 DB와 대화하는 언어 (DDL·DML·DQL·DCL·TCL) |
| CRUD | 생성·조회·수정·삭제, 데이터의 기본 네 동작 |
| JOIN | 여러 테이블을 이어붙여 조회하는 연산 |
| 정규화 | 중복·이상을 줄이려 테이블을 나누는 설계 (1NF~3NF) |
| 반정규화 | 성능을 위해 일부러 중복을 허용하는 설계 |
| 트랜잭션 | 전부 성공 또는 전부 실패해야 하는 연산 묶음 |
| ACID | 원자성·일관성·격리성·지속성 |
| 격리 수준 | 안전성과 성능을 조절하는 트랜잭션 격리 단계 |
| 잠금(lock) · 교착 상태 | 동시성 제어 장치와, 서로를 기다리다 멈추는 상황 |
| 인덱스 | 빠른 조회를 위한 별도의 정렬된 자료구조 (B-트리) |
| 카디널리티 | 열이 가진 값의 다양성 정도 |
| NoSQL | 관계형이 아닌 방식(키-값·문서·컬럼·그래프)의 총칭 |
| CAP 정리 | 분단 시 일관성과 가용성 중 하나를 택해야 함 |
| 복제 · 샤딩 · 파티셔닝 | 데이터를 복사·분할해 규모를 키우는 전략 |
| N+1 문제 | 연관 데이터를 항목 수만큼 개별 조회해 쿼리가 폭증하는 함정 |
References
기초 개념
트랜잭션과 정규화
- Wikipedia — ACID
- Wikipedia — Isolation (database systems)
- Wikipedia — Database normalization
- PostgreSQL — Transaction Isolation
인덱스와 확장
- Use The Index, Luke — SQL 인덱싱 튜토리얼
- Wikipedia — Database index
- Wikipedia — CAP theorem
- Wikipedia — Shard (database architecture)
