Gidhub BE Developer

[데이터 중심 애플리케이션 설계] 3장. 저장소와 검색 : 5. 기타 색인 구조

2022-04-23
goodGid

이 글은 내용을 토대로 작성하였습니다.

목차

  1. DB를 강력하게 만드는 데이터 구조

  2. SS테이블과 LSM 트리

  3. B 트리

  4. B 트리와 LSM 트리 비교

  5. 기타 색인 구조

  6. 컬럼 지향 저장소


기타 인덱스 구조

인덱스 안에 값 저장하기

  • 인덱스에서 키는 검색하려는 대상이지만 값은 둘 중의 하나다.

    실제 데이터이거나 실제 데이터가 위치한 로우를 가리키는 참조 값이다.

  • 후자의 경우 로우가 저장된 곳을 힙 파일(Heap File)이라고 한다.


힙 파일 접근 방식

  • 힙 파일 접근 방식은 키를 변경하지 않고 값을 갱신할 때 효율적이다.
if ( 새로운  크기 < 이전  크기 ) {
// 레코드를 제자리에 덮어씀
} else if ( 새로운  크기 > 이전  크기 ) {
// 힙에서 충분한 공간이 있는 새로운 곳으로 위치를 이동시킨 후 
// 변경된 값과 관련이 있는 참조 값들을 모두 새로운 위치를 가리키도록 수정
}

Clustered Index

  • 인덱스의 값을 읽고 다시 힙 파일로 이동하는 일은 읽기 성능에 불이익이 많다.

    그래서 때로는 인덱스 값으로 찾고자하는 로우 자체를 저장하기도 한다.

    이를 클러스터드 인덱스(Clustered Index)라고 한다.

  • 예를 들어 MySQL의 InnoDB 저장소 엔진에서는

    테이블의 기본키가 Clustered Index이다.


Covering Index

  • Clustered Index(= 인덱스 안에 모든 로우 데이터를 저장)과

    Non Clustered Index(= 인덱스 안에 데이터의 참조만 저장) 사이의 절충안을

    커버링 인덱스(Covering Index)라고 한다.

  • Covering Index는 컬럼 일부를 저장한다.

    이렇게 하면 인덱스만 이용해 일부 질의에 응답할 수 있어진다.

    그리고 이런 경우를 “인덱스가 질의를 커버했다” 표현한다.


다중 컬럼 인덱스

  • 지금부터는 하나의 키만 가진 인덱스가 아닌

    n개의 키를 가진 다중 컬럼 인덱스에 대해 알아본다.


Concatenated Index

  • 다중 컬럭 인덱스 중 가장 일반적인 유형은 결합 인덱스(Concatenated Index)이다.

    Concatenated Index는 하나의 컬럼에 다른 컬럼을 추가하는 방식으로

    하나의 키에 여러 필드를 결합한다.

    (필드가 연결되는 순서는 인덱스 정의에 명시한다.)

  • 이 방법은 키를 (성, 이름), 값을 전화번호 로 하는 인덱스를 제공하는 전화번호부와 비슷하다.

    순서가 정렬돼 있으므로 특정 성을 가진 모든 사람을 찾거나

    특정 성 이름 조합을 가진 사람을 찾을 때 Concatenated Index를 사용할 수 있다.

  • 하지만 특정 이름을 가진 모든 사람을 찾을 때는 쓸모가 없다.


Fuzzy Index

  • 위 인덱스들은 정확한 데이터를 대상으로 질의할 수 있음을 가정했다.

    그래서 틀린 단어와 같이 유사한 키에 대해서는 검색할 수 없다.

    이처럼 모호한(Fuzzy) 질의에는 다른 기술이 필요하다.

    예를 들어 트라이(Trie) 자료구조가 있다.


인메모리 (= 모든 것을 메모리에 보관)

탄생 배경

  • 위에서 언급한 데이터 구조는 모두 디스크의 한계에 대한 해결책이다.

    디스크는 메인 메모리와 비교해 다루기 어렵다.

  • 만약 HDD 혹은 SSD 사용 시 R/W에서 좋은 성능을 위해선

    디스크에 데이터를 잘 배치해야 한다.

    이렇게 까다로움을 참고 디스크를 사용하는 이유로는 2가지가 있다.

    1. 지속성 (전원이 꺼져도 손실되지 않음)
    2. 저렴한 가격
    
  • 그런데 요즈음 램 가격이 저렴해지면서

    메모리에 전체 데이터를 보관하는 방식도 현실적으로 가능해졌다.

    이런 이유로 인메모리 DB가 개발됐다.


장점

  • 인메모리 DB는 장점이

    디스크에서 데이터를 읽지 않아도 된다는 점만 있는 것은 아니다.

  • 디스크 기반 저장소 엔진도 OS가 최근에 사용한 디스크 블록을

    메모리에 캐시하므로 충분한 메모리를 가진 경우에는 디스크에서 읽을 필요가 없어졌다.

  • 오히려 인메모리 데이터 구조를 디스크에 기록하기 위한 형태로

    부호화하는 오버헤드를 피할 수 있어 더 빠르다는 장점도 존재한다.

  • 또 다른 장점으로는

    디스크 기반의 인덱스 구조로는 구현하기 어려운 데이터 모델을 제공한다.

  • 예를 들어 Redis는 Priority Queue와 Set 같은 다양한 데이터 구조를 제공한다.


단점

  • 만약 인메모리 DB가 재시작되는 경우

    특수 H/W를 사용하지 않는다면

    디스크나 복제본에서 데이터를 읽어 인메모리에 적재해야 한다.


Refernece


Index