본문 바로가기

mongoDB

[MongoDB] DAS, NAS, SAN, HDD, SSD, 인덱스란?

반응형

저장매체의 종류와 특성

저장매체의 종류와 특성

내장디스크 (Internal Disk) 


PC 본체에 장착된 디스크,
장착 가능 개수가 적고, 용량도 부족한 경우가 많음
DAS (Direct Attached Storage)



스토리지의 한 종류로써 서버와 직접 연결되는 하드웨어,
서버와 하드웨어를 1:1로 연결,
"서버의 외장하드" 와 비슷
내장디스크의 용량 문제 해결을 위해 주로 사용, 
독자적으로 사용할 수 없으며 본체에 연결해서 사용
반드시 하나의 본체에만 연결해야하며 동시 공유는 불가

장점 : 확장이 용이하다. (계속 사서 붙이기) 
단점 : 계속 확장하다 보면 서버 효율 저하 
NAS (Network Attached Storage)

네트워크가 연결된 DAS,
여러 컴퓨터에서 동시 사용 가능,
TCP/IP를 통해 연결,

장점 :
- 많은 어플리케이션 사용 가능
- 다중 호스트 파일시스템 엑세스 제공
- 유지보수 쉬움
- 비용 상대적으로 저렴

단점 :
- 백업의 어려움
- 이미지 레벨의 백업 불가(파일 단위로 백업)
- SAN보다 상한선이 낮음
- 직접 연결방식(DAS)에 비해 속도가 많이 느림 
SAN (Storage Area Network) 
DAS로 불가능한 대용량 공간을 제공, 
블록 수준 (NAS는 파일 단위) 스토리지에 접속할 수 있도록 지원하는 특정 시스템 전용의 고속 네트워크,
여러 컴퓨터에서 동시 사용 가능,
광케이블 연결로 속도 상당히 빠르고 안정적, 
고가의 구축비용, 
주로 중요한 데이터 보관의 경우에만 사용,
스토리지 트래픽을 LAN과 분리해서 따로 네트워크를 구성,
따라서 LAN과 구별되므로 SAN을 활용한 앱의 가용성과 성능이 향상,
NAS와는 다르게 일반적으로 파이버 채널 연결을 이용 (NAS는 표준 이더넷 연결) 

장점 :
- 로우 디바이스 처리 가능
- NAS보다 성능이 빠름
- 대규모 백업과 복구 쉬움
- 데이터베이스 이중화 시 사용

단점 : 
- 가격이 비쌈
- 관리 및 유지보수가 복잡 
Storage


컴퓨터 프로세서가 접근할 수 있도록
데이터를 저장하는 목적을 가진 하드웨어

쉽게 하드 많이 들어간 외장하드
OS에 독립적
데이터는 전용 인터페이스로 전송

초대용량, 백업기능, 다수의 볼륨 생성/ 복제 / 삭제 등 관리, 가상 볼륨 생성, 장애 및 재해 대응, 자유로운 용량확장성

다양한 연결방식 제공 (DAS, NAS, SAN, iSCSI, FCoverIP 등등) 
단순 NAS로는 해결할 수 없는 기업의 엔터프라이즈급에서 요구하는 고급기능을 제공
Server


하드 많이 들어간 PC본체
데이터는 네트워크로 전송
다른 프로그램에게 서비스를 제공하는 목적을 가진 하드웨어 

 

 

 

HDD vs SSD

HDD vs SSD
  HDD (Hard Disk Drive)  SSD (Solid State Drive) 
동작방식 아날로그 (기계식) 디지털
처리지연시간 비율 100  1
내부구조 플레터 (원판)  플래시 메모리
순차 I/O SSD와 비슷하거나 약간 더 빠름 -
랜덤 I/O - HDD보다 훨-씬 빠름
인터페이스 SATA, SAS  
가격  SSD보다 쌈  HDD보다 비쌈
초당 처리 트랜잭션 수 (기대값)  약 68 약 436 (약 7배) 

 

 

 

랜덤 I/O vs 순차 I/O

 

공통점 :

랜덤, 순차 I/O 모두 디스크의 원반을 돌려서 디스크 헤드를 읽어야 할 데이터가 저장된 위치로 이동시킨다음 읽는 방식

 

차이점 : 

랜덤 I/O - 3개의 페이지를 디스크에 기록하기 위해 시스템 콜을 3번 요청 ( 디스크 헤드를 3번 움직임 )

