인덱스와 B-tree
주로 B+tree를 사용한다.
B-tree와 B+tree
비트맵 인덱스도 있지만, 인덱스 갱신의 오버헤드가 크기 때문에 BI/DWH에 사용한다.
BI/DWH?
비즈니스 인텔리전스(Business Intelligence, BI)는 기업에서 데이터를 수집, 정리, 분석하고 활용하여 효율적인 의사결정을 할 수 있도록 지원하는 정보체계이다.
데이터 웨어하우스(data warehouse, DW)란 사용자의 의사 결정에 도움을 주기 위하여, 기간시스템의 데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스를 말한다.
인덱스를 잘 활용하려면
B+tree 자체가 균형이 잘 잡혀있기 때문에, 데이터의 증가에도 검색 속도가 갑자기 악화되는 일(특이점)이 없다. 한편 인덱스를 사용하려면 여러 포인트들을 고려해야 한다.
카디널리티와 선택률
카디널리티는 유니크한 값의 빈도에 비례한다.
선택률은 어떤 값을 선택했을 때 전체 레코드 대비 해당하는 레코드의 비율을 의미한다.
즉, 카디널리티가 높을 수록 선택률은 낮아진다.
→ 이 조건을 가진 인덱싱이 좋은 인덱싱이다.
→ 왜냐? 카디널리티가 낮다 == 선택률이 높다 == 겹치는 레코드가 많다 == 인덱싱으로 식별(탐색)하는 의미가 없다.
구린 인덱스가 풀스캔보다 구린 이유
인덱스로 성능 향상이 어려운 경우
데이터가 늘어날 수록 인덱스 설계도 중요해진다.
인덱스 설계는 테이블 정의와 SQL만 봐서 정할 수 있는 문제가 아니다.
적절한 SQL 작성을 위해서는 검색 조건과 결합 조건을 바탕으로 효율적으로 압축할 수 있는 조건을 알아야 한다 → SQL 구문에 어떠한 키(필드)가 들어가는지, 해당하는 키의 카디널리티는 어떤지를 알아야 한다.
레코드 압축이 어려운 경우
→ 선택률이 높은 경우다(특정 컬럼을 where로 걸어서 보려는데 선택률이 10% 이상으로 넘어가는 경우, 풀스캔이 나을 수 있다).
매개변수에 따라 선택률이 높아지는 경우(shop_id를 보는데 큰 가게는 주문이 많고 작은 가게는 적은 경우..)에 옵티마이저가 잘 결정해주지 못하는 케이스가 생길 수 있다.
→ 인덱스를 걸어서 스캔해버리면 오히려 역효과가 난다.
인덱스를 사용할 수 없는 경우 대처법
외부 설정으로 처리하기
•
그런 쿼리가 실행되지 않도록 어플리케이션에 제한하기
→ 클라이언트의 선택 가능성이 높아지면 서버에 부담(인덱스)이 생길 수 있다.
따라서, 점포 ID로 검색할 때 주문일도 검색하도록 강제한다.
(개인의견) 실제로 해당하는 케이스에 대해서 문제가 생긴다면, 사용자 경험이 조금 해쳐지더라도 개선하는게 나을 수 있겠다 - 오히려 이걸로 속도를 챙기면 사용자 경험 개선일듯.
인덱스 온리 스캔으로 대처
테이블이 아닌 인덱스만을 스캔 대상으로하는 검색
→ 커버링 인덱스(Covering Index, Index only scan)
원하는 query가 이루어지는 필드들에 대한 컬럼들 자체를 index로 묶어서 지정하는 방법이다.
→ 일종의 임시 테이블처럼 형성이 된다. 모든 컬럼을 커버링하는 것이 아니면 의미가 퇴색된다 - 섣부른 컬럼 추가
