이번 게시글은 Chat GPT 센세와 함께합니다!

2023년 4월 18일
호눅스와 함께하는 마스터 클래스
주제는 ....

✨DB✨

테이블을 만들면 OS에서는 무슨 일이 일어날까? 🤔

데이터베이스의 주요 목적?

데이터를 효율적으로 관리하는 것. 데이터베이스는 다양한 종류의 데이터를 구조화하고 저장하며, 데이터의 무결성, 일관성, 보안, 접근성 효율성 등을 보장하기 위한 기능을 제공한다.

1. 데이터의 중앙화

데이터베이스는 사용자들이 공유하는 데이터를 중앙에서 통합하여 관리한다. 이로써 중복 데이터의 생성을 방지하고 데이터 일관성을 유지할 수 있다

2. 데이터 구조화

데이터를 구조화하여 테이블, 필드, 레코드 등의 형태로 저장한다. 이로써 데이터에 일관성 있는 형식과 구조를 부여함으로써 데이터의 이해와 관리를 용이하게한다

3. 데이터 무결성 및 보안

데이터베이스는 데이터의 무결성(정확성과 일관성)을 유지하고, 무단 접근으로부터 보호하기 위한 다양한 보안 기능을 제공한다. 데이터베이스는 데이터를 정확하게 저장한다

4. 데이터의 접근성과 공유

다양한 사용자들이 데이터에 접근할 수 있도록 허용하고, 동시 다중 사용자의 데이터 공유를 가능하게 한다.

5. 데이터의 효율적인 관리

데이터의 백업, 복구, 성능 튜닝, 인덱싱 등의 관리 기능을 제공하여 데이터를 효율적으로 관리하고 운영할 수 있도록 한다

6. 데이터 분석과 의사 결정 지원

다양한 데이터를 통합하여 데이터 분석과 의사 결정을 지원하는 기능을 제공한다

데이터베이스에게 PK는...

데이터베이스의 프라이머리키는 b+tree 디스크 기반 자료구조 인덱스로 저장되어 있다
b+tree는 많은 데이터베이스 시스템에서 인덱스 구성 요소로 사용되며, 데이터베이스의 검색 속도를 높이는 데에 매우 효과적이다

b+tree는 높은 성능을 가지는 디스크 기반의 자료구조로, 프라이머리 키와 그에 대응하는 레코드의 위치를 매핑하여 인덱스를 구성한다. 이를 통해 프라이머리 키를 기반으로 빠른 검색과 정렬된 순서에 따른 범위 검색이 가능하게 된다. b+트리는 높은 효율성과 검색 성능을 제공하며, 데이터베이스의 크기가 커지더라도 일관된 성능을 유지할 수 있다.

데이터베이스의 프라이머리키를 b+트리와 같은 디스크 기반 자료구조 인덱스에 저장함으로써, 데이터베이스의 검색속도를 향상시키고 데이터의 무결성과 일관성을 유지하는 데에 도움이 된다.

### 프라이머리 인덱스 프라이머리 인덱스(Primary Index)는 데이터베이스에서 테이블의 프라이머리 키(primary key)를 기반으로 생성된 인덱스이다. 프라이머리키는 **각 레코드를 고유하게 식별하는 열**로, 프라이머리 인덱스는 이 프라이머리키를 이용하여 빠르게 데이터를 검색하고 정렬하는데 사용된다. 프라이머리 인덱스를 사용하면 프라이머리 키를 이용한 검색이 빠르게 처리될 수 있어, 테이블에서 특정 레코드를 찾거나 정렬된 결과를 얻는 등의 작업이 빠르게 수행될 수 있다. 또한 프라이머리 인덱스를 사용하면 중복된 데이터의 입력을 방지하고 데이터의 일관성을 유지하는데도 도움이 된다. 하지만, 인덱스 유지 관리에 따른 오버헤드가 발생하므로, 데이터 변경 작업이 빈번하게 일어나는 테이블의 경우에는 성능 저하가 발생할 수도 있다.

여기서 잠깐, 데이터베이스 관리 시스템의 ACID의 속성을 알고 넘어가도록 하자

