NON-CLUSTERED 를 잘 모르겠습니다

Question

1. CLUSTERED 는 영한 사전처럼 순서대로 저장된다고 하셨는데 그러면 DB에 INSERT 하는 순서대로 저장되는건가요? 2. NON-CLUSTERED 를 사용하는 이유르 정확하게 모르겠습니다. accountName을 NON-CLUSTERED INDEX로 만들었는데 보통 닉네임을 정할때 중복없이 생성하게 되는데 이걸 색인으로 만들면 특정 이름을 찾는데에 모든 플레이어들의 이름을 다 비교하는게 아닌가요? 만약 그렇게 되면 색인을 넣든 안넣든 똑같은게 아닌가요? 예를들어서 플레이어를 찾을 때 [찾고싶은 플레이어 이름 = '플레이어 이름'] 이런식으로 찾는다 했을 때 굳이 색인이 필요한지 색인을 안하고 [찾고싶은 플레이어 이름 = '플레이어 이름']  이런식으로 찾을 수는 없는건가요? 아니면 색인을 넣어줘야지 위처럼 찾는 기능이 가능한건가요?

Rookiss · Answer

1. 그건 아니구요. 단어에 따라 [물리적으로 저장되는 위치]가 정해진다는 비유이지, 정말 영한 사전처럼 순차적으로 이어서 저장되진 않습니다. 실제로는 트리 계열 (B-Tree) 알고리즘을 이용해서 저장될 위치가 결정되는데 이는 DB 제품마다 조금씩 다를 수 있습니다. 2. 보통 닉네임을 정할때 중복없이 생성하게 되는데 이걸 색인으로 만들면 특정 이름을 찾는데에 모든 플레이어들의 이름을 다 비교하는게 아닌가요?  -> 그렇지 않습니다. 오히려 반대로 이해하고 계시네요. CASE1 : accountName에 색인이 없을 경우 - 특정 이름을 찾고 싶어도 데이터들이 accountName을 기준으로 정렬되어 있지 않으니 모든 데이터의 플레이어 이름을 다 비교해야 함. (데이터 1억개라면 1억번 비교 GG) CASE2:  accountName에 색인이 있을 경우 - 색인을 보고 빠르게 찾을 수 있음 가령, 어떤 1000페이지 짜리 책에 accumulate이라는 단어가 등장하는지 알고 싶다고 가정해봅시다. 책 뒤에 있는 색인을 보면, accumulate()가 122, 125페이지에 등장하는 것을 알 수 있으니 바로 찾을 수 있겠죠. 아마 위 내용이 잘 이해 안 가시는 가장 큰 이유는 자료구조&알고리즘 쪽의 균형 이진 트리 쪽 지식이 부족해서일 것으로 보입니다. 기회가 되면 AVL이나 Red-Black Tree라거나  트리 쪽 공부를 해보면 쉽게 와닿을 것 같네요. 간단하게 요약하면, 균형 이진 트리는 왼쪽은 더 작고, 오른쪽으로 가면 더 큰 형태로 데이터가 저장되어 있습니다. 이런 트리 구조를 accountName에도 응용한다면, 사전 순서상 작은 단어는 왼쪽, 더 크면 오른쪽에 배치하는 형태로 logN 시간 복잡도에 빠르게 서칭할 수 있는 구조를 만들 수가 있습니다. 아니면 색인을 넣어줘야지 위처럼 찾는 기능이 가능한건가요? 찾는 기능 자체는 INDEX 여부와 무관하게 항상 사용 가능합니다. 단 성능 자체가 어마무시하게 차이가 나게 됩니다. INDEX가 걸려있지 않다면, 데이터가 1억개일 경우 1억개를 다 서칭할 것이고 INDEX가 적절하게 걸려 있다면, 100회 미만의 서칭 개수로 데이터를 찾을 수 있게 됩니다.