DB를 사용할 때, index라는 말을 많이 듣게 됩니다. 한국말로는 ‘색인’이라고 합니다. 예를 들어, 우리에게 엑셀파일이 있고, 이 파일에 행이 1억개 정도 있다고 해봅시다. 그리고, 무엇이 어디에 있는지 정확하게 알지 못해서, 매번 처음부터 끝까지 다 찾아야 한다고 해보죠. 그러니까, 매번 반복되는 작업을 위해서, 1억개의 행이 있는 테이블을 full-scan해야 한다는 것이죠. 이 얼마나 번거롭고 쓸데없는 짓입니까.
여기서 다시, 우리 한번 전화번호부를 생각해봅시다. 아, 어쩌면 전화번호부라는 것을 안다는 것 자체가 굉장히 아재가 되는 것이기도 하네요. 아무튼, 전화번호를 보면, ㄱ부터 ㅎ까지, 다양한 목차가 있습니다. 즉, 내가 찾으려는 것이 ㅎ에 있다면, full-scan할 필요없이, 바로 저 곳으로 갈 수 있다는 것이죠. 그렇습니다. 아주 간단하고, 파워풀한 일종의 하이퍼링크 같은 것이며, 이것이 바로 DB에서 index를 말하는 것과 완전히 동일합니다.
즉, 이를 정리하자면,
DB에서 어떤 칼럼에 대해서 index를 만들어준다는 것은,
만약 SQL에서 where등을 통해, 특정 칼럼에 대해서 어떤 기준을 충족하는 로우(row)만 찾고 싶을 때,
index가 없다면, 이러한 query가 들어올 때마다, 매번 해당 테이블을 scan해야 하는 반면에
index, 즉, (칼럼의 값, row_id)로 묶어둔, 인덱스가 존재하면, 이를 통해 빠르게 적합한 row를 찾아낼 수 있기 때문에 훨씬 효과적이다.
라는 것을 말합니다.
wrap-up
언제나 그렇듯이, 이렇게 index를 따로 만들어두면, read측면에서는(특히, join과 함께라면) 훨씬 효과적으로 작동할 수 있습니다. 그러나, read가 아니라, update/insert등에 대해서는, 테이블을 업데이트하고, 바로 INDEX에서도 업데이트가 되므로, 부하가 좀 더 걸리게 되겠죠.
늘 느끼는 것이지만, DB에서 발생하는 문제점들을 명확하게 이해하려면, 대용량의 데이터를 직접 다뤄보는 것이 필요합니다. 조금 슬픈 것은, 제가 연구 등의 목적으로 평소에 사용하는 데이터는 csv로 읽어서 처리해도 될 정도로 아주 작은 데이터라는 것이죠. 따라서, ‘DB에서 index가 필요하다’는 것을 외울 수 는 있어도, ‘왜 필요한지’에 대해서 현실적인 공감을 가지기는 어렵습니다. 사실, 연구실 단위에서 생활하면서 가장 슬픈 것이 이런 것이죠.
댓글남기기