모든 기술스택의 사용은 탄탄한 기본기 에서부터 시작된다고 생각한다. 기초 지식과 함께 모르는 내용이 있다면 꾸준히 업데이트 하고 역량을 키워나가자.
데이터베이스
DBMS
DBMS (Database Management System) 란 데이터베이스 관리 시스템으로 여러 사용자가 데이터베이스로 접근하고 사용할 수 있도록 해주는 소프트웨어 이다.
데이터베이스의 성능 이슈는 디스크 I/O를 어떻게 줄이냐에 시작한다. 그렇기에 쿼리 튜닝 등을 하며 최적화를 하게 되고 디스크 I/O를 줄일 수 있다.
DB를 사용하는 이유
데이터베이스를 사용하기 전에는 파일 시스템을 사용하여 데이터를 관리했지만 데이터의 중복, 검색 등의 문제를 해결하기 위해서 사용되고 있다. 데이터를 통합해 관리하는 데이터베이스는 중복성을 최소화 할 수 있기에 파일 시스템의 단점을 보안해준다.
OS 마다 파일 시스템은 다를 수 있고 OS에 종속되는 파일 시스템은 이후에 프로그램 확장을 할때 제한되는 부분이 될 수 있다.
Key
키 (key)
여러 가지 정의가 인터넷에 적혀 있지만 통합적으로
검색, 정렬 시 튜플을 구분하는 기준이 되는 속성 이 가장 맞는 말 같다.
후보키 (Candidate Key)
Tuple 을 유일하게 식별하기 위해 사용하는 속성들의 부분 집합. (기본키로 사용 할 수 있는 속성들)
2가지 조건을 만족해야 한다.
유일성 : Key로 하나의 Tuple 을 유일하게 식별할 수 있음
최소성 : 꼭 필요한 속성으로만 구성
기본키 (Primary Key)
후보키중 선택한 Main Key
특징:
Null 값을 가질 수 없음
동일한 값이 중복될 수 없음
대채키 (Alternate Key)
후보키중 기본키를 제외한 나머지 키 = 보조키
슈퍼키 (Super Key)
고유하게 식별하는 모든 후보키를 조합하는 키
유일성은 만족할 수 있지만, 최소성은 만족하지 못한다.
외래키 (Foreign Key)
다른 릴레이션 (테이블) 의 기본키를 참조하는 속성의 집합
테이블간의 연결을 유지하고 중복을 방지한다.
참고할 수 있는 링크
조인 (JOIN)
조인 (JOIN)
두개 이상의 테이블이나 데이터베이스를 연결하여 데이터를 검색하는 방법
트랜잭션 (Transaction)
트랜잭션
데이터베이스의 상태를 변환시키기 위해 수행하는 작업 단위
상태를 변환시킨다는 것 -> SQL 질의어를 통해 DB에 접근하는 것 (SELECT, INSERT, DELETE, UPDATE)
논리적인 작업의 쿼리 개수와 관계없이 논리적인 작업 셋 자체가 100% 적용되거나 아무것도 적용되지 않아야 함을 보장한다.
트랜잭션 특징 (ACID)
-
원자성(Atomicity)
트랜잭션이 DB에 모두 반영되거나, 혹은 전혀 반영되지 않아야 된다. -
일관성(Consistency)
트랜잭션의 작업 처리 결과는 항상 일관성 있어야 한다. -
독립성(Isolation)
둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다. -
지속성(Durability)
트랜잭션이 성공적으로 완료되었으면, 결과는 영구적으로 반영되어야 한다.
참고할 수 있는 링크
트랜잭션 매커니즘 : 트랜잭션이 일어날때 어떤식으로 업데이트가 되고 롤백이 되는지 매우 잘 설명이 되어있다.
트랜잭션 특성 : 트랜잭션의 특징 (ACID) 에 관한 설명이 잘 되어 있다.
인덱스
인덱스 (INDEX)
데이터베이스의 검색 속도를 향상 시키는 방법, 추가적인 쓰기와 저장 공간을 사용한다.
장점으로는 검색 속도 향상이 있지만 데이터를 추가, 삭제, 수정하는 경우 인덱스도 변경하고 정렬해야함으로 성능을 저하 시킨다.
Cluster 인덱스
인덱스로 지정한 컬럼을 기준으로 물리적으로 정렬하는 인덱스이다
한 테이블당 1개 (PK 처럼 적용된다)
범위 탐색에 굉장히 유리하고 검색속도가 빠른 반면, 입력, 수정은 느리다.
Non-Cluster 인덱스
데이터 자체는 정렬이 되지않고 페이지에 실제 데이터가 위치한 주소를 가리킨다.
한 테이블에 여러개가 생성될수있다.
검색 속도는 Cluster 에 비해 느리지만, 입력 수정 삭제가 빠르다.
멀티 인덱스 (Composite Index)
두개 이상의 필드를 조합하여 생성한 인덱스
참고할 수 있는 링크
인덱스 정의 및 알고리즘 : 인덱스의 정의 뿐만 아니라 Full Table Scana, B-Tree 알고리즘 원리도 설명이 되어있다.
인덱스 추가 설명 : 동일하게 인덱스를 설명 했지만 더 깔끔했다.
그래도 부족하다면 마지막 설명 : 이것까지 보면 인덱스는 정말 다 이해 했다고 생각한다.
RDBMS vs NoSQL
RDBMS vs NoSQL
RDBMS(관계형 DB):
1. 정해진 스키마에 따라 데이터를 테이블에 저장하는 데이터베이스
2. 데이터 구조를 보장 할 수 있다.
3. 수직적 확장이 가능하다 (서버의 성능을 향상시키는것 ex. CPU 업그레이드)
명확한 스키마가 사용자와 데이터에게 중요한 경우 적절하다.
관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션의 경우
NoSQL:
1. 스키마가 없거나 느슨한 스키마로 데이터 간의 자유로운 형태로 데이터를 저장하는 데이터베이스
2. 유연하기 때문에 언제든지 데이터를 조정하고 새로운 필드를 추가할 수 있다 (MongoDB 같은 경우 JSON 과 유사한 문서를 사용하여 스키마 없는 데이터를 저장한다)
3. 수평적 확장으로 트래픽 분산 및 대용량 처리가 가능하다 (ex. 더 많은 서버 추가)
정확한 데이터 구조를 알 수 없거나, 변경/ 확장될 수 있는 경우 적절하다.
데이터베이스를 수평적으로 확장해야하는 경우(막대한 양의 데이터를 다루는 경우)
참고할 수 있는 링크
RDBMS vs NoSQL 영어로 되어 있는 설명이지만 내가 봤던거중 가장 잘 설명이 되어 있다.
Lock
Lock
트랜잭션들이 동시에 수해될때 일관성을 해치지 않도록 데이터 접근을 제어하는 DBMS의 기능
동시성 제어?
Lock: Optimisstic Lock (낙관적 장금)
Pessimistic Lock (비관적 장금)
낙관적 장금:
동시 업데이트가 거의 없을 경우
데이터 갱신 시 충돌이 발생하지 않을 것으로 가정하여 락을 걸지 않는 방식 -> 락이 아닌 버전 관리 기능을 통해서 트랜잭션 격리성 관리
커밋 전까지는 충돌을 알 수 없다
비관적 장금:
동시 업데이트가 빈번한 경우
외부 시스템과 연동한 경우
공유락(Shared lock): 사용중인 데이터를 다른 트랜잭션이 읽기 허용, 쓰기 비허용
베타락(Exclusive Lock): 사용중인 데이터를 다른 트랜잭션이 읽기, 쓰기 비허용
데이터 수정 즉시 트랜잭션 충돌을 감지할 수 있다
둘의 사용을 판단하는 기준은 읽기와 수정 비율이 어디에 가까운지 보고 판단해야 한다. 수정의 비율이 높다면 Pessimistic 을 사용하고 읽기의 비중이 높다면 Optimistic 을 사용한다.
참고할 수 있는 링크
Lock 정의, 그리고 DeadLock 해결방안 : 마음에 들었던 강의이다. Lock의 기본 매커니즘을 더 쉽게 이해할 수 있었다.
Lock 추가설명 : 여러 종류의 Lock에 관한 추가 설명이 되어있다.
추가적인 학습 필요
클러스터링
DB 클러스터링은 DB 스토리지는 공유하고 동일한 DB 서버를 다중화 하는 방식이다.
레플리케이션
DB 서버와 DB 스토리지를 다중화하는 방식이다.
조회작업은 Slave 에서, INSERT, DELETE, UPDATE 작업은 Master 에서 수행하며 트래픽 분산
Slave 로 데이터를 옮길때 비동기 방식으로 동작하기 때문에 일관성 있는 데이터를 얻지 못할 수 도 있다.
수직 파티셔닝
큰 Table 인덱스를 관리하기 쉬운 단위로 분리하는 방식이다.
예) 사람이라는 테이블이 너무 커지게 되면 사람을 북유럽인, 아시아인, 서유럽인 이렇게 테이블로 분리 할 수 있다.
장점:
1. Insert 시 분리된 파티션으로 분산시켜 값을 줄인다
2. 읽기/쓰기 향상
3. 데이터 전체 검색시 필요한 부분만 탐색해서 성증 증가
단점:
1. 테이블간 조인 비용 증가
수평 파티셔닝 (샤딩)
같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방식
샤딩은 복잡도가 매우 높아지므로 다른 방식을 우선적으로 고려해야 한다.
쿼리 성능 최적화
같은 테이블에 여러 데이터를 insert 할 경우 insert 쿼리가 여러번 나가는것을 방지해서 배치 insert 를 사용해 최적화 할 수 있다.
MySQL 의 경우 Identity 전략을 Table 전략을 이용해 사용할 수 도있다.
정규화
What is Normalization?
정규화 설명 블로그
Redis
Elastic Search
Kafka
자료 참고