데이터베이스의 ACID

1. 독립성 (Isolation): 동시에 여러 개의 트랜잭션이 수행되더라도 각각의 트랜잭션은 다른 트랜잭션에게 영향을 주지 않고 독립적으로 실행되어야 한다. 한 트랜잭션의 변경이 다른 트랜잭션에게 곧바로 반영되지 않고, 트랜잭션이 완전히 완료된 후에만 변경 사항이 반영되어야 한다.
2. 일관성 (Consistency): 데이터베이스는 항상 미리 정의된 규칙과 제약 조건에 따라 일관된 상태를 유지해야 한다. 트랜잭션이 수행되기 전과 후에 데이터베이스는 항상 일관된 상태를 유지해야 한다.
3. 원자성 (Atomicity): 트랜잭션은 "원자적"이어야 하며, 트랜잭션의 모든 연산은 전부 성공하거나 전부 실패해야 한다. 트랜잭션이 중간에 실패할 경우, 이전 상태로 롤백되어 원자성이 유지되어야 한다.
4. 영속성 (Durability): 트랜잭션이 성공적으로 완료되면, 그 결과는 영구적으로 저장되어야 한다. 시스템 장애나 비정상적인 상황이 발생하더라도 데이터는 영속적으로 저장되어야 한다.
   
   

인덱스가 걸려있다? 인덱스를 타면 빨라진다?

• 인덱스가 걸려있다
  데이터베이스에서 특정 열(칼럼)에 인덱스가 생성되어 있다는 의미이다. 인덱스를 사용하여 데이터를 검색하면 일반적으로 빠른 속도로 결과를 얻을 수 있다
• 인덱스를 타면 빨라진다
  인덱스가 사용되어 데이터를 검색하는 작업이 빠르게 처리된다는 의미이다. 일반적으로 인덱스는 특정 열의 값을 미리 정렬하여 효율적으로 검색할 수 있도록 도와주기 때문에, 인덱스가 있는 열을 이용하여 검색을 수행하면 일반적으로 빠른 검색 성능을 얻을 수 있다.

하지만..

모든 경우에 인덱스를 사용하는 것이 항상 빠른 것은 아니다.
인덱스를 사용하면 인덱스 자체가 차지하는 공간이 추가로 필요하게 되므로 데이터 베이스의 용량도 증가할 수 있다.
인덱스를 만들었다고 해서 모든 쿼리가 인덱스를 타는 것은 아니다.
인덱스를 사용하는 쿼리에서만 인덱스가 활용된다. 그렇기 때문에 인덱스를 사용하지 않는 쿼리는 인덱스를 타지 않고 일반적인 데이터 검색 방법을 사용하게 된다.

인덱스를 만들면 인서트 성능이 떨어지나요? 🤔

AskUp은 이렇게 대답했습니다!

유료버전은 이렇게 대답했습니다!

성능 저하의 정도는 데이터베이스의 크기, 인덱스의 수, 쓰기 작업의 비율 등 다양한 요소에 따라 달라집니다. 
인덱스가 필요한 쿼리에 대한 성능 향상이 크다면, 쓰기 작업의 성능 저하는 상대적으로 덜 중요하게 고려될 수 있습니다. 
반면, 쓰기 작업이 빈번하게 발생하는 데이터베이스에서는 인덱스 추가로 인한 성능 저하가 중요한 문제로 다뤄질 수 있습니다.

성능 저하 문제를 최소화하려면 다음과 같은 방법을 고려할 수 있습니다:

1. 필요한 인덱스만 추가: 읽기 작업에 실제로 도움이 되는 인덱스만 추가하고, 불필요한 인덱스는 제거합니다. 이렇게 하면 쓰기 작업에 미치는 부정적 영향을 줄일 수 있습니다.

2. 인덱스 정리 및 최적화: 정기적으로 인덱스를 정리하고 최적화하여 페이지 분할 및 공간 사용률 문제를 해결합니다.

