데이터 베이스의 설계 및 모델링의 핵심 구성 요소

• Entity - Relationship 모델링
• 스키마 전략
• 인덱싱 전략
• 데이터 무결성과 성능을 보장하기 위한 제약 조건

Mastering the Building Blocks of Database Design and Modeling(DB 설계 & 모델링 구성 요소 마스터하기)

이 장에서 중요한 주제

• 데이터 타입과 제약 조건에 대한 이해
• Key 의 사용법
• 제약 조건을 활용한 데이터 품질 확인
• 동시성 제어 - 다중 사용자 관리

데이터 베이스 객체

View: 데이터를 상용자 맞춤으로 표현하는 것
Index: 데이터 검색을 빠르게 하기 위함
Stored Procedures & Trigger: 데이터베이스의 작업을 자동화하고 효율화 하는데 사용됨
Constraints: 데이터 무결성 보장
Sequences: 고유 식별자 생성을 위한 연속적인 숫자를 생성하는데 사용됨
User-Defined Functions(UDFs): 내장 기능을 넘어 데이터 베이스의 기능을 확장 가능

데이터 타입과 제약 조건

데이터 타입

열에 저장될 수 있는 값의 종류 정의

• 숫자형
• 문자형
• 날짜 및 시간
• 기타 데이터 형
  - 바이너리
  - 불리언
  - blob/clob
  - json

UUID
UUID에는 여러 종류가 있다.

• UUID v1 (호스트의 MAC 주소에서 생성된 타임스탬프와 랜덤 값을 포함)
• UUID v4 (완전 랜덤)
• UUID v7 (타임스탬프와 랜덤 값 결합)

MySQL에서 UUID를 저장하는 가장 좋은 방법은 VARBINARY(16) 타입을 사용하는 것. UUID를 순차적으로 저장하려면 UUID_TO_BIN(..., swap_flag) 함수를 사용하여 스왑 플래그를 활성화할 수 있다

Constraints(제약 조건)

Primary Key

• 각 레코드를 고유하게 식별
• Not Null
• 자동으로 인덱스 생성

Foreign Key

• 테이블 간 관계를 설정하고 참조 무결성을 보장
• 변경 시 다른 테이블의 외래키 제약도 함께 수정

인덱스가 많아지면 쓰기 작업(INSERT, UPDATE, DELETE)이 느려질 수 있다. 인덱스도 업데이트해야 하기 때문.
인덱스에 포함된 컬럼 수가 많아질수록 인덱스 크기도 커짐. 최적의 성능 유지를 위해 정기적인 유지보수가 필요할 수 있습니다. 데이터 분포와 쿼리 패턴이 바뀔 때 인덱싱 전략을 유연하게 조정할 준비를 하세요.

인덱스의 효과는 데이터베이스의 특정 쿼리와 데이터 분포에 크게 의존한다. 새로운 인덱스를 만든 후에는 성능을 테스트하고 모니터링하여 의도한 효과가 있는지 확인하는 것이 좋다.

데이터 베이스 검사 및 제약 조건

각 검사 작업은 내부적으로 성능 저하를 유발할 수 있음
하나의 테이블에 너무 많은 제약 조건을 추가하면 안됨.

• ckeck 제약 조건: 모든 값이 특정 조건을 만족하는지
• default 제약 조건: 값이 지정되지 않았을 때 기본 값으로 자동 할당
• Not Null 제약 조건: Null 비허용
  --> 데이터 일관성 유효성, 무결성을 보장

중복을 피하는 법

• 정규화
• primary key, foreign key 사용으로 데이터 중복을 피함
• 올바른 데이터 모델 구현
• 중복 레코드 방지(Unique 제약 조건)
• 데이터 통합 및 ETL프로세스 활용

Database consistency and beyond

데이터베이스 관리는 단순히 일관성을 유지하는 것에 그치지 않는다. 데이터베이스가 커지고 복잡해질수록, 일관성과 성능, 확장성 간의 균형이 필요함.

