자칭 연봉이 얼마네 하는 현직 백엔드 개발자 80%가 인덱스가 뭔지도 몰라서 인덱스 안만들어놓고 서비스 런칭하고 막 느려지면 디도스 공격이 들어왔다는둥 고성능 서버로 업그레이드 해야 한다는둥 함. 이거 진짜 중요한건데 대학이나 학원에서 왜 똑바로 안가르쳐주는지 모르겠음. 암튼 코딩애플님 좋은 내용 올려주셔서 감사.
클러스터드 인덱스(body 자체가 정렬되어 있음) : 옛날 수사물 같은거보면 서류보관실에 가나다순 혹은 연도순으로 물리적 순서 맞춰서 사건기록 진열해놓은 것. 만약 자료가 새로 추가될 경우 중간에 맞는 위치를 찾아서 쏙 끼워넣음. 근데 순서대로 정렬되어 있어도 자료실이 너무 크면 눈알 빠질수 있으니 몇 미터 마다 ㄱ ㄴ ㄷ 이렇게 간판을 붙여놓을수 있는데 이게 클러스터드 인덱스. 논클러스터드 인덱스(body 와 별개로 색인 데이터가 존재) : 옛날 두꺼운 책 시작 부분에 보면 '색인(index)'이라는 섹션이 있는데 거기에 가나다 순으로 키워드들이 정렬되어 있고 각 키워드가 본문(body) 어느 페이지에 등장하는지 써져 있음. body의 물리적 배열을 순서대로 정렬하기 곤란한 경우 사용.
인덱스라는 것은 이분탐색을 이용하기 위해 db 를 정렬해놓는 것을 말한다. 정렬을 한 후 이분탐색을 통해 시간복잡도를 줄었다. 여기서 탐색과정을 줄이기 위해 binary tree ☞ b - tree ☞ b+tree 의 발전과정이 생겼다. 최근 db 들은 비플러스 트리를 사용하며 트리의 맨 하단에 데이터를 정렬하며 서로다른 노드로의 이동이 가능해 이전 트리들의 자료구조에서 힘들던 스캔이 가능해졌다. 틀린점 있으면 댓글주시면 감사하겠습니다.
중요한 로직이 빠진듯 합니다. 해당 설명은 결국 메모리에 올라간 인덱스 컬럼의 값을 찾는 과정이고 행단위를 찾기 위해선 결국 하드디스크에서 다시 찾아야 하는데 기본 값으로 찾는 것과 메모리에서 확인되서 찾는 과정이 어떻게 달라서 더욱 빠른지가 빠져있는데 해당 설명이 추가 첨부되면 더더욱 이해하기 좋은 강의가 되지 않을까 합니다. 항상 좋은 영상 만들어 주셔서 감사합니다
인덱스도 기본적으로 디스크에 저장됩니다. 사용되는 과정에서 인덱스의 목적에 맞게 최적화되어 메모리에 로드하고 사용하지만, DB데이터와 인덱스데이터 모두 디스크에서 읽는다고 보아도 영상의 내용이 최적화의 관점에서 크게 벗어나거나 이해하기 어려운 내용이 되는 건 아닙니다. Row수 많이 없는 DB만 다뤄보셨거나 경험이 없다면 그 메모리 로드만 크게 보일 가능성이 크죠
메모리냐 디스크냐는 완전히 별개의 layer에서 작동하는거라 주제를 굳이 섞을 이유가 없는것 같네요. 다만 DB상에서 어떤 명령이 수행되든 OS레벨과 DB엔진레벨에서 적절한 메모리캐싱이 이루어지기 때문에 아주 딥한 니즈가 있지 않는한 그런것까지 굳이 신경써야 하는지 모르겠습니다. 참고로 거대한 레코드수가 누적된 테이블에서 인덱싱 안된 컬럼을 검색하면 순수 메모리에서만 검색하더라도 속도가 절대 빠르지 않습니다.
index를 만능키로 생각하면 경우에 따라 위험할 수도 있습니다. 데이터가 많은데 모든 컬럼에 index를 걸어둔 채 insert, update, delete 가 자주 일어나는 상황이면 db 장비의 리소스를 잡아먹어서 예상치 못한 문제가 발생합니다. 서버 이전이나 db 롤백같은 작업이 필요할 때 테이블 하나가 너무 크면 할당된 작업 시간 내에는 답이 없는 경우도 종종 있습니다. 아무리 index가 잘 걸려있어도 데이터가 많아지면 select 도 느려질 수 있습니다. 모든 데이터가 균일한 검색 빈도를 가지는 것이 아니면.. 예를 들면 오래 된 데이터는 검색 요청이 잘 없다면 분리가 가능하죠. 테이블 하나로 설계할 것이 아니라 연관있는 항목끼리 잘 묶어서 여러 테이블로 분산할 수 있는지 고민해 볼 수 있습니다. 레코드가 정말 너무 많으면 테이블을 여러 개 쓰는 것도 추천합니다. app 에서 미리 계산하여 table을 찾은 뒤 검색하면 되므로 db 부하를 줄일 수 있습니다 시스템 환경에 따라 적절하게 db 설계를 하고, 타협선을 찾아 app 에서 부하를 나눠서 가져가는 것이 현명합니다.
실제 쓸 땐 where에 단 하나 칼럼만 넣는 게 아니고 and도 넣고 이것저것 할텐데 컴포지트 인덱스 같은 복수 컬럼 인덱스가 필요해지고, 그 땐 인덱스 순서 탓에 있어도 못 써먹기도 합니다. 계획 잘 세우고 해야지 쓸데없는 인덱스 만들면 insert update 느려지고 디비 용량도 크고 나중에 데이터 개수 늘면 인덱스 변경도 몇 시간짜리 작업이 되어서 바로잡으려고 해도 손쓸 수 없게 됩니다.
아뇨. 실제로 컬럼마다 인덱스를 만드는 것은 용량이나 데이터 관점에서뿐만 아니라, 실제 검색에서도 시간이 오래 걸려버리게 됩니다. 개개 컬럼별로 만들어진 인덱스로 해시조인이 되거나 더 빠른 나름대로의 인덱스 조인 실행계획이 생성된다고 해도, 하나의 복합인덱스에서 검색하는것만큼 빠르진 않습니다.
저도 초보라서 잘 모르지만 제가 이해한 내용대로 말씀드려볼게요. B+ 트리의 하위 노드는 정렬 되어있음 == 배열을 만드는 것 은 맞는 말이죠. 근데 배열을 만드는 방법이 b+트리 구조로 만든 것이라는 것 같아요. b+트리로 만들어져서 가지뻗어 나온 노드들 기준으로 가장 하단, 가장 왼쪽에 있는게 가장 작은 숫자이겠죠. 그걸 그 순서대로 읽으면 정렬된 배열이 나오는거겠구요.
