DB - index

1 분 소요

INDEX in DB

  • 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가 필요하다’는 것을 외울 수 는 있어도, ‘왜 필요한지’에 대해서 현실적인 공감을 가지기는 어렵습니다. 사실, 연구실 단위에서 생활하면서 가장 슬픈 것이 이런 것이죠.

reference

댓글남기기