■서론
ㅎㅇ 여기 애들한테
실질적으로 도움이 될만한게 뭐가 있을까
생각해봤는데 하나라도 자세히
올려주면 좋다고 생각해서씀
※mssql기준으로 설명함 아마용어만 다를듯※
■개요
RDBMS에서 데이터를 읽는 3가지 연산중 scan에
원리에 대해서 설명을 해볼꺼임
RDBMS는 scan, seek, lookup 이3가지 연산과 힙, 클러스터드인덱스, 논클러스터드 인덱스 내에서 여러 조합을 통해
데이터를 엑세스하는 패턴을 가지고 있어
이는 그것을 이해하기 위한 기반지식이 될것이고
더 나아가 실무를 하면서 비즈니스 로직이
테이블에 대해 적합한 연산을 하는지 자가진단
할 수 있기를 바래
■본문
일단 스캔 그자체를 설명하자면 어떠한 범위에 대해
쭉이어서 읽어나가는걸 스캔이라고 해
이러한 방식을 지원할 수 있는 이유는
테이블 또는 인덱스에 대한 페이지 할당 정보를 저장하는
맵이 내부에 있는것 과 인덱스의 구조의 경우
동일레벨의 노드간 링크드 리스트로 연결되어 있으며
인덱스키의 정렬 순으로 페이지가 배치되기 때문이야
눈치가 좋은 친구는 여기서
위에 설명한 두가지로 스캔방식이
나뉨을 알 수 있었을 꺼야
스캔은 두가지 방식을 지원하는데
하나는 아까 설명한 페이지 할당맵 을 쭉 읽어나가는 것이고
두번째는 인덱스의 리프노드를 정렬순으로 쭉 읽어나가는 거야
이러한 두가지 방식에는 각자 장단점이 있는데
★페이지 할당 맵 scan의경우
□장점
- 페이지 할당맵은 페이지에 저장된 데이터가 물리적으로
연속되는 경향(100%보장 x)이 있기 때문에 이를 통해
미리 읽기를 위해 필요한 물리적 읽기량이 대폭 감소해
- 따라서 위 장점에 기반하여 인덱스의 페이지가 조각화(물리적 페이지 순서와 논리적 페이지 순서 불일치)된
정도에 따라서 페이지 할당맵 scan이 유리해
(페이지 조각화 정도에따라 10배차이 날 수 있다고함)
□단점
- 페이지를 할당한 순서대로 스캔할수 밖에 없기 때문에
결과셋을 원하는 바로 정렬할 수 없어
- NoLock이나 Tablock힌트가 지정된경우에만 사용할 수 있기 때문에 부정확한 결과여도 상관없거나 스캔도중 데이터가 변경되지 않게 하여 정호가한 결과를 보장할 수 있도록
할 수 있는경우에만 사용가능해
★인덱스 리프페이지 스캔의 경우
□장점
- 인덱스 키를 기반으로한 결과셋의 정렬순서를 보장할 수 있다.
□단점
- 페이지 할당맵 scan의 장점과 동일하다 물리적 읽기에서
페이지 조각화에 영향을 받음
- 논리적 읽기에서 1io손해봄 ㅋㅋ 인덱스 리프페이지 스캔은 지정된 범위까지 읽었는지 확인하기위해 범위끝에 바로 다음
페이지를 하나 읽음(벤더마다를수도 있을것 같은점이야)
■결론
scan의 동작원리에 대해서 설명해봤는데
결론을 지어보자면
페이지 조각화 정도에따라 데이터가 캐시되지 않았을때
유리한 scan연산이 다르지만 조각화가 거의 없는경우
성능이 비슷하고 데이터가 이미 캐시되었다면 조각화에
따른 두scan간 성능 차이가 발생하지 않기때문에
거의 대부분에 환경에서는 페이지 조각화 정도에 신경쓰면서
인덱스 리프노드 스캔만 고려하면 될것 같아.
■+ Scan 성능을 향상 시키는법
기본적으로 Scan연산은 연결된 페이지를 한 방향으로 쭉 읽기 때문에 나중에 설명할 seek이나 lookup연산 처럼 인덱스 트리
depth의 영향을 받지 않아 scan의 성능을 향상 시키는 방법
으로는
- 스키마 설계시 속성별 데이터 크기를 타이트 하게 설계하여
페이지당 저장되는 레코드 수를 늘리기
- 대용량 테이블의 경우 파티셔닝을 파티션마다 비슷한 행수를 가지도록 구현하고 이를 디스크별로 파티션을 할당한뒤
패러렐 연산으로 파티션마다 patial scan하게 만들기
- 더있을꺼같은데 생각안남
■비고
- dc official App
다음에 심심할때 Seek하고 Lookup도 들고올게용 - dc App
개추 감사합니다
정보) 씨유, GS 편의점 5천 상픔권 받자 1. 앱스토어에서 [ㅋㅐ시닥] 검색, 다운 2. 회원ㄱㅏ입 후 츄천인에 [HZNKU] 입력하면 5천 포인트 지급 3. 받은 캐시로 [쿠폰shop]에서 구매 ㄱㄱ
MySQL, PostgreSQL 인터넷에 나와있는 뭔 차이라는 거 봐도 사실 안와닿긴하는데 DBA가 봤을땐 어떤 차이가 있다고 생각함?? 내부 동작까지 알지 않는 이상 JPA 추상화로 쿼리 날리는 내 입장에선 잘모르겠음..
RDBMS의 아키텍처들은 거의다 동일하고
(postgre의 배큠제외)
기능도 ANSI표준에 의해 동일함
성능도 큰차이가 없는것으로 알고
요즘 돈이랑 확장성 편의성으로 가름하는듯
나도 아직 다 찍먹해본건아니라
참고자료 남길게
https://youtu.be/ocZid4g4UpY?si=XILBoSzekp6-Iljn
- dc App
Db 공부 주로 어떤 자료들로 하시나요?? 아무래도 책일까요? - dc App
저는 - 공식문서 - 책 - 특정 내용에 대한 블로그 - 실무 및 실습 으로 공부했습니다. - dc App
드루이드 롤업에 대해서 써줘 - dc App
nosql은 아직안다러봐서 몰???루 nosql맞나? - dc App
형 요새 db 성능 장난아닌걸로 알고있는데 아무것도 없이 db만 가지고 부하주면 보통 얼마까지 버팀? 토이 프로젝트로 db 테이블 넣는걸로는 감이 안잡힘
DB성능이라기보단 메모리나 디스크의성능이 올라와서 라고보는게 맞고rdbms 입출력의 기본단위인 페이지가1페이지당 8kb인데 어떠한 테이블에도인덱스가 없다치면 수십만 수백만행이있는 테이블 정도면 매번 풀스캔조회로물리적읽기(디스크읽기)일때 수십초논리적읽기(메모리읽기)일때 수초정도 걸리지 않을까그런상태에서 배치가 좀많으며cpu나 메모리 압력으로 hang상태걸리는거지 - dc App
페이지 얘기는 괜히 했네 여튼 아무것도 없으면 수십 수백만 행 수준에서 배치가 좀많으면 매번 풀스캔해서 cpu/메모리 압력으로 db가 먹통될꺼 같아 - dc App
고마워 형 역시 토이프로젝트로 깔짝거리는걸로는 어떤 문제도 안생기겠구나 ㄱㅅㄱㅅ