티스토리 뷰
데이터베이스
데이터베이스 스키마 종류
- 내부 스키마 : 사용자 측면의 데이터베이스 전체 구조
- 개념 스키마 : 데이터베이스 전체구조
- 외부 스키마 : 물리적 저장 측면에서 구조
관계형 데이터 베이스 VS NoSQL
- 릴레이션(개념적 모델) = 테이블(실제 구현 개체)
- NoSQL은 대용량 데이터 조회시 관계형보다 빠름, 데이터 확장과 대용량 데이터 조회가 빈번히 일어날 때 사용
+) 그렇다면 관계형 DB는 NoSQL에 비해 뭐가좋을까? → 데이터 쿼리와 트랜잭션 지원이 필요한 경우, DB끼리 join을 많이해야하는경우(복잡한 쿼리 사용할때)
- +) 수직확장과 수평확장은 뭘까?
- 정의: 수직 확장은 하나의 서버의 성능을 향상시키는 것을 의미합니다. 이는 일반적으로 더 강력한 CPU, 더 많은 RAM, 더 큰 저장 용량과 같이 더 나은 하드웨어로 기존 서버를 업그레이드하는 것을 포함합니다.
- 장점:
- 관리가 쉽습니다. 하드웨어를 업그레이드하는 것이 전부이기 때문에, 추가적인 서버 관리나 네트워크 구성이 필요하지 않습니다.
- 데이터베이스 트랜잭션과 같은 복잡한 작업들이 더 효율적으로 처리됩니다. 모든 데이터가 하나의 물리적 위치에 있기 때문에 데이터 일관성을 유지하기가 더 쉽습니다.
- 단점:
- 비용이 많이 들 수 있습니다. 고성능의 하드웨어는 일반적으로 더 비쌉니다.
- 확장성에 한계가 있습니다. 하드웨어의 성능은 물리적으로 한계가 있으며, 어느 시점에서 더 이상의 성능 향상이 불가능할 수 있습니다.
- 정의: 수평 확장은 추가적인 서버를 네트워크에 추가함으로써 시스템의 처리 능력을 확장하는 것을 의미합니다. 이는 데이터베이스를 여러 서버에 분산시켜 작업 부하를 분산시키는 것을 포함합니다.
- 장점:
- 확장성이 높습니다. 필요에 따라 서버를 추가할 수 있으므로 더 많은 트래픽과 데이터를 처리할 수 있습니다.
- 비용 효율적입니다. 많은 중소규모의 서버를 사용하는 것은 고성능의 단일 서버를 사용하는 것보다 비용이 적게 들 수 있습니다.
- 단점:
- 관리가 더 복잡해질 수 있습니다. 여러 서버의 네트워크를 유지 관리해야 하며, 서버 간의 일관된 데이터 상태를 유지하는 것이 어려울 수 있습니다.
- 특정 종류의 작업(예: 조인 연산)이 더 복잡해질 수 있습니다. 데이터가 여러 서버에 분산되어 있기 때문에, 이러한 연산을 수행하는 데 추가적인 오버헤드가 발생할 수 있습니다.
- 수직 확장 (Vertical Scaling)
결론 :
- NoSQL의 장점: 대량의 데이터를 빠르게 수정해야 하거나, 스키마 변경이 빈번할 경우 NoSQL이 더 나은 성능을 보일 수 있습니다.
- SQL의 장점: 데이터의 무결성과 정확한 트랜잭션 관리가 중요한 경우, SQL이 더 나은 성능을 제공할 수 있습니다.
관계형 데이터 베이스
키는 유일성(하나의 키로 식별가능한지?)과 최소성(식별하는데 필요한 속성만으로 이루어졌는지?)을 만족해야한다.
- 슈퍼키 : 튜플을 식별할 수 있지만 최소성 만족 X
- 후보키 : 유일성과 필요한 속성만으로 구성되는 최소성
- 기본키 : 후보키 중 메인이 되는 키, NULL안됨
- 대체키 : 후보키중 기본 키 제외
- 외래키 : 다른 테이블의 기본키를 참조한 키
무결성
데이터베이스에 저장된 데이터와 실제 데이터가 일치하는 정확성, 데이터가 일정하게되는 일관성
- 개체 무결성 : 모든 테이블이 기본 키를 가져야함
- 도메인 무결성 : 도메인은 속성이 가질 수 있는 값의 집합, 테이블 속성 값은 도메인에 속해야함
- 참조 무결성 : 외래키의 값은 참조 테이블 기본키값과 동일하거나 NULL이어야함
인덱스
튜플의 검색 성능을 높이기 위해 속성값+튜플이 저장된 주소를 저장하는 것
장점 : 인덱스 테이블에 데이터가 정렬되어 있어 검색 속도가 빠름
단점 : 인덱스 테이블을 위한 추가 공간이 필요함, 정렬된 상태를 유지하기 위해 데이터를 추가/수정/삭제 속도가 느림
→ 데이터 양이 방대하며 변경보다 검색을 자주하는 경우에 생성
+) https://mangkyu.tistory.com/96
+) 인덱스의 정렬이란?
- 순서대로 저장: 인덱스는 데이터를 빠르게 검색할 수 있도록 키 값을 기준으로 정렬하여 저장합니다. 예를 들어, 데이터베이스의 특정 컬럼을 기준으로 인덱스를 생성하면, 이 인덱스는 해당 컬럼의 값에 따라 정렬됩니다.
- 데이터 구조: 인덱스는 보통 B-트리, B+트리와 같은 트리 기반의 데이터 구조를 사용합니다. 이러한 구조는 데이터를 정렬된 상태로 유지하면서도 효율적인 검색을 가능하게 합니다.
B+- 트리 인덱스
트랜잭션
데이터베이스의 상태를 바꾸기 위해 수행하는 작업의 단위/연산
원자성때문에 트랜잭션은 완전히 반영되거나 아예 실행되지 않아야한다. 이를 위한 명령어(TCL)
- COMMIT
- ROLLBACK
- SAVEPOINT
트랜잭션 격리
동시성이 높아지면 여러 트랜잭션이 동시에 처리되고 일관성에 문제가 발생할 확률도 높아진다. 그러나 고립성을 높이면 효율이 낮아진다.
락
트랜잭션이 처리되는 순서를 보장하기 위한 방법
- 공유락 : 읽기 락(read lock), 읽는 연산이라 데이터 일관성에 영향을 주지 않아 여러 공유락이 동시 접근할 수도 있음
- 베타락 : 쓰기 락(write lock), 쓰기라서 다른 락이 접근 불가능
트랜잭션도 교착상태(dead lock)에 빠질 수 있음 이를 해결하려면
- 예방 : 트랜잭션 처리 시작 전 필요한 데이터에 대해 미리 락을 얻음
- 회피 : 트랜잭션이 들어온 순서에 따라 교착 상태 회피
추가로 알아볼 것
관계형 데이터 베이스
- 각 속성들이 1:1 관계 -> 각 속성들? 1:1? 속성이란뭐죠? 1:1이어야하나요? 데이터를 하나의 컬럼에 a,b로 적으면 1:1이 아닌건가용?
- SQL과 NoSQL은 각각 언제쓸까요? -> NoSQL은 일관성이 정말 떨어질까요?
- 수평 확장과 수직 확장의 차이?
- 내부 스키마라는게 정확히 뭐지? 외부 스키마의 구체적 예시?
- 인덱스 데이터 변경시 불리한 이유?
- B+-트리 설명
- ROLLBACK이 불가능한 상황?
- 정규형 다시 공부하시죠!
- 외부조인할때 기준점 테이블이 명령어기준에서 어디로오는지?
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- 데이터잘림
- 모의서버
- redisTemplate
- 시간어떻게
- redis
- 소숫점잘림
- redis-py
- 구글클라우드스토리지
- 지도데이터
- 알고있
- 이미지검색
- PC시간어떻게
- visionAPI
- 네이버이미지검색
- jupyterlab
- crudrepository
- 구글
- mockserver
- 빈해쉬맵
- ChatGPT
- 조회수기능개발
- 스마트렌즈
- 항해커톤
- 실시간클록
- 주피터랩
- 실시간클락
- 항해해커톤
- 조회수기능
- 해커톤
- 목서버
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
글 보관함