순차 I/O - 3개의 페이지를 디스크에 기록하기 위해 시스템 콜을 1번 요청 ( 디스크 헤드를 1번 움직임) 

 

쿼리를 튜닝한다는 것은 랜덤 I/O를 순차 I/O로 바꾸는 것보다는 얼마나 랜덤 I/O의 회수를 줄이는지 즉, 처리에 꼭 필요한 데이터만 읽도록 쿼리를 개선하는 것이다. 

 

 

 

 

인덱스, Index 란? 

책의 마지막 쪽에 있는 '인덱스', '찾아보기' 와 비슷하다. 책의 '인덱스'에 적힌 페이지 번호는 해당 데이터의 주소에 비유할 수 있다. DBMS도 사람이 책의 인덱스를 보고 해당 페이지를 찾는 것처럼 데이터를 찾는다. 데이터와 저장된 위치를 키와 값의 쌍 (key-value pair)으로 관리한다.  

DBMS에서 인덱스는 데이터의 저장성능을 희생해서 상대적으로 데이터의 읽기 속도를 향상시키는 존재 -> 테이블에 인덱스 하나를 더 추가할지 말지는 데이터의 저장 속도를 얼마나 더 희생할 수 있는지, 읽기(조회) 속도를 얼마나 더 빠르게 만들어야 하는지 조율하면서 결정해야한다. 

 

많은 도큐먼트 (전체 컬렉션 도큐먼트의 15~20% 이상)를 읽어야 할 때에는 인덱스를 이용하지 않고 컬렉션 스캔 (풀 테이블 스캔) 으로 필요한 레코드를 가려내는 방식이 더 좋다고 한다. 

 

 

 

 

INDEX 다양한 기준으로 분류해보기 

INDEX
자료 정렬 여부 구분
SortedList

- 저장되는 값들을 항상 정렬된 상태로 유지하는 자료구조
- DBMS의 인덱스와 동일한 자료구조
- 단점 : 데이터를 저장할 때마다 값을 정렬해야 하므로 저장하는 과정이 (insert, update, delete) 복잡 + 느림 
- 장점 : 이미 정렬된 "인덱스" 덕분에 (find, select, 조회) 쿼리는 매우 빠르게 처리할 수 있다. 
ArrayList

- 값을 저장하는 순서대로 그대로 유지하는 자료구조 
- 데이터 파일과 동일한 자료구조



인덱스를 역할별로 구분
Primary Key (프라이머리 키) 

- 도큐먼트 (or 레코드) 를 대표하는 필드들의 값으로 만들어진 인덱스
- "식별자" 라고도 불림
- Null값  불허 /  중복 불허 
Secondary Key (보조 키)

- 프라이머리 키를 제외한 모든 인덱스들은 Secondary index로 분류됨 
데이터 저장 방식 (알고리즘) 별로 구분 (대표적인 두가지)
B-Tree 인덱스


