쿼리의 튜닝에 있어서 인덱스는 빠질수 없는 주제이다.
인덱스에 대한 설명을 지금 당장 !!!! 하고 싶지만,
그 이전에 MySQL이 동작하는 DB용 하드웨어에 대한 배경지식을 몇가지 설명하고자 한다.
이번 포스팅에서는 3가지 주제를 다룬다. 가볍게 한번 훑어보자.
- 데이터 저장 매체의 종류와 특성
- HDD와 SSD 비교
- 순차I/O와 랜덤I/O
======================================================
<저장매체의 종류와 특성>
- 내장디스크(Internel Disk) : PC의 본체에 장착된 디스크, 장착 가능 개수가 적고, 용량도 부족할 경우가 많다.
- DAS (Direct Attached Storage) : 내장디스크의 용량문제 해결을 위해 주로 사용, 독자적으로 사용할 수 없으며 본체에 연결해서만 사용할 수 있다. 반드시 하나의 본체에만 연결해야하며 동시 공유는 불가능하다. (연결방식 : SATA, SAS, SCSI 중 1)
- NAS (Network Attached Storage) : 여러 컴퓨터에서 동시 사용 가능, TCP/IP를 통해 연결, 직접 연결방식(DAS)에 비해 속도가 많이 느리다. (빈번한 데이터 읽고쓰기가 필요한 DB서버 용으로는 사용 X)
- SAN (Storage Area Network) : DAS로는 불가능한 아주 대용량 공간을 제공, 여러 컴퓨터에서 동시사용가능, 광케이블 연결로 속도도 상당히 빠르고 안정적, 고가의 구축비용이 듦. 주로 중요한 데이터 보관의 경우에만 사용.
고사양 및 성능 비교 (우측으로 갈수록 고사양)
내장디스크 < DAS < SAN
========================================================================
<하드 디스크 드라이브와 솔리드 스테이트 드라이브 (HDD vs SSD) >
컴퓨터 대부분의 주요 장치(CPU, RAM 등)는 대부분 디지털 방식이다.
하지만 디스크 드라이브(HDD)는 기계식(아날로그) 장치다.
고로, 디지털 방식으로 동작하는 주요 장치간의 데이터 소통은 굉장히 빠른데 디스크 드라이브만 그 페이스를 맞추지 못하는 상황이 발생하고, DB에서 디스크 장치는 항상 미운오리새끼(병목 지점 - 느려짐 현상의 주 원인 지점)가 된다.
이러한 기계식 디스크 드라이브를 대체하기위해 나온것이 요새 모두가 한번쯤 들어보았을 SSD(Solid State Drive)이다.
그럼 HDD와 SSD의 비교를 다음 표를 통해 알아보자
HDD | SSD | |
동작방식 | 아날로그(기계식) | 디지털 |
처리지연시간 비율 | 100 | 1 |
내부구조 | 플레터(원판) | 플래시 메모리 |
순차 I/O | SSD와 비슷하거나 약간 더 빠름 | - |
랜덤 I/O | - | HDD보다 훨씬 빠름 |
인터페이스 | SATA, SAS | |
가격 | - | HDD보다 비쌈 |
초당 처리 트랜잭션 수 (기대값) | 약 68 | 약 436 (약7배) |
========================================================================
<랜덤 I/O vs 순차 I/O>
일단 I/O란 입출력 (input & output)의 준말이 되겠다.
랜덤 I/O는 디스크 드라이브의 플래터(원판)를 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽어들이는 것을 의미하는데 실상 순차 I/O도 하는 작업은 동일하다. 그럼 대체 차이점이 뭘까.?
아래의 몇가지 사항을 살펴보면 그 차이점이 감이 올것이다.
FACT
- 디스크에 데이터를 읽고 쓰는데 걸리는 시간은 디스크 헤더를 움직여서 읽고 쓸 위치로 옮기는 단계에서 결정된다.
- 디스크의 성능은 디스크 헤더의 위치이동 없이 얼마나 많은 데이터를 한번에 기록하느냐에 의해 결정된다.
- 랜덤 I/O는 순차 I/O에 비해 여러번 쓰기 또는 읽기 요청을 한다. (즉, 작업 부하가 커진다.)
USAGE
- 쿼리 튜닝으로 랜덤 I/O를 순차 I/O로 바꾸어 실행할 방법은 많지 않다.
- 쿼리 튜닝은 랜덤 I/O 자체를 줄이는 것이 목적이다.
- 인덱스 레인지 스캔은 주로 랜덤 I/O를 사용
- 풀테이블 스캔은 주로 순차 I/O를 사용
- 위 두가지 이유로, 주로 Data Warehouse나 DB Table 통계작업 등에는 테이블이 큰 경우 인덱스 레인지 스캔보다 풀 테이블 스캔을 유도하는 경우도 있음.
========================================================================
자, 이렇게 기본적인 DB가 동작해야할 밑바탕이 되는 하드웨어의 종류와 그것들(저장매체=하드웨어)이 임무를 수행하는데 직면한 과제가 무엇인지 알았다.
이것이 중요한 이유는 DB가 그것들에게 원하는 작업을 요청할 것이고 그것들이 결국에 DB의 요청에 따라 데이터를 읽고 쓰는 작업을 수행해 줄 것이기 때문이다.
즉, 우리는 DB를 사용하면서 저장매체의 동작방식에 따른 적절한 요청을 구별하여 해야한다는 것이다.
일단 아쉽지만, 까마득한 일요일밤... 필자는 포스팅을 쓰면서 졸리다.. 안그래도 잠도 많은데... ㅎㅎ
책은 다 읽었지만, 다음 포스팅에서 본격적인 인덱스를 정리해보고자 한다. 기대해 주시길... ㅎㅎ 개봉박두!!
덧글
SSD도 느리다라는 시대가 바로 와버렸어요.. 문제는 가격과 휘발성이고 가격적인 부분에서 타협하는 구조로
SAN 스토리지쪽에서는 이미 SSD+HDD 구조는 수년전부터 보편화가 되었죠 (그래도 충분히 억억 하긴 합니다만)
논외로 SAN 스토리지의 경우 SSD+HDD의 비율이 문제인데 대략 20TB 정도면 오천이상... 거기에 SAN은 스위치가 정말 비싸죠.
24포트면 최소 천만원 이상에 서버용 인터페이스 카드가 최소 백만원 이상...
요즘은 대안으로 DAS에 SSD와 HDD를 묶어셔(퓨전I/O라던가.) RAID 구성하고... 그런 서버들을 가상SAN을 구성해서 볼륨을 만들기도 합니다.
복잡한 솔류션 필요없이 ESX같은 경우는 알아서 구성을 해주기도 하구요
물론 라이센스도 사야하지만요... TCP/IP 기반의 스토리지가 상대적으로 느리다고는 하지만 10Gbps가 보급되면서 SAN은 8Gbps에 비해서 속도에서는
이제 뒤쳐지지 않습니다. 동시성을 처리하는데는 아직 약하지만 인덱스 같이 작은 파일이 많은 구조에서는 오히려 더 유리하기도 하구요
(미들레인지급정도 까지만....입니다. 하이엔드급 장비는 논외)
정말 인덱스가 DB 성능게 크리티컬 하면 가속기라던가 캐쉬용 시스템을 따로 구성하기도 하죠.
논점 이탈 댓글이었습니다....
저는 전혀 접하지 못할 서버의 저장 매체 세팅의 세계...
그치만 잘 설명해주셔서 특별히 못알아 듣는 것은 없는거 같아요 ㅎㅎ
논점 이탈 댓글 이라지만 정말 ,,, 유익한 내용이었습니다 ㅎㅎ 감사합니다 !!!