인덱스 (Clustered 인덱스, Non-clustered 인덱스)

 

인덱스는 색인과 같은 개념이다.

인덱스를 사용하면 데이터베이스에서 사용하는 용량이 많아진다는 문제점이 있고, 조회를 효율적이게 할 수 있지만 삽입, 업데이트, 삭제와 같은 나머지 연산들은 오히려 비효율적이게 만든다는 단점이 있다. 

 

 

 

Clustered 인덱스

Clustered 인덱스는 데이터베이스에 저장돼있는 데이터 자체를 특정 순서대로 저장하는 인덱스입니다. 예를 들어 이 user 테이블에서 이메일 column에 대한 clustered 인덱스를 만든다고 할게요. 그럼 데이터베이스 테이블 안의 내용이 실제로 email의 알파벳 순서대로 저장이 됩니다. a에서 시작해서 쭉 z까지 이메일들이 순서대로 저장이 됩니다.

 

이메일이 순서대로 저장돼있으니까 특정 이메일을 찾을 때는 이 순서를 이용해서 데이터를 찾을 수 있죠.

Clustered 인덱스는 일반적으로 조회 속도가 굉장히 빠르다는 장점이 있습니다. 하지만 데이터를 특정 순서대로 저장했기 때문에 Clustered 인덱스는 하나밖에 만들 수 없습니다. 지금은 데이터를 이미 이메일 순서대로 정렬해놨는데, 여기서 이메일 순서로도 정렬돼있으면서, 동시에 이름 순서대로 정렬할 수는 없죠.

책으로 비유를 하면, 책 가장 뒤에 따로 인덱스를 만들어놓는 게 아니라, 영한 사전 같이 애초부터 단어들을 알파벳 순서대로 저장하는 겁니다.

이렇게 하면 찾고 싶은 영어 단어는 빠르게 찾을 수 있겠지만, 이미 알파벳 순서대로 책을 만들어놨기 때문에, 사전 안에서 특정 한글 단어를 찾고 싶을 때는 선형 탐색을 사용해야 합니다.

 

Non-clustered 인덱스

Non-Clustered 인덱스는 로우들이 실제 저장된 순서 자체는 건들지 않고, 위에서 얘기했던 거처럼 아예 데이터베이스 다른 곳에 컬럼 값들의 순서를 저장하는 방법입니다.

이메일에 대한 non-clustered 인덱스를 만들면 데이터베이스의 다른 곳에 이런 식의 데이터를 저장하는 거죠. 각 이메일에 대해서 해당 row의 유저가 저장된 주소를 저장합니다. 그래서 원하는 이메일을 찾았을 때, 주소를 사용해서 바로 원하는 유저 row를 찾을 수 있죠.

Non-Clustered 인덱스는 실제 테이블과 무관하게 순서를 저장하기 때문에 개수의 제한이 없습니다. 그 어떤 column에 대해서도 non-clustered 인덱스를 만들 수 있습니다.

아무래도 실제 테이블과 다른 곳에 저장돼있기 때문에 데이터를 찾는 게 clustered 인덱스보다 조금 느리다는 단점을 갖고 있습니다.

Non-clustered 인덱스는 얘기했던 것과 같이 책의 색인, 또는 인덱스랑 비슷합니다. 책 내용은 그대로 유지하면서, 따로 개념들을 정렬해놔서, 언제든지 원하는 개념을 빠르게 찾을 수 있도록 하죠.