1. 클러스터링 인덱스는 innoDB로 pk 있는 테이블을 생성하면 자동으로 생성되는거지?
2. 데이터 파일 내부에 박혀 있는거 맞지? 사용자가 직접 생성한 세컨더리 인덱스의 리프 노드가 프라이머리 키를 가지고 있고 그걸로 데이터파일의 클러스터링 인덱스를 타고 실제 레코드값을 가져오는거고?
3. 클러스터링 인덱스 단점이 쓰기 작업의 성능이 상대적으로 저하된다는데 그렇다면 쓰기 비율이 정말 높은 테이블일 경우 클러스터링 인덱스가 있는게 오히려 마이너스임?
- dc official App
책 다시봐야할거같은데
다시 책피러간다 - dc App
답은 못하고 책보러가야할거같은데 ㅇㅈㄹ - dc App
뭐랄까 좀 애매한데 그냥 row를 저장하기 위한 데이터 파일이 b-tree 형식으로 저장되는 거임. 말한대로 클러스터링 성질때문에 쓰기 부하가 매우 심하거나 초대용량인 경우엔 적합하지 않음. 보통 쓰기 부하가 매우 많은거면 로그성 데이터일 확률이 높아서 ELK 같은거 쓸수도 있고, 로그성이 아니라 사용자 데이터라면 디스코드가 쓰는 Scylladb같은 대안도 있고 Spark도 있고..
음 데이터파일이 그냥 b-tree형식으로 저장되는거라고 이해하면 딱이겟네 ㄱㅅㄱㅅ - dc App
1. mssql은 그런데 그것도 아마그럴듯 2. 데이터파일에 박힌다기보다는 실제로 인덱스 키를 기준으로 밸런스트리형태로 정렬됨 3.클러스터링 인덱스는 insert, update에 성능 영향이 없는걸로암 논클러스터드 인덱스가 리프페이지에 원본데이터를 참조하는 포인터로 밸런스 트리를 생성하기때문에 논클러스터드 인덱스 개수만큼 update, insert비용이 늘어나나 거의99%이상의 서비스는 select비율이 압도적으로 높기때문에 인덱스로인한 삽입수정로직의 성능저하를 감안하지는 않음 - dc App
잘보았읍니당 ㄱㅅㄱㅅ - dc App
인덱스에 관한 성능 고민이 있다면 우선적으로 가볍게 선택도와 카디널리티 더 깊이는 실행계획 생성, 인덱스 통계, 카디널리티 예측에 대해 공부해보셈 - dc App
헉ㅋㅋ선택도 뭔가 안중요해보여서 건너뛰엇는데 ㅋㅋ다시봐야긋네 인덱스 다보고 옵티, 실행계획 볼듯 ㄱㅅㄱㅅ - dc App
차피 선택도와 카디널리티는는 인덱스의 아키텍처를 이해한다면 자연스럽게 연상되는 개념이긴함 아키텍처를 모르는데 어느정도 잘짜고 싶다일때만 겉핥기로 선택도랑 카디널리티만 아는거 ㅇㅇ - dc App