3. 쓰기 작업 분리: 쓰기 작업이 빈번하게 발생하는 테이블과 읽기 작업이 빈번하게 발생하는 테이블을 분리하여 관리합니다. 이렇게 하면 인덱스로 인한 성능 저하를 최소화할 수 있습니다.

최종적으로, 인덱스 추가에 따른 성능 저하가 고려할 만큼 큰 문제인지 여부는 상황에 따라 다릅니다. 데이터베이스의 요구사항을 정확하게 이해하고, 인덱스를 적절하게 관리하는 것이 중요합니다.


인덱스를 추가하면 데이터베이스의 조회 성능이 향상되지만, 반면에 insert, update, delete와 같은 쓰기 작업에는 성능 저하가 발생할 수 있습니다. 
인덱스를 추가할 때 발생하는 성능 저하의 주요 이유는 다음과 같습니다.

1. 인덱스 유지: 새로운 데이터가 삽입될 때, 데이터베이스는 해당 인덱스를 업데이트해야 합니다. 인덱스가 많으면 많을수록, 삽입 작업이 더 오래 걸립니다.

2. 페이지 분할: 새로운 데이터가 삽입되면, 인덱스의 특정 위치에 새 데이터를 저장해야 합니다. 이 때, 해당 위치에 공간이 없으면 페이지 분할이 발생하여 성능 저하가 일어날 수 있습니다.

3. 인덱스 크기: 인덱스가 많아지면, 물리적 저장 공간이 늘어나고 인덱스 구조를 메모리에 로드하는 데 시간이 더 걸립니다. 이로 인해 쓰기 작업의 성능이 저하될 수 있습니다.

따라서, 데이터베이스의 인덱스를 추가할 때는 읽기 작업의 성능 향상과 쓰기 작업의 성능 저하 사이에서 균형을 찾아야 합니다. 
인덱스를 무분별하게 추가하는 것이 아니라, 실제로 필요한 인덱스만 추가하는 것이 중요합니다.

데이터베이스는 내부적으로 통계를 가지고 있다

이 통계정보는 데이터베이스 시스템이 쿼리를 실행할 때 최적의 실행 계획을 선택하는 데 사용된다. 이를 통해 데이터베이스 시스템은 쿼리의 성능을 최적화하고, 쿼리 실행 시간을 줄이는데 도움을 준다

통계 정보는 일반적으로 테이블의 칼럼별로 수집되며, 각 칼럼의 값 분포, 카디널리티, 히스토그램 등의 정보를 포함할 수 있다. 이 통계 정보는 데이터베이스 시스템이 실행할 쿼리의 실행 계획을 선택할 때 사용된다. 예를 들어, 특정 칼럼의 값 분포가 고르게 퍼져있는 경우, 인덱스 스캔이나 풀 테이블 스캔보다는 인덱스를 활용한 접근이 더 효율적일 수 있다.

통계정보는 주기적으로 업데이트되거나, 데이터의 변경이 있을 때 자동으로 갱신될 수 있다. 또한 데이터베이스 시스템에서는 사용자가 직접 통계정보를 수동으로 갱신하거나 힌트를 사용하여 특정 실행 계획을 선택하는 기능도 제공될 수 있다. 이를 통해 데이터베이스 시스템은 최적의 실행 계획을 선택하여 쿼리의 성능을 최대화할 수 있다

커버링 쿼리

데이터베이스에서 인덱스를 활용하여 쿼리를 수행할 때, 인덱스 자체만으로 필요한 데이터를 모두 제공하여 디스크의 실제 데이터 블록을 참조하지 않고도 원하는 결과를 얻는 쿼리이다. 이를 통해 I/O를 최소화하고 쿼리의 성능을 향상시킬 수 있다

일반적으로 쿼리가 데이터베이스에서 원하는 데이터를 얻기 위해 디스크에 있는 실제 데이터 블록을 참조해야하는데, 커버링 쿼리는 인덱스 자체제 필요한 데이터가 모두 포함되어 있기 때문에 디스크의 실제 데이터 블록을 참조하지 않아도 원하는 결과를 얻을 수 있다.

