인덱스와 DBMS의 부상

Source: Dev.to

안녕하세요, 저는 마네시와르입니다. 저는 FreeDevTools online에서 작업하고 있으며, 현재 모든 개발 도구, 치트 코드 및 TLDR을 한 곳에 모으는 작업을 진행 중입니다 — 개발자들이 인터넷을 뒤져가며 찾는 번거로움 없이 빠르게 도구를 찾아 사용할 수 있는 무료, 오픈‑소스 허브입니다.

요약

이전 게시물에서 관계형 모델이 데이터에 구조를 부여하는 방식을 살펴보았습니다:

• 엔터티는 관계가 됩니다.
• 관계는 테이블이 됩니다.
• 무결성 제약은 유효한 데이터베이스 상태가 어떤 모습인지 정의합니다.

하지만 구조만으로는 충분하지 않습니다. 데이터가 사소한 규모를 넘어 성장하면, 관계에 접근하는 방법이 그 관계가 무엇을 나타내는지만큼 중요해집니다. 여기서 인덱싱과 **데이터베이스 관리 시스템 (DBMS)**이 등장합니다.

인덱스가 존재하는 이유

A 전체 관계 스캔 (reading every row in a table) 은 쿼리에 답하는 가장 기본적인 방법이며, 데이터베이스가 수행할 수 있는 가장 비용이 많이 드는 작업 중 하나이다.

우리가 이미 디스크에 대해 알고 있는 사실:

• 데이터 읽기는 블록 단위로 이루어진다.
• 디스크 I/O 가 실행 시간을 지배한다.
• 큰 관계에 대한 순차 스캔은 비용이 많이 든다.

따라서, 데이터베이스는 행을 더 빠르게 찾을 방법이 필요하다.

인덱스란?

인덱스는 관계 위에 구축된 데이터 구조로, 하나 이상의 속성값을 기준으로 행을 효율적인 조회할 수 있게 지원한다. 인덱스는 데이터를 자체적으로 저장하지 않으며, 다음을 저장한다:

• 검색 키 값
• 기본 관계의 행에 대한 포인터 또는 참조
• 조회를 가장 효율적인 경로로 안내하는 라우팅 정보

인덱스는 관계 모델 자체의 일부는 아니지만, 실제 시스템에서는 필수적이다.

인덱스와 관계

관계형 데이터베이스에서 인덱스의 중요한 속성:

행이 삽입, 삭제, 갱신될 때마다 DBMS는 모든 관련 인덱스를 백그라운드에서 자동으로 업데이트합니다.

해시 인덱스와 트리 인덱스

두 가지 인덱스 구조 패밀리가 관계형 시스템을 지배합니다.

해시 인덱스

A hash index는 빠른 포인트 조회에 최적화되어 있습니다. 작동 방식은 다음과 같습니다:

1. 검색 키 값에 해시 함수를 적용한다.
2. 값을 버킷에 매핑한다.
3. 해당 버킷 내에서만 검색한다.

해시 인덱스는 정확히 일치하는 쿼리에 대해 매우 빠르지만, 큰 제한이 있습니다:

• They do not support range queries efficiently.
  두 경계 사이의 값을 요청하면 많은 버킷 또는 전체 버킷을 스캔해야 하므로 인덱스의 목적을 무색하게 합니다.

B‑트리와 B⁺‑트리 인덱스

A B‑tree index는 검색 키 값을 정렬된 순서로 저장하여 다음을 가능하게 합니다:

• Efficient point lookups.
• Efficient range queries.
• Ordered traversal without scanning the entire relation.

B‑트리의 각 노드는 다음을 포함합니다:

• Search‑key values.
• Pointers to child nodes.

탐색 결정은 각 노드에서 검색 키를 비교하여 이루어집니다.

널리 사용되는 변형은 B⁺‑tree입니다:

• Internal nodes는 라우팅 정보만 포함합니다.
• Leaf nodes는 실제 데이터 참조를 포함하며 (종종 빠른 범위 스캔을 지원하기 위해 서로 연결됩니다).

