MongoDB 특징

• MongoDB는 Reliability(신뢰성), Scalability(확장성), Flexibility(유연성), Index Support(인덱스 지원) 4가지 특징을 가진 NoSQL Database 입니다.

Reliability(신뢰성)

• Primary와 Secondry로 구성된 Replica Set 구조로 고가용성을 지원합니다. 이를 통해 서버의 장애가 발생되어도 자체적으로 이를 회복하여 서비스가 정상적으로 운영되도록 할 수 있습니다.

Replica Set 동작

• MongoDB의 Replica Set은 기본적으로 1개의 Primary와 2개의 Secondary로 이루어져 있습니다.

• 쓰기 작업은 Primary가 담당하고, 읽기 작업은 Secondary가 담당합니다. 이를 통해 읽기/쓰기에 대한 부하를 분산할 수 있습니다.

• Primary는 쓰기 작업을 처리하여 데이터에 대한 변경 사항을 Secondary에 전달하여 동기화합니다.

• Primary 서버에 문제가 발생되어 사용할 수 없게 되었다면, 자동적으로 Secondary 서버를 Primary 서버로 설정하고 새로운 Secondary 서버를 셋팅하여 서버 장애에 대응합니다.

Scalability(확장성)

• 데이터와 트래픽이 증가함에 따라 데이터 샤딩을 통한 수평확장(scale-out)을 하여 부하 분산을 할 수 있습니다.
  
  
  
• Replica Set구조로 이루어진 각 Shard에 Shard Key를 기준으로 데이터를 분산하여 저장합니다.

• MongoDB는 RDBMS와 같이 정규화를 통한 테이블 분산을 거의 하지 않고, Document의 field에 배열 또는 Sub Document를 담음으로써 하나의 Document에 필요한 데이터를 모두 저장할 수 있습니다. 이를 통해 수평 확장에 대한 이점을 더욱 얻을 수 있습니다.

MongoDB의 밸런싱(Balancing)

• 몽고DB에 데이터가 증가하여 더 이상 하나의 Replica Set에 담을 수 없게 되거나 특정 샤드에 데이터가 몰리면 다른 샤드로 데이터를 이동 시켜, 전반적으로 모든 샤드가 균등하게 데이터가 저장될 수 있도록 합니다. 이러한 작업은 서비스 중단 없이 온라인 과정에서 진행됩니다. 그리고 이러한 동작을 밸런싱(Balancing)이라고 합니다.

Flexibility(유연성)

• 스키마 구조 변경 없이 여러 가지 형태의 데이터를 저장할 수 있기 때문에 서비스 요구 사항에 맞춰 다양한 형태의 데이터를 저장할 수 있습니다.

• JSON 형태로 데이터를 저장하고 읽기 때문에 개발자들 입장에서도 Object와 1:1로 매칭하여 사용할 수 있어 더욱 편리합니다.

• 하나의 Document에 배열 또는 Sub Document를 추가함으로써 RDBMS와 같이 join을 이용해 여러 테이블을 조회하는 상황을 줄일 수 있습니다.

Index Support(인덱스 지원)

