인프런 커뮤니티 질문&답변

이경환3님의 프로필 이미지
이경환3

작성한 질문수

[C#과 유니티로 만드는 MMORPG 게임 개발 시리즈] Part5: 데이터베이스

복합 인덱스

인덱스의 저장 방식에 대해서 질문이 있습니다!

작성

·

409

·

수정됨

1

안녕하세요 루키스님.
항상 좋은 강의 감사드립니다!!!

인덱스 및 복합 인덱스 강의를 들으면서
생긴 궁금증 하나를 여쭤보려 합니다!

※ 해당 질문은 Clustered Index 기준입니다.

개요.
인덱스 강의 때 Clustered Index는 물리적인 데이터의 저장 순서의 기준이라고 하셨습니다. 따라서 사전처럼 데이터가 키에 따라 정렬된 상태로 저장되는 것으로 이해했습니다.
그런데 복합 인덱스 강의를 들으면서 인덱스가
트리 구조의 페이지로 나뉘고 써칭을 할 때 페이지 트리 탐색 후 찾은 인덱스(키)의 RID를 읽어서 본격 실제 물리적인 데이터를 찾는다고 말씀하셨습니다.

의문.
"데이터가 애초에 정렬된 상태로 저장되면 트리 탐색 혹은 이분 탐색으로 끝날 텐데 왜 굳이 RID를 읽고 한 번 더 써칭을 하는 것일까?"

 

그래서 제가 아래와 유추와 결과를 냈는데
혹시 맞을까요? (Clustered Index 기준)


유추.
"데이터가 물리적으로 정렬된 것은 맞을 것 같은데..
그렇다면 내가 생각한 데이터의 기준이 다를까?
인덱스는 일종의 Key이므로
데이터는 Key와 Value의 조합이겠군?
그렇다면 강의에 말씀하신 데이터는 엄밀히 말하면 Key 데이터와 Value 데이터로 나눌 수 있겠군?"

결론.
인덱스(Key)는 실제 디스크에 정렬된 상태로 저장되지만 그 인덱스(Key)에 대응되는 실제 데이터(Value)는 실제 디스크에 정렬된 상태로 저장되지 않고 대신에 리니어 하게 만 저장된다. 그렇기 때문에 정렬되지 않은 실제 Value를 찾기 위해서 RID를 읽는 것.
(Value 마저 정렬된다면.. 그것 나름대로 또 끔찍하겠군요... 중간에 추가 삽입될 때마다 방대한 데이터가 한 칸씩 뒤로 밀리기 때문에요.)

그래서 인덱스(Key)는 트리 탐색을 하고
인덱스(Key)에 대응되는 Value를 찾기 위해서 RID를 읽고 찾아갑니다.


+

그 다음 강의인 Clusterd vs Non-Clustered를
시청 후 해결됐습니다.

위에서 제가 언급한 결론은
Non-Clustered Index의 경우네요.

그러면 Clustered Index의 경우 Key가 정렬되어 저장된 곳에 바로 Value가 저장되는군요. 그래서 실제 데이터 자체가 디스크에 정렬된 상태로 저장된다고 볼 수 있겠네요.
Non-Clustered에 비해서 검색 속도는 빠르겠지만 대신에 Trade Off로 데이터의 추가 삽입/삭제가 느리겠군요. 왜냐하면 Value 까지 포함한 큰 데이터들이 전부 정렬된 상태를 항상 보장 받아야 하기 때문에요.

 

 

 

답변 1

1

Rookiss님의 프로필 이미지
Rookiss
지식공유자

아주 완벽히 잘 요약을 해주셨네요 -_-b

이경환3님의 프로필 이미지
이경환3

작성한 질문수

질문하기