B⁺‑트리는 무작위 I/O를 최소화하고 트리 높이를 작게 유지하기 때문에 디스크 기반 저장소에 특히 적합합니다.

이 시점에서 우리는 논리적 쿼리가 물리적 디스크 접근 패턴에 어떻게 매핑되기 시작하는지 처음으로 엿볼 수 있습니다.

애플리케이션이 데이터를 직접 관리해서는 안 되는 이유

역사적으로 애플리케이션은 데이터베이스 파일을 직접 조작했습니다:

• 파일에서 바이트를 읽기.
• 메모리 내 구조를 수정하기.
• 데이터를 다시 디스크에 쓰기.

이 파일 처리 방식은 여러 근본적인 문제 때문에 빠르게 무너집니다:

• 파일 형식에 대한 강한 결합.
• 무결성 제약을 강제하기 어려움.
• 부분적인 쓰기와 충돌로 인한 데이터 손상.
• 위험한 동시 접근.
• 실패 후 복구가 매우 복잡함.

데이터베이스가 성장하고 여러 사용자가 동시에 접근하게 되면, 애플리케이션 수준에서 정확성을 보장하기가 거의 불가능해집니다. 잘 작성된 애플리케이션이라도 동시성이나 실패 상황에서 일관성 없는 상태를 만들 수 있습니다.

데이터베이스 관리 시스템에 입문

해결책은 애플리케이션과 스토리지 사이에 전용 소프트웨어 계층을 삽입하는 것입니다: Database Management System (DBMS).

DBMS는 다음을 제공합니다:

• Higher‑level data abstractions (relations instead of files). → 고수준 데이터 추상화 (파일 대신 관계)
• Well‑defined APIs for querying and updating data. → 데이터 조회 및 업데이트를 위한 명확히 정의된 API
• Automatic index maintenance. → 자동 인덱스 관리
• Enforcement of integrity constraints. → 무결성 제약 조건 강제 적용
• Concurrency control. → 동시성 제어
• Failure recovery. → 장애 복구

애플리케이션 관점에서

• Data appears as tables. → 데이터가 테이블 형태로 나타납니다.
• Operations are declarative. → 작업이 선언형입니다.
• Storage details are hidden. → 스토리지 세부 사항이 숨겨져 있습니다.

시스템 관점에서

• Queries are translated into efficient execution plans. → 쿼리가 효율적인 실행 계획으로 변환됩니다.
• Indexes are used when beneficial. → 인덱스는 유리할 때 사용됩니다.
• Disk I/O is carefully managed. → 디스크 I/O가 신중하게 관리됩니다.
• Failures are handled transparently. → 장애가 투명하게 처리됩니다.

DBMS는 블랙 박스 역할을 하여 다음 사이의 격차를 메웁니다:

• Conceptual data models. → 개념적 데이터 모델
• Physical storage realities. → 물리적 스토리지 현실

현재 위치

이 단계에서 레이어가 명확히 보입니다:

• Disks는 물리적 제약을 정의합니다.
• Relations는 논리적 구조를 정의합니다.
• Indexes는 접근 경로를 정의합니다.
• DBMS는 모든 것을 조정합니다.

남아 있는 문제는 가장 어려운 문제

많은 사용자가 동시에 데이터를 수정하고, 작업 중에 실패가 발생하면 어떻게 될까요?

이 질문은 곧 트랜잭션, ACID 특성, 트랜잭션 관리, 그리고 동시성 제어로 이어집니다.

이것이 바로 다음 단계이며, 데이터베이스가 단순한 데이터 저장소를 넘어 진지한 시스템으로 변모하는 지점입니다.

👉 확인해 보세요: FreeDevTools

피드백이나 기여는 언제든 환영합니다!
온라인이며 오픈소스이고, 누구든지 사용할 수 있습니다.

⭐ GitHub에서 별표 달기: FreeDevTools