- 시중의 RDBMS에서 대부분 사용하고 있는 알고리즘 (mongoDB)- mongoDB의 프라이머리 키는 클러스터링 인덱스가 아니므로 프라이머리 인덱스와 세컨더리 인덱스 간의 내부구조가 동일
- 최상단의 루트 노드, 중간 위치의 브랜치 노드, 최하단의 리프 노드로 구성되어 있음 
- 각 리프가 동일한 깊이에 위치, 균등한 응답 속도 보장 (하나의 컬렉션에서 모든 도큐먼트가 3~4개의 I/O이상으로 떨어져 있지 않음

B-tree 장점 

- B-tree는 깊이가 최대 4개 (헤더블록 1개, 브랜치 블록 2개, 리프 블록1개) 이므로 대규모 컬렉션에 대해 우수한 성능 제공

-> 일반적으로 문서를 찾는데 4개 이상의 I/O가 필요하지 않음

-> 실제로 헤더 블록은 거의 항상 메모리에 미리 로드되고 브랜치 블록들도 일반적으로 메모리에 로드되어 실제 디스크 읽기 수는 일반적으로 1-2개에 불과함 

- 빠르고 정확한 조회, 레인지 스캔 쿼리 지원 
Hash 인덱스


데이터 중복 허용여부로 구분
Unique Index
- 중복없는 유일무이한 데이터 -> 해당 인덱스로 검색한다는 것은 쿼리가 항상 1건의 레코드만 리턴한다는 의미 -> 최적화 
Non-Unique Index 


기능별로 분류 

전문 검색용 인덱스
공간 검색용 인덱스
클러스터형 여부 (MongoDB에서는 지원  X) 
클러스터형 인덱스, Clustered Index 

- 테이블당 한 개만 생성 가능
- 행 데이터를 인덱스로 지정한 열에 맞춰서 자동 정렬
- 영어 사전처럼 책의 내용 (데이터)가 순서대로 정렬되어 있어 인덱스 자체가 책의 내용과 같음
- 인덱스를 생성할 때 데이터 페이지 전체를 다시 정렬
- 대용량 데이터가 이미 입력된 상태라면 클러스터형 인덱스 생성은 심각한 시스템 부하를 줄 수도 있다
- 비클러스터형 인덱스보다 검색 속도는 빠르지만 입력/수정/삭제는 느림
- 클러스터 인덱스는 성능이 좋지만 테이블에 한 개만 생성할 수 있음

비클러스터형 인덱스, Nonclustered Index

- 테이블당 여러 개 생성 가능
=> 남용할 경우 오히려 시스템 성능이 저하될 수도 있음

- "인덱스 (=찾아보기)"가 끝 쪽에 있는 책과 같다. - 정렬 

- 비클러스터형 인덱스를 생성할 때는 데이터 페이지는 그대로 두고, 별도의 "인덱스" 페이지에서 구성한다 

 

 

 

 

 

MongoDB 명령어

MongoDB Commands
db db.version() mongoDB 버전 조회
  show databases db 조회
     
  use [dbName] 해당db 사용
     
Index db.[dbName].createIndex({ "field명" : 1 })
* 1 : sort 오름차순
인덱스 생성
인덱스 생성 시 options
  db.[dbName].createIndex({"fieldName":1, name: "idx_isDeleted"})  인덱스 이름 변경 (이 안되어서
삭제 후 다시 생성할 때 이름 option 넣어주기) 
  db.[dbName].getIndexes() 인덱스 불러오기
  db.[dbName].dropIndex({"field명" : 1}) 인덱스 삭제
     
index for a sub document  db.[dbName].createIndex({ "field명.sub doc's field명" : 1})  sub 도큐먼트 필드에 인덱스 생성
     
     

 

 

 

 

 


 

References: 

1. 대용량 데이터처리를 위한 Real MongoDB 책

2. https://mongyang.tistory.com/75

 

[SQL] 인덱스 (클러스터, 비클러스터) 개념

인덱스. 1. 개념 A. 간단한 비유로 일반적으로 책 뒤쪽에 위치하는 ‘찾아보기’를 들 수 있다. B. 일 예로, ‘홍길동전’에서 ‘율도국’이라는 단어를 찾는다고 가정해보자. 만일 이 책에 ‘찾

mongyang.tistory.com

3. https://rastalion.me/mongodb-index-1-architecture/

 

MongoDB Index #.1 Architecture - RastaLion's IT Blog

MongoDB Index #.1 - Architecture, MongoDB의 인덱스 구조, MongoDB의 인덱스 동작 방식, B-Tree 인덱스에 대한 이해, MongoDB의 인덱스 사용시 주의사항

rastalion.me

4. http://oniondev.egloos.com/9682288

 

[DB-MySQL 인덱스(INDEX) #1] 저장매체의 종류와특성, HDD vs SSD, 순차I/O vs 랜덤I/O

쿼리의 튜닝에 있어서 인덱스는 빠질수 없는 주제이다. 인덱스에 대한 설명을 지금 당장 !!!! 하고 싶지만, 그 이전에 MySQL이 동작하는 DB용 하드웨어에 대한 배경지식을 몇가지 설명하고자 한다.

oniondev.egloos.com

5. https://docs.mongodb.com/manual/reference/method/db.collection.createIndex/

 

db.collection.createIndex() — MongoDB Manual

Docs Home → MongoDB Manualdb.collection.createIndex(keys, options, commitQuorum)mongosh MethodThis is a mongosh method. This is not the documentation for Node.js or other programming language specific driver methods.In most cases, mongosh methods work th

docs.mongodb.com

6. https://wonyong-jang.github.io/database/2021/04/06/DB-MongoDB-Index.html

 

[DB] MongoDB Index 설계 전략 - SW Developer

Index는 왜 중요한가 인터넷에는 셀 수 없이 많은 정보들이 있다. 하지만, 우리가 구글에서 원하는 정보를 찾을 때는 어떤가? 검색어 몇 번 입력하면 꽤 높은 확률로 필요한 정보를 빠르게 얻을 수

wonyong-jang.github.io

 

반응형