🚩관계형 데이터베이스
RDBMS는 행과 열을 가지는 표 형식 데이터를 저장하는 형태의 데이터베이스를 가리키며 SQL이라는 언어를 써서 조작합니다. MySQL, PostgreSQL, 오라클, SQL server, MSSQL 등이 있습니다.
✒ MySQL
MySQL은 대부분의 운영체제와 호횐되며 현재 가장 많이 사용하는 DB입니다. C, C++로 만들어 졌으며 인덱스 압축기술, B-트리 기반의 인덱스, 스레드 기반의 메모리 할당 시스템, 빠른 조인 최대 64개 인덱스를 제공합니다.
- 대용량 DB를 설계하기 위해서 설계되어 있습니다.
- 커밋, 이중 암호, 지원보안 등의 기능을 제공합니다.
- MySQL Storage 엔진
- 모듈식 아키텍처로 쉽게 스토리지 엔진 교환 가능
- 스토리지 엔진 위에 커넥터 API 및 서비스 계층을 통해 MySQL DB와 쉽게 상호 작용
✒ PostgreSQL
MySQL 다음으로 개발자들이 선호하는 DB 기술입니다.
- 디스크 조각이 차지하는 영역 회수 장치 => VACUUM
- 최대 테이블 크기 32TB, SQL 또는 JSON을 이용해서 데이터에 접근 가능
- 지정 시간에 복구하는 기능, 로깅, 접그 제어, 중첩된 트랜젝션, 백업 가능
🚩NoSQL 데이터베이스
NoSQL이라는 슬로건에서 생겨난 DB입니다. SQL을 사용하지 않는 DB를 말하며, 대표적으로 MongoDB와 redis가 있습니다.
✒ MongoDB
MongoDB는 JSON을 통해 데이터에 접근할 수 있고, Binary JSON 형태로 데이터가 저장되며 와이어드 타이거 엔진이 기본 스토리지 엔진으로 장착된 키-값 데이터 모델에서 확장된 도큐먼트 기반의 DB입니다.
- 확장성이 좋아, 빅데이터 저장할 때 사용, 고가용성과 샤딩 레플리카셋을 지원
- 스키마를 정하지 않고 데이터를 삽입, 따라서 다양한 도엠인의 DB를 기반으로 분석 or 로깅 구현
- 도큐먼트를 생성시, 다른 컬렉션에서 중복된 값을 제거하는 유니크 한 값인 ObjectID 생성
✒ redis
redis는 인메모리 DB이자 키-값 데이터 모델 기반의 DB입니다.
- 기본적인 데이터 타입은 String 이며, 최대 512MB까지 저장할 수 있습니다.
- Hash, Set 지원
- 사용
- pub/sub 기능을 통해 채팅 시스템
- 다른 DB앞단에 둬 사용하는 케싱계층
- 키-값 으로 관리되는 세션 정보 관리
- sorted set 자료구조를 이용한 실시간 순위표 서비스
🚩인덱스의 필요성
인덱스는 데이터를 빠르게 찾을 수 있는 하나의 장치입니다.
- 인덱스 설정시 테이블 안에 내가 찾고자 하는 데이터를 빠르게 찾음
🚩B-트리
인덱스는 보통 B-트리라는 자료구조로 되어있습니다. 이는 루트 노드, 리프 노드, 그리고 루트 노드와 리프 노드 사이에 있는 브랜치 노드로 구성됩니다.
- 찾고자 하는 데이터가 있을 법한 곳으로 노드로 타고가는 것
- 14를 컴퓨터 관점으로 찾아보자
✒ 인덱스가 효율적인 이유와 대수확장성
인덱스가 효율적인 이유는 효육적인 단계를 거쳐 모든 요소에 접근할 수 있는 균형 잡힌 트리 구조와 트리 깊이의 대수 확장성 때문입니다.
- 대수확장성
- 트리 깊이가 리프 노드 수에 비해 매우 느리게 성장하는 것
🚩인덱스 만드는 방법
인덱스를 만드는 방법은 DB마다 다릅니다.
✒ MySQL
클러스터형 인덱스와 세컨더리 인덱스가 있습니다.
- 클러스터형 인덱스
- 테이블당 하나
- PK옵션으로 기본키로 만들려면 클러스터형 인덱스 생성
- PK를 기본키르 만들지 않고 +unique not null 하면 클러스터형 인덱스로 만듬
- create index ...
- 세컨더리 인덱스를 만들 수 있음
- 세컨더리 인덱스
- 보조 인덱스
- 여러 개의 필드 값을 기반으로 쿼리를 많이 보낼 때 생성해야 하는 인덱스
✒ MongoDB
도큐먼트를 만들면 자동으로 ObjectID가 형성되며, 해당 키가 기본키로 설정됩니다. 그리고 세컨더리키도 부가적으로 설정해서 기본키와 세컨더리키를 같이 쓰는 복합 인덱스를 설정할 수 있습니다.
🚩인덱스 최적화 기법
인덱스 최적화 기법은 DB마다 다르지만 기본적인 골조는 같습니다.
✒ 1. 인덱스는 비용이다
인덱스 리스트 , 컬렉션 순으로 탐색하기 때문에 관련 읽기 비용이 들게 됩니다.
- 필드에 인덱스를 무작정 설정하는 것은 답이 아님
- 컬렉션에서 가져오는 양이 많을수록 인덱스를 사용하는 것은 비효율적
✒ 2. 항상 테스팅하라
서비스에서 사용하는 객체의 깊이, 테이블의 양 등이 다르기 때문에 테스팅을 해야합니다.
- explain()함수를 통해 인덱스를 만들고 쿼리를 보낸 이후에 테스팅하는 시간을 최소화
EXPLAIN
SELECT * FROM t1 JOIN t2 ON t1.c1 = t2.c1✒ 3. 복합 인덱스는 같음, 정렬, 다중 값, 카디널리티 순이다.
여러 필드를 기반으로 조회를 할 때 복합 인덱스를 생성하는데, 이 인덱스를 생성할 때는 순서에 맞게 생성해야 합니다. (같음 -> 정렬 -> 다중 값 -> 카디널리티)
- 카디널리티는 유니크한 값의 정도
- 같음을 비교하는 == or equal 쿼리가 있으면 가장 먼저 index로 설정
- 정렬에 쓰는 필드면 그 다음 인덱스로 설정
- 다중의 값을 출력해야 하는 쿼리에 쓰는 필드라면 나중에 인덱스를 설정
- 카디널리티가 높은 순을 기반으로 인덱스를 생성
참고
https://velog.io/@tastestar/Mysql-%EC%8A%A4%ED%86%A0%EB%A6%AC%EC%A7%80-%EC%97%94%EC%A7%84
.
https://velog.io/@ragnarok_code/PostgreSQL%EC%9D%B4%EB%9E%80
.
https://www.mongodb.com/
.
https://rastalion.me/redis-summary/
.
https://rebro.kr/169
