336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

사용자 정보를 텍스트 파일로 관리하거나 정보 확인을 위해서 처음부터 탐색하여 찾을 때가지 검색하는 방법은 매우 비 효율 적이다.

이를 개선하기 위해 사용자 정보를 고정 길이로 관리하는 기술은 사용자 정보의 시작 위치는 빨리 찾을 수는 있어도 가변 길이 방식으로 데이터를 관리하는 경우에는 부적합 하다.

해결책은 인덱스 구조를 도입하는 것인데 책의 색인과 같이 키워드와 페이지의 구조로 되어 있고 책의 본문과는 독립적인 형태로 관리되고 있다.

이것을 으용하면 사용자 정보를 취급하는 가변 길이 포맷의 문서와는 별도로 "각각의 사용자 ID마다 파일 상의 시작 위치를 기록한 파일"을 만들어 둠으로써 고속으로 사용자 정보를 찾을 수 있다. 이것이 바로 인덱스 라는 구조 이다.

"키 값, 바이트 위치" 라는 인덱스 항목을 활용할 수 있는데 액세스가 2단계 필요하다는 단점이 있지만, 어느 쪽도 데이터 양에 의존하지 않는 비용으로 값을 취할 수 있기 때문에 데이터의 양에는 의존하지 않고 상당히 빠른 검색이 가능하다


해시 인덱스

앞서 인덳 항목은 키와 바이트 위치의 고정 길이 포맷에 대응을 했는데 키 값의 데이터 항목이 숫자, 문자열, 날씨/시간 등 여러가지를 생각할 수 있으므로 좀 더 범용성을 추구하려면 키 값을 해시 함수를 대입하여 해시 값과 값을 쌍으로 갖는 구조가 즐겨 사용되고 있다.

해시 인덱스는 편리하지만 목적을 당성하지 못하는 일도 종종 있다. 예를들어, "가격이 만원 이하의 선물을 찾고 싶다" 와 같이 키가 되는 것은 가격인데 키의 값이 몇 개로 반환될지 사전에 알 수 없다. 해시 인덱스는 지정한 키 값과 같은 것밖에 찾을 수 없기 때문에 이러한 목적으로는 사용할 수 없다.

결국 많은 검색 작업에서 단지 일부 용도에서만 빠르게 처리할 수 있다 라는 정도로 생각해야 한다.

이를 해결 하기 위해서 나온 것이 바로 B+Tree 라고 불리는 인덱스 구조다.


인덱스만을 읽는 검색 (Index Only Read, Covering index)

데이터베이스 구현에 따라서는 데이터 영역을 읽지 않고 인덱스 영역을 읽는 것만으로 처리를 고속으로 완료할 수 있다. 

예를들어, '가격이 만원 이하인 상품의 개수를 알고 싶다'


블로그 이미지

뚱땡이 우주인

,