• MongoDB Index에 대한 정리 글(https://vanilla-tech.tistory.com/entry/MongoDB-index-%EC%A2%85%EB%A5%98)

MongoDB의 Cluster 구조

• MongoDB의 Cluster 구조는 mongos, shard cluster, config server로 3개의 Component 구성됩니다.

• shard cluster에는 실제 데이터가 저장됩니다.

• config server에는 접근하고자 하는 데이터가 어떤 shard cluster에 저장되어 있는지 여부를 확인 수 있는 메타 데이터가 저장됩니다.

• app server는 mongos에만 연결하여 데이터를 요청합니다. mongos는 config server를 통해서 어떤 shard cluster에 데이터가 저장되었는지 확인하여 shard cluster에서 데이터를 가져와 app server에 응답합니다.

• 위와 같은 구조 덕분에 app server는 MongoDB의 Cluster 구조를 알 필요 없이 mongos에만 접근하여 원하는 데이터를 접근하고 조작할 수 있습니다. 덕분에 사용성 측면과 유지보수 측면에서의 이점이 있습니다.

BSON과 JSON

• MongoDB는 JSON 형태로 데이터를 저장하는 것처럼 보이지만, 실제로는 BSON(Binary JSON) 형태로 데이터를 저장합니다.

• JSON은 텍스트 기반으로 저장되기 때문에 구문 분석이 느리고, 공간 효율성이 떨어지고 데이터 타입 표현의 한계가 있습니다. 그렇기 때문에 사용자에게 보여질 때는 JSON으로 보여주고, 네트워크로 전송하고 저장할 때는 BSON으로 인코딩하여 처리합니다.

• BSON은 JSON보다 공간 효율성, 처리 속도, 다양한 데이터 타입 지원 부분에서 이점이 있습니다.

자료 출처 : https://tv.kakao.com/v/414072595

MongoDB index 종류

• MongoDB는 다양한 인덱스를 지원하기 때문에 서비스 요구 사항에 적합한 인덱스를 선택하여 보다 빠른 검색 속도를 지원합니다.
  
  
  
• MongoDB에서의 index는 모두 Non-Clustered index입니다.
  
  
  
• index는 필요한 만큼 생성 가능합니다.

단일 필드 인덱스(Single Field Index)

• 단일 필드만으로 구성된 인덱스입니다. B-Tree로 구현되어 오름/내림 차순 정렬이 가능합니다.

복합 인덱스(Compound Index)

• 복합 인덱스는 여러 필드를 조합하여 구성된 인덱스입니다. 복합 인덱스는 복합 인덱스를 이루는 여러개의 필드로 검색할 때 큰 이점을 얻을 수 있으며, 지정된 필드 순서대로 정렬되기 때문에 인덱스를 구성하는 필드의 순서가 중요합니다. 예를들어서 복합 인덱스가 (field1, field2)로 구성되어 있다면 field1을 정렬한 후에 field1에 대한 field2를 정렬합니다. 그렇기 때문에 field1으로만 검색했을 때에는 복합 인덱스로 인한 이점을 얻을 수 있지만, field2로만 검색할 때는 복합 인덱스에 대한 이점을 얻을 수 없습니다.

텍스트 인덱스(Text Index)

• 텍스트 인덱스(Text Index)는 MongoDB에서 문자열을 검색할 때 사용하는 인덱스입니다. 일반적인 인덱스와는 다르게 MongoDB의 텍스트 검색 기능을 사용하면 여러 단어나 문장에 대한 검색이 가능하며, 검색 결과를 스코어링하여 결과값을 정렬할 수 있습니다.(스코어링이란 검색어와 문서의 일치도를 계산하여 검색 결과를 정렬하는 방법입니다.)
  
  텍스트 인덱스는 단일 필드 인덱스와 복합 인덱스로 구성될 수 있습니다. 텍스트 인덱스를 지정한 필드에서는 전문 검색(full-text search)이 가능합니다. 이를 통해 전체 텍스트를 검색할 수 있고, 검색 결과에 대한 스코어링을 통해 결과값을 정렬할 수 있습니다.
  
  텍스트 인덱스를 사용하면 텍스트 검색 속도가 매우 빨라지며, 텍스트 검색 기능의 활용도를 높일 수 있습니다. 다만, 텍스트 인덱스를 사용하면 색인 크기가 커지기 때문에 저장 공간이 필요 이상으로 많아질 수 있다는 단점이 있습니다.

지리 공간 인덱스(Geospatial Index)

• 지리 공간 인덱스(Geospatial Index)는 지리 정보(Geographic Information)가 저장된 필드를 더 빠르게 검색할 수 있도록 하는 인덱스입니다. MongoDB에서는 2차원의 평면 지리 정보를 다루는데, Geospatial Index는 해당 평면 상에서 좌표 값(latitude, longitude)으로 이루어진 위치 정보를 저장할 수 있습니다.
  
  Geospatial Index는 R-Tree 알고리즘을 사용하여 인덱싱을 수행합니다. R-Tree는 2차원 공간 상에서 사각형의 형태로 인덱싱을 수행하여 공간 상의 논리적 관계를 유지합니다. 이를 통해 지정한 범위 내에서 빠른 검색을 수행할 수 있습니다.
  
  Geospatial Index를 사용하면 지도 어플리케이션 등에서 위치 기반 검색을 더욱 빠르게 수행할 수 있습니다. 또한, 지리 정보가 포함된 다양한 데이터를 분석하는 데에도 유용합니다.
  
  
  
• 카카오 택시, 카카오 대리, 카카오 모빌리티 등과 같은 지리적 특성을 이용한 서비스에서 사용됩니다.

TTL 인덱스(Time-To-Live Index)

• TTL(Time-To-Live) 인덱스는 MongoDB에서 지원하는 인덱스 중 하나로, 일정 기간이 지나면 데이터를 삭제하는 인덱스입니다. 즉, 데이터의 유효기간을 설정하여 그 기간이 지난 데이터를 자동으로 삭제해주는 역할을 합니다.
  
  TTL 인덱스는 적용할 필드에 일정 기간을 설정하면 해당 기간이 지나면 데이터가 자동으로 삭제됩니다. 예를 들어, create_at 필드에 1일을 설정했다면, 1일이 지나면 해당 데이터는 자동으로 삭제됩니다.
  
  TTL 인덱스는 일반적으로 로그 데이터, 세션 데이터 등 유효기간이 정해져 있는 데이터에 많이 사용됩니다. 이를 통해 필요하지 않은 데이터가 지속적으로 쌓이는 것을 방지하고, 데이터의 용량을 줄일 수 있습니다.

해시 인덱스(Hashed Index)

• 해시 인덱스(Hashed Index)는 해시 함수(Hash Function)를 사용하여 인덱스를 생성하는 인덱스 종류입니다. 해시 기반의 인덱스이기 때문에 O(1)의 시간복잡도를 가지며, 검색 성능이 매우 빠릅니다. 해시의 특성상 정렬이 불가하고, 인덱스의 크기가 고정되어 있기 때문에, 데이터가 많아져 해시가 충돌할 수록 인덱스의 성능이 저하될 수 있습니다. 해시 인덱스는 주로 전체 데이터에서 일부 데이터를 빠르게 검색할 때 사용됩니다.

ERD(Entity Relationship Diagram)란?

• ERD(Entity Relationship Diagram)는 단어에서 의미하는 그대로 'Entity 개체'와 'Relationship 관계'를 중점적으로 표시하여 데이터 베이스 구조를 한 눈에 알아보기 위해 그려놓는 다이어그램입니다. 개체 관계도라고도 불리며 요구 분석 사항에서 얻은 개체와 속성들의 관계를 그림으로 표현할 수 있습니다.

ERD에서 Entity 표기법

Entity

• Entity는 정의 가능한 사물 또는 개념을 의미합니다.

• 학생과 학생의 취미를 표현할 때, 학생은 유형 Entity, 학생의 취미는 무형 Entity로 구별할 수 있습니다.

• 데이터 베이스 테이블을 Entity로 포현할 수 있습니다.

Entity Attribute

• Entity에는 개체가 갖고있는 속성(Attribute)를 포함합니다.

• 데이터 베이스 테이블의 각 컬럼을 Attribute로 표현할 수 있습니다.

Entity Domain

• Domain은 속성의 값, 타입, 제약 사항 등의 대한 값의 범위를 표현할 수 있습니다.

• 사용자 기호에 따라 속성 타입만 그릴수도 있고, 가독성을 위해서 생략할 수도 있습니다.

• 데이터 타입을 명시할 때, 사용할 데이터 베이스가 지원하는 타입에 맞게 표시합니다.

ERD 키와 제약 조건 표기법

기본 키(Primary key)

• Primary Key는 속성 앞에 ◆를 기재하여 표현합니다.(ERD 프로그램에 따라 다름)

• Primary Key는 다른 속성들과 구분하기 위해서 구분선을 두기도 합니다.

외래 키(Foreign Key)

• 데이터 베이스 테이블의 Foreign Key를 표현할 때 해당 Foreign Key를 Primary Key로 들고 있는 개체와의 선을 이어주어 관계를 표시합니다.

• 외래 식별자 역시 Key의 일종이라 ERD Entity에서도

NOT NULL

• 해당 속성에 들어갈 값에 NULL을 허용하지 않는다면 N 또는 NN을 적습니다.

• NULL을 허용한다면 아무것도 적지 않습니다.

ERD의 Entity 관계 표기법

• Entity간의 관계를 표현할 때 선을 이어주어 표현합니다. 이 때 강한 연결관계 또는 약한 연결관계에 따라서 실선 또는 점선으로 표현합니다.

강한 연결관계(식별자 관계)

• FK를 자신의 PK에 사용한다면 강한 연결관계로서 실선으로 관계를 표현합니다.

약한 연결관계(비식별자 관계)

• FK를 자신의 속성에 사용한다면 약한 연결관계로서 점선으로 관계를 표현합니다.

ERD Entity 관계의 Cardinality

• 관계가 존재하는 두 Entity 사이에 관계 수를 표현하는 방법은 아래와 같습니다.

ERD 관계 표현 방법

• '|' 표시가 있는 곳은 반드시 있어야 하는 개체. (필수)

• 'O' 표시가 있다면 없어도 되는 개체. (선택)

• 이와 같은 표현 방법으로 1:1, 1:N, M:N 등의 표현을 할 수 있습니다.

관계의 선택 기호

• 취미를 가지지 않는 학생이 있을 수는 있지만, 취미는 있는데 학생이 없는 경우는 없습니다. 즉, 이러한 경우 취미쪽을 선택 기호를 이용해서 표현합니다.

관계의 필수 기호

• 취미가 있다면, 해당 취미를 가진 학생은 반드시 존재해야 합니다. 즉, 어느 한쪽에 존재한다면 다른 쪽은 반드시 존재해야 하는 관계를 필수 관계 기호를 사용해 표현합니다.

• 참고 자료 : https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-1N-%EA%B4%80%EA%B3%84-%F0%9F%93%88-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8

데이터 모델링이란?

• 데이터 모델링이란 정보 시스템 구축의 대상이 되는 업무 내용을 분석하고 이해하여, 필요한 데이터를 약속된 표기법에 의해 표현하는 것을 의미합니다.
  
  특히 데이터를 추상화한 데이터 모델은 데이터 베이스의 골격을 이해하여 개선점을 찾을 수 있고, 그 이해를 바탕으로 SQL을 조금 더 효율적으로 작성할 수 있기 때문에, 데이터 모델링은 데이터 베이스 설계의 핵심 과정입니다.

데이터 모델링 과정

1. 업무 파악(요구 사항 수집 및 분석)

• 업무 파악 단계에서는 요구사항 수집과 분석을 통해 모델링할 데이터를 정합니다.

2. 개념적 데이터 모델링

• 개념적 데이터 모델링은 데이터 간의 관계를 구상하는 단계입니다. 각 개체들간의 관계를 ERD(Entity-Relationship Diagram) 중 하나인 피터 첸(Peter Chen) 표기법을 이용해 개체간의 관계를 표현할 수 있습니다.

3. 논리적 데이터 모델링

• 개념적인 데이터 모델이 완성되면, 구체화된 업무 중심의 데이터 모델을 만들어 내는데, 이것을 논리적인 데이터 모델링이라고 합니다.
  이 단계에서는 데이터에 대한 Key, 속성, 관계등을 표시하며, 정규화 활동을 수행합니다.

• 개념적 데이터 모델링을 위해 표현된 ERD를 정보 공학 표기법(Information Engineering Notation)인 테이블 형태로 재구성하여 논리적 데이터 모델링을 수행합니다.

4. 물리적 데이터 모델링

• 물리적 데이터 모델링은 최종적으로 데이터를 관리할 데이터 베이스를 선택하고, IE 모델을 기반으로 테이블을 만드는 작업을 수행합니다.

데이터 모델링 절차 정리

• 데이터 모델링 요약 정리

• 1. 게시판을 구현하는데 필요한 요구 사항 수집 및 분석을 통해 모델링할 데이터를 정의합니다.

• 2. 데이터들의 관계를 파악하고 이를 ERD를 통해 표현하여 개념적 데이터 모델링 수행합니다.

• 3. 개념적 데이터 모델을 기반으로 논리적 데이터 모델링을 하여 key, 속성, 관계를 구체화하고 정규화 과정을 통해서 데이터의 이상 현상이나 중복 데이터를 제거합니다.

• 4. 논리적 데이터 모델을 기반으로 데이터 베이스를 선정하고 테이블을 생성합니다. 그리고 이것을 물리적 데이터 모델링이라고 합니다.

ORM(Object Relational Mapping)이란?

• ORM(Object-Relational Mapping)은 객체 지향 프로그래밍 언어에서 사용되는 객체와 관계형 데이터베이스 시스템(RDBMS) 간의 데이터 매핑을 자동화 하는 기술입니다.
  즉, 객체 지향 프로그래밍 언어에서 사용하는 클래스와 관계형 데이터베이스에서 사용하는 테이블 간의 매핑을 수행하고, 객체를 통해 데이터베이스를 조작할 수 있도록 지원합니다.

ORM의 장.단점

ORM 장점

• 생산성 향상: ORM을 사용하면 SQL을 사용하지 않고 객체를 이용해 데이터를 조작할 수 있기 때문에 개발 시간이 단축됩니다.

• 유지보수 용이: ORM을 사용하면 객체 지향적인 방법으로 개발이 가능하므로 코드의 가독성이 좋아지고 유지보수가 용이해집니다.

• DBMS 독립성: ORM을 사용하면 DBMS를 변경해도 소스 코드를 변경할 필요가 없기 때문에 DBMS 독립성이 보장됩니다.

ORM 단점

• 복잡성: ORM은 데이터베이스에 대한 지식이 없어도 객체 지향 언어만으로 데이터베이스를 조작할 수 있지만, ORM 자체가 복잡할 수 있습니다. 특히 복잡한 데이터 모델이나 쿼리를 처리할 때 ORM을 사용하면 코드가 복잡해질 수 있습니다.

• 제한된 SQL 기능: ORM을 사용하면 SQL 코드의 일부 기능을 사용할 수 없거나, 복잡한 SQL 쿼리를 작성하기 어려울 수 있습니다.

ODBC(Open Databse Connectivity)?

• ODBC는 Open Database Connectivity의 약자로, 데이터베이스와 상호작용하기 위한 표준 API입니다. ODBC는 독립적인 데이터베이스 액세스 방법을 제공합니다.

• ODBC는 C, C++, Java 및 .NET과 같은 다양한 프로그래밍 언어에서 사용될 수 있으며, 대부분의 주요 데이터베이스 관리 시스템과 호환되며, 데이터베이스 액세스를 단순화하고 다른 데이터베이스 관리 시스템 간의 이식성을 향상시키는 데 중요한 역할을 합니다.

DBCP( DB Connection Pool )란?

• 미리 DB 서버와 Connection들을 만들어 놓고 필요할 때마다 Connection Pool에서 이미 연결되어 있는 Connection을 가져오고 이용해 반납하는 방식을 DBCP( DB Connection Pool )이라고 합니다. 이 덕분에 TCP의 Connect을 맺고 끊는 추가적인 작업을 서버가 가동될 때 한 번에 처리하기 때문에 네트워크 트래픽과 성능의 이점이 있습니다.

DBCP를 사용하기 위한 DB 서버 설정 몇가지

DB 서버의 max_connections

• Connection Pool을 설정할 때 DB 서버의 max_connections의 개수를 설정해야 합니다. 이때 고려해야 할 부분은 여러 대의 서버에서 Connection Pool을 사용할 것을 고려해서 설정해야 합니다.

DB 서버의 wait_timeout

• wait_timeout은 connection이 inactive 할 때 다시 요청이 오기까지 얼마의 시간을 기다린 뒤에 close할 것인지를 결정할 때 사용합니다.

DBCP에서 적절한 Connection 수를 찾기 위한 과정

• 모니터링 환경 구축( 서버 리소스, 서버 쓰레드 수, DBCP 등등)

• 백엔드 시스템 부하 테스트( 네이버의 nGrinder )

• reqeust per seconds와 avg response time 확인

모니터링 시 확인해야 할 사항

• 사용할 백엔드 서버 수를 고려하여 DBCP의 max pool size 결정

• 백엔드 서버와 DB 서버의 CPU, MEM 등등 리소스 사용률 확인

• thread per request 모델이라면 active thread 수 확인

• DBCP의 active connection 수 확인

• 자료 참조 : https://www.youtube.com/watch?v=zowzVqx3MQ4&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=27

파티셔닝( Partitioning )

• 데이터베이스 table을 더 작은 table들로 나누는 것을 의미합니다.

파티셔닝의 종류

vertical partitioning

vertical partitioning의 종류

• 정규화 과정을 통해서 테이블을 나누는 방식

• 자주 사용되지 않고 너무 큰 데이터의 column은 테이블로 나누는 방식

• 민감한 정보에 제한을 더 걸기 위해서 테이블을 나누는 방식

• 자주 사용되는 column과 자주 사용되지 않는 column을 모아 테이블을 나누는 방식

horizontal partitioning

• vertical partitioning은 column을 기준으로 partitioning을 하기 때문에 테이블의 스키마가 변경되지만, horizontal partitioning은 row를 기준으로 partitioning을 하기 때문에 테이블의 스키마는 유지됩니다.

horizontal partitioning이 필요한 이유

• 테이블에 튜플이 점점 추가됨에 따라서 인덱스의 크기도 커지기 때문에 테이블에 읽기/쓰기/수정/삭제가 있을 때마다 인덱스에서 처리되는 시간도 조금씩 늘어납니다.

horizontal partitioning 종류

• hash-based horizontal partitioning은 특정 attribute를 해쉬하여 나온 값을 기준으로 partitioning을 하는 것을 말합니다.

• range-based horizontal partitioning은 특정 attribute의 범위를 정하여 partitioning을 하는 것을 말합니다.

hash-based horizontal partitioning

• 특정 attribute를 hash하여 hash에 나온 값을 기준으로 테이블을 나누어 저장하는 방식을 말합니다. hash에 사용된 attribute를 partition key라고 합니다.

hash-based horizontal partitioning 주의점

• partition key는 가장 많이 사용될 패턴에 따라 선택해야 테이블을 나눈 이점을 최대한 얻을 수 있습니다.

• 한 번 partition을 나눈 테이블에 partition을 추가하는 것은 굉장히 어렵습니다. 이미 저장된 데이터의 partition key를 기준으로 재해쉬하여 다시 partition하여 저장해야하기 때문입니다.

sharding

• sharding은 horizontal partitioning으로 나누어진 table들을 각각의 DB서버에 저장하는 방식을 말합니다.

• sharding에서 partition key를 shard key라고 부릅니다. 그리고 각 partition을 shard라고 부릅니다.

sharding이 필요한 이유

• horizontal partitioning은 결국 하나의 DB서버에서 나누어진 partition을 관리하기 때문에 각 partition에 대한 요청도 하나의 DB서버에 몰려 부하가 집중됩니다. 그렇기 때문에 DB 서버의 부담을 줄이기 위해서 sharding을 통해 각 shard을 독립된 DB서버에 저장하여 각 shard에 대한 요청을 분산하여 DB서버의 부하를 줄일 수 있습니다.

replication

• DB를 복제해서 여러 대의 DB 서버에 저장하는 방식을 말합니다.

• 기존 DB를 master/primary/leader라고 부르며 복사된 DB를 slave/secondary/replica라고 부릅니다.

• secondary는 primary와 데이터가 동일한 상태에서 primary에 요청되어 변경된 데이터들을 계속해서 확인하여 sync를 맞춥니다.

• secondary는 여러 대가 있을 수 있습니다.

replication의 High availability(고가용성) 이점

• 서비스중에 primary DB서버에 문제가 생겼다면 secondary중에 하나가 primary를 대체하여 서비스가 정상적으로 유지될 수 있도록 할 수 있습니다. 이처럼 자동적으로 장애를 극복하여 서비스가 유지되도록 하는 것을 failover라고 합니다.

replication의 읽기/쓰기 분산 이점

• 대부분의 서비스는 write보다는 read 트래픽이 훨씬 많습니다. write는 동기화를 확실히 맞출 필요가 있지만 대부분의 서비스에서 read는 정확한 동기화까지는 필요가 없기 때문에 read를 secondary로 처리할 수 있도록 하여 부하 분산을 할 수 있습니다.

참고 자료 : https://www.youtube.com/watch?v=P7LqaEO-nGU&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=26

index의 종류

• RDBMS에서 index의 종류는 크게 Clustered 와 Non-Clustered 로 나뉩니다.

Clustered Index란?

• Clustered는 군집화 라는 뜻을 가집니다. 즉, Clustered Index는 군집화된 인덱스로서 데이터와 인덱스를 합쳐놓은 인덱스를 Clustered Index라고 합니다.

• Clustered Index는 사전에서 가나다 순으로 찾기 좋게 정렬되어 있고, 책의 모서리에 ㄱ, ㄴ ,ㄷ 표시를 확인하여 접근하는 방식과 유사합니다.

Clustered Index 작동 방식과 특징

• Clustered Index를 만들면 위 그림에서와 같이 루트 페이제에 각 Index 값과 리프 페이지의 위치 정보에 해당하는 첫 번째 데이터를 맵핑시켜 저장합니다.

• 데이터 페이지는 Clustered Index를 기준으로 항시 자동 정렬됩니다.

• 데이터 페이지를 리프 페이지로 사용합니다.

• 한 테이블에 한 개씩만 만들 수 있습니다.

• MySQL에서는 Primary Key가 있다면 Clustered Index로 지정되며, Primary Key가 없다면 unique하면서 not null인 컬럼을 Clustered Index로 하며 이것도 없다면 보이지 않는 컬럼을 만들어 Clustered Index로 지정합니다.

Clustered Index 장점

• 데이터 자체가 Clustered Index를 기준으로 정렬되어 있으며, 리프 페이지가 곧 접근하고자 하는 데이터이기 때문에 인덱스를 위한 추가적인 저장 공간을 사용할 필요가 없습니다.

• Non-Clustered Index보다 Index를 통한 검색 속도가 빠릅니다.

Clustered Index 단점

• 데이터 페이지는 Clustered Index를 기준으로 정렬되기 때문에 기존에 많은 데이터가 추가된 테이블에 Clustered Index를 지정하면 DB에 많은 부하가 발생됩니다.

• Non-Clustered Index보다 Index를 통한 검색 속도가 빠르지만, 입력/수정/삭제는 상대적으로 더 느립니다.

Non-Clustered Index란?

• Non-Clustered Index는 보조 인덱스로서 <목차> 또는 <찾아보기>를 통해서 페이지 넘버를 확인하고 접근하는 방식과 유사합니다.

Non-Clustered Index 작동 방식

• Non-Clustered Index 역시 루트 페이지가 만들어집니다. 하지만, Clustered Index 처럼 리프 페이지가 데이터 페이지인 것과는 달리 리프 페이지에 index 값과 데이터 페이지에서 몇 번째 위치에 Index인지에 대한 대한 정보를 맵핑하여 저장합니다.

• Non-Clustered Index는 index와 위치 정보를 맵핑한 테이블 데이터가 필요하기 때문에 추가적인 저장 공간이 필요합니다.

• 데이터 페이지는 정렬하지 않고 리프 페이지에 있는 Index를 기준으로 정렬합니다.

• 데이터 페이지에는 직접적인 영향을 주지 않기 때문에 Clustered Index 달리 여러개 생성이 가능합니다.

Non-Clustered Index 장점

• Clustered Index보다 Index를 통한 검색 속도가 느리지만, 입력/수정/삭제는 상대적으로 더 빠릅니다.

• 입력/수정/삭제 시 데이터 페이지가 아닌 리프 페이지만을 정렬 시키기 때문에 Clustered Index보다 DB에 주는 부하가 적습니다.

Non-Clustered Index 단점

• 리프 페이지에는 Index에 대한 값과 맵핑된 데이터 페이지의 위치 정보를 맵핑한 저장 공간이기 때문에 Clustered Index 보다 필요한 저장 공간이 더 필요합니다

• 리프 페이지에서 데이터 페이지로 접근하기 때문에 Clustered Index 보다 검색 속도가 상대적으로 느립니다.

- 자료 참조 : https://inpa.tistory.com/entry/MYSQL-%F0%9F%93%9A-%EC%9D%B8%EB%8D%B1%EC%8A%A4index-%ED%95%B5%EC%8B%AC-%EC%84%A4%EA%B3%84-%EC%82%AC%EC%9A%A9-%EB%AC%B8%EB%B2%95-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC#%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0_%EC%9D%B8%EB%8D%B1%EC%8A%A4_(Primary_Index)

index를 사용하는 이유

• 조건을 만족하는 튜플을 빠르게 조회하기 위해 사용합니다.

• 빠르게 정렬(order by)을 하거나 그룹핑(group by)하기 위해 사용합니다.

index와 select의 where 조건문

select * from customer where first_name = 'Minsoo';

• first_name에 index가 걸려있지 않다면 테이블 전체를 scan하여 first_name의 값이 'Minsoo'인 튜플을 찾습니다. 이를 full scan이라고 하며 이때 시간 복잡도는 O(N)입니다.

• first_name에 index가 걸려있다면 full scan보다 더 빨리 찾을 수 있습니다. 만약, B-tree 기반의 index라면 이때 시간 복잡도는 O(logN)입니다.

index의 이점을 얻을 수 있는 쿼리문들 몇가지

select * from customer where first_name = 'Minsoo';

delete from logs where log_datetime < '2022-0101';

update employee set salary = salary * 1.5 where dept_id = 1001;

select * from employee as E join department as D on e.dept_id = d.id;

• 위 쿼리문들의 조건 부분에 index를 주었을 때 성능의 이점을 얻을 수 있는 쿼리문입니다.

사용중인 player 테이블에 index 걸기

-- 중복을 허용하는 index 생성
-- create index (index 이름) on 테이블명 (attribute 이름);
create index player_name_idx on player (name);


-- 중복을 허용하지 않는 index
-- backnumber는 중복되기 때문에 temm_id와 같이 묶어서 index 처리
create unique index team_id_backnumber_idx on plyaer (team_id, backnumber);

player 테이블을 생성하면서 index 걸기

create table player(
    id int primary key,
    name varchar(20) not null,
    team_id int,
    backnumber int,
    index player_name_idx (name), -- name은 동명이인이 있기 떄문에 그냥 index 그리고 index이름은 생략 가능
    unique index team_id_backnumber_id (team_id, backnumber)
);

show index from player;

• team_id, backnumber와 같이 두 개 이상의 컬럼을 이용해 index를 거는 경우를 multicolumn index 또는 composite index 라고 합니다.

• primary key에는 RDBMS가 자동으로 unique index로 생성합니다.

• show index player; 는 player 테이블에 있는 index 정보를 가져올 수 있습니다.

B-tree 기반의 index의 동작 방식

• 위 그림에서의 왼쪽은 a attribute의 index를 걸었을 때 오름 차순으로 생성되는 a와 a값을 가진 튜플에 대한 맵핑 테이블입니다.

• 위와 같은 index 정보를 기반으로 a에 대한 조건으로 튜플을 찾을 때 바이너리 서치를 통해 접근합니다.

• where a = 7 and b = 95;에 대한 조건으로 튜플을 찾는다면 a는 index 정보를 기반으로 바이너리 서치를 하지만 b는 a를 기준으로 찾은 튜플을 대상으로 full scan을 합니다.

B-tree 기반의 multicolumn index의 동작 방식

• 위 그림에서 왼쪽은 a, b를 묶어서 index를 걸었을 때 a에 대한 오름차순 후에 b에 대한 오름 참순으로 생성된 index입니다. 즉, 왼쪽 column을 기준으로 오른쪽으로 오름 차순으로 index를 생성하기 때문에 multicolumn index를 만들 때 컬럼의 순서가 중요합니다.

• where a = 7 and b = 95;에 대한 조건으로 튜플을 찾는다면 a = 7에 대한 조건을 바이너리 서치로 먼저 찾은 후 b = 95에 대한 조건을 바이너리 서치로 찾아 접근합니다. 그렇기 때문에 where a = 7 and b = 95;을 조건으로 찾는 쿼리문이 많다면 a, b를 index로 설정하는 것이 좋은 선택일 수 있습니다.

• 만약, 위와 같이 index가 걸려있는 상태에서 where b = 95; 조건으로 튜플을 검색하더라도 위의 index를 온전히 활용하여 성능을 뽑아낼 수는 없습니다. 그렇기 때문에 where b = 95;를 조건으로 하는 쿼리문이 많다면 b에 대한 index를 생성하는 것이 좋을 수 있습니다.

• 만약, 위와 같이 index가 걸려있는 상태에서 where a = 7;를 조건으로 튜플을 검색하면 a에 대한 값을 기준으로 index가 생성되어 정렬되어 있기 때문에 index를 이용한 성능을 보장받을 수 있습니다.

EXPLAIN

• index가 위 그림에서 나온것 처럼 걸려있다면 backnumber를 조건으로 튜플을 검색할 때 어떤 index를 이용해 검색하는지를 확인하고 싶다면 EXPLAIN을 통해 확인이 가능합니다. possible_keys는 사용 가능한 index에 대한 이름을 의미하며, key는 사용된 index에 대한 이름을 의미합니다.

use index & force index & ignore index

• 위와 같이 조건문에 대한 index를 어떤 것으로 선택할지는 RDBMS의 optimizer가 알아서 선택하지만, 간혹 의도하지 않은 index를 선택하여 성능이 좋지 못한 경우가 있습니다. 그럴 경우 위 그림에서와 같이 use index를 이용해서 어떤 index를 사용할지 명시할 수 있습니다.

• use index 문법은 권장해 달라고 요청하는 문법이지만, 강력하게 어떤 index를 사용하라고 요청할 때에는 force index를 사용합니다.

• 만약 특정 index를 사용하지 않겠다면 ignore index(index name) 문법을 사용하면 됩니다.

index를 주의해서 사용해야 하는 이유

• index를 생성할 때마다 위와 같이 index에 대한 테이블이 생성되기 때문에 추가적인 저장 공간이 필요합니다.

• index가 걸린 attribute에 write를 할 때마다 B-tree를 다시 조정해야 하는 추가작업이 필요합니다.

• 만약 index(team_id, backnumber)가 걸려있다면 team_id에 대한 추가적인 index는 불필요 합니다.

Covering index

• 위 그림에서와 같이 team_id를 이용해서 team_id, backnumber에 대한 데이터를 가져올 때 필요한 데이터가 index에 모두 있다면은 player 테이블에 접근하지 않고 index에 있는 데이터만을 가지고 select 문을 수행합니다. 이를 통해 테이블에 접근해야 하는 추가적인 작업이 없기 때문에 성능이 훨씬 좋으며, 이를 Covering index라고 하며 의도해서 Covering index를 만드는 경우도 있습니다.

B-tree index와 Hash index의 차이

• hash table을 기반으로 index를 구현합니다.

• 시간 복잡도는 O(1)입니다.

• 데이터가 추가됨에 따라서 rehashing이 일어날 수 있습니다.

• index를 조건으로 하여 쿼리문을 수행할 때 equality 비교만 가능하며 >, =>, <, <= 와 같은 range 비교는 불가능합니다.

• B-tree에서 (a, b)와 같이 multicolumn index를 지정하면 a만을 이용해 index를 활용할 수 있지만, hash 기반의 index는 무조건 (a, b)로 조건을 걸었을 때만 index를 활용할 수 있습니다.

Full scan이 좋은 경우

• table에 데이터가 몇 백건 정도만 있는 경우 Full scan을 통한 검색이 나을 수 있습니다.

• 조회하려는 데이터가 테이블의 상당 부분을 차지하면 Full scan이 더 나을 수 있으며 이 또한 optimizer가 판단합니다.