커버링 쿼리는 특히 데이터베이스에서 대량의 데이터를 처리하는 경우에 유용하다. 예를 들어, 많은 수의 로우를 포함하는 테이블에서 특정 조건에 맞는 데이터를 검색하고자 할 때 커버링 쿼리를 사용하면 인덱스를 활용해서 빠르게 결과를 얻을 수 있다.

커버링 쿼리를 사용하기 위해서는 인덱스가 쿼리에서 필요한 모든 컬럼을 커버해야하며, 쿼리에서 인덱스를 활용하는 것이 중요하다.

쿼리 옵티마이저

쿼리 옵티마이저는 데이터베이스 시스템에서 사용자의 SQL 쿼리를 가장 효율적으로 실행하기 위해 쿼리의 실행 계획을 최적화하는 역할을 수행하는 컴포넌트이다. 쿼리 옵티마이저는 사용자가 작성한 SQL 쿼리를 실행 계획으로 변환하고, 가능한 다양한 실행 계획 중에서 최적의 실행 계획을 선택하는 작업을 수행한다. 이를 통해 데이터베이스 시스템이 가장 효율적으로 쿼리를 실행하고, 최적의 성능을 제공할 수 있도록 도와준다

인덱스를 활용하여 빠른 데이터 검색, 조인 연산의 순서를 최적화하여 중간 결과를 최소화 하는 등의 작업이 포함될 수 있다. 또한 통계 정보를 기반으로 데이터의 분포와 특성을 고려하여 실행 계획을 선택하거나, 병렬 처리 기술을 사용하여 여러 CPU나 스토리지를 활용하여 빠른 처리를 수행하는 등의 최적화 기술이 사용될 수 있다.

쿼리 옵티마이저는 데이터베이스 시스템의 핵심적인 컴포넌트로, 데이터베이스의 성능과 효율성에 큰 영향을 미친다.

클러스터드 인덱스 자료구조

클러스터드 인덱스는 데이터베이스에서 사용되는 인덱스 중 하나로, 데이터를 물리적으로 정렬된 상태로 저장하는 자료구조이다. 즉, 테이블의 데이터 자체가 인덱스의 순서와 일치하게 저장되는 구조를 가지오 있다. 이러한 특성으로 인해 클러스터드 인덱스는 데이터의 빠른 액세스와 검색을 가능하게 한다

1. 데이터 물리적인 정렬 : 클러스터드 인덱스는 데이터를 물리적으로 정렬하여 저장한다. 따라서 인덱스의 순서와 데이터의 순서가 일치하게 된다
2. 데이터의 높은 압축률 : 클러스터드 인덱스는 데이터를 물리적으로 정렬하므로, 데이터의 중복을 줄일 수 있어 데이터의 압축률이 높아진다
3. 인덱스와 데이터의 통합 저장 : 클러스터드 인덱스는 테이블의 데이터와 인덱스를 통합하여 저장한다. 따라서 인덱스와 데이터 간의 조인 작업이 필요하지 않아 성능이 향상될 수 있다
4. 데이터의 연속된 블록에 저장 : 클러스터드 인덱스는 데이터를 연속된 블록에 저장하므로, 디스크에서 데이터를 읽어오는 횟수가 줄어들어 액세스 속도가 향상될 수 있다

하지만 클러스터드 인덱스는 데이터의 물리적인 정렬을 유지하기 위해 데이터의 추가, 삭제, 수정에 대한 비용이 높아질 수 있고, 데이터의 중복이 적은 경우에는 압축 효과가 미비할 수 있다. 또한 클러스터드 인덱스는 테이블당 하나만 생성할 수 있어 한 테이블에 여러 개의 클러스터드 인덱스를 생성하는 것이 불가능 하다. 따라서 클러스터드 인덱스의 사용 여부는 데이터베이스의 특정 상황과 요구사항에 따라 결정되어야 한다.

+++

추가로 공부해야 할 것

• 선형대수, 확률통계
• 쿼리 옵티마이저와 클러스터드 인덱스 자료구조는 추후에 공부할 예정
• 리눅스
• 마이크로서비스 <-> 모놀리식서비스