CAP 이론 (Consistency, Availability, Partition Tolerance)

• Consistency (일관성): 모든 노드가 동일한 데이터 값을 갖는 것
• Availability (가용성): 모든 요청에 대해 응답을 받을 수 있는 상태
• Partition Tolerance (분할 허용성): 네트워크 단절이 발생해도 시스템이 동작을 유지하는 능력

이 세가지를 모두 충족시킬 수 없다. 두 가지를 선택하면 하나는 희생해야함.

일관성 외에도 데이터베이스 시스템을 종합적으로 관리하려면 다음과 같은 요소들을 고려해야 함:

• 백업 및 복구 (Backup and Recovery)
• 장기적인 데이터 무결성 유지
• 규제 준수 (Regulatory Compliance)
• 모니터링 및 감사 (Monitoring and Auditing)

Transactions – ensuring data integrity

MySQL은 많은 관계형 데이터베이스 시스템처럼 기본적으로 REPEATABLE READ 격리 수준을 사용

이 격리 수준은 높은 일관성을 제공하지만, 높은 동시성 환경에서는 성능 저하나 경합(lock contention) 을 유발할 수 있음.

ACID 속성 외에도 격리 수준은 트랜잭션 간의 충돌을 방지하여 무결성을 유지하는 추가적인 제어 도구입니다.
애플리케이션의 필요에 따라 적절한 격리 수준을 선택해 일관성과 성능 사이의 균형을 맞추는 것이 중요.

격리 수준의 일반적인 종류:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE
  각 수준은 서로 다른 수준의 격리와 동시성을 제공한다. 개발자와 데이터베이스 관리자는 애플리케이션의 요구 사항에 따라 적절한 수준을 신중히 선택해야함

트랜잭션 간 무결성을 유지하기 위해 데이터베이스는 잠금(Lock)을 사용한다.

• Shared Lock
• Exclusive Lock
• Row-level Lock

동시성 제어 - 다중 사용자 관리

MVCC(Multi-Version Concurrency Control)는 동시성을 관리하는 또 다른 기술
lock contention을 줄이고 성능을 향상시킴

MVCC

MVCC는 데이터를 잠그는 대신, 여러 버전(스냅샷)을 유지하여 트랜잭션에 특정 시점의 데이터 상태를 보여주는 방식이다.
즉, 트랜잭션이 데이터를 읽을 때 변경 중이거나 최신 상태가 아닌, 자신이 시작한 시점의 데이터 버전을 참조함.

이 방식 덕분에 아래의 것들이 가능해짐

• 읽기 작업은 쓰기 작업에 의해 차단되지 않음
• 쓰기 작업도 다른 읽기 트랜잭션을 기다릴 필요 없음

MVCC는 데이터 변형(mutation)을 대신하는 것이 아니라, 잠금 사용을 최소화하고 독립적인 스냅샷을 제공함으로써 동시성을 유지합니다.

MySQL과 PostgreSQL은 모두 MVCC를 지원하나 내부 구현 방식에 차이가 있다.

PostgreSQL

MVCC는 PostgreSQL아키텍쳐의 핵심
모든 트랜젝션에서 일관된 데이터 보기 제공, non-blocking 읽기를 가능하게 함.

PostgreSQL은 트랜젝션 ID를 사용해 MVCC를 구현함
그래서 불필요한 오래된 행 버전을 제거하는 Vacuum이라는 프로세스가 필요함.
이 과정으로 공간을 회수하고 성능을 향상.

MySQL

MVCC지원 여부는 스토리지 엔진에 따라 다름.
지원하는 가장 대표적인 엔진 InnoDB

PostgreSQL과 유사하게, InnoDB도 행이 업데이트되거나 삭제될 때 새로운 버전의 행과 인덱스 항목을 생성

InnoDB는 PostgreSQL처럼 수동으로 vacuum을 실행할 필요 없이, 일상적인 작업 중 자동으로 오래된 행 버전을 정리함.