□ Database :
여러사람에 의해 공유될 목적으로 구조화된 데이터 모음
dbms 의해 관리된다.
crud 사용하는 일련 소프트웨어 도구 서비스 제공한다.
■ DBMS : 사용자와 db 사이에서 사용자의 요구 따라 정보 생성해주고, 생성된 db관리해주는 SW
□ 역할 : 안전성 신뢰성 유지
데이터 보호, 유지. 무결성, 일관성, 보안, 백업 및 복구 등 보장
□ dbms 종류 : 계층형, 관계형, 객체지향, nosql 등
(주로 관계-nosql 비교됨)
sql? sql이 뭔데여?
□ SQL : structured query language
데이터 저장, 검색, 수정, 삭제에 사용되는 표준 언어
=> 관계형 dbms에 저장된 데이터 관리 위해 설계된 언어
명령어와 함수로 이루어짐, 간단하고 직관적 ==> 강력
ex) select, insert, delete, update
강력해? po강력한wer한 sql 사용하면 dbms에는 어떤게 좋은데 ?
먼저
□ RDBMS : 테이블 형태로 저장 & sql 사용
데이터를 저장하는 테이블은 열과 행으로 구성.
외래키 사용해 테이블간 관계 설정
외래키 사용해 테이블 간 join 가능!
[테이블 장점]
데이터를 구조화, 열과 행으로 저장함으로써 데이터 체계적 관리 가능
각 열은 데이터의 특정 속성을 나타내고, 각 행은 개별 데이터를 나타내므로 데이터를 쉽게 찾고 분석 가능
[조인의 장점]
여러 테이블에 저장된 데이터를 하나의 결과로 결합하여 효율적으로 조회 가능
데이터의 중복을 최소화, 데이터 일관성을 유지, 복잡한 질의를 작성 가능 => 데이터베이스의 유연성과 성능 향상
rdbms 는 뭐뭐 있는데?
□ sql 사용해 데이터 관리
장점:
표준화된 언어인 sql 사용 => 데이터 분석 & 검색 용이
- 데이터 분류, 정렬, 탐색 속도 비교적 fast
- 대규모 데이터 처리에도 뛰어난 성능!
- 동시에 여러 사용자 사용해도 데이터 일관성, 무결성 유지에 용이!(안정적)
∴ RDBMS는 일반적으로 가장 많이 사용되는 dbms 中 1
그럼 그렇게 좋으면 얘만 쓰면 되잖아여?
단점 :
한 번 생성한 스키마 변경 어려움(스키마: 테이블 정의... 추가내용)
- 스키마 변경되면 모든 데이터 일관되게 업데이트 해야함.
- 대규모 db 경우 시간과 복잡성에 대한 비용 매우 클 수도
- 테이블간 관계, 시스템 커지면 join 많은 복잡한 쿼리 사용해야...
수평적 확장의 어려움(=서버 성능 향상 / 부하의 분산 어려움)
- 관계형 db는 트랜잭션을 사용 (for ACID 특성을 유지하기 위해서)
- 수평적 확장 : db 분산시켜 처리 능력 확장 시키는 방식 (but 데이터 분산시키면 트랜잭션 일관성 유지 어려움)
여러 대 서버에 데이터 분산해서 구현
여러 대의 서버에 동일한 데이터의 일부가 저장되어 있을 때,
서버 간 데이터의 일관성을 유지하면서 동시에 각각의 서버에 트랜잭션을 수행하는 것은 매우 어려우므로
보통 RDBMS는 수직적 확장을 사용
(수직적 확장: CPU, RAM등을 증가시켜 데이터베이스 서버 자체를 강화)
□ Bigdata의 등장
—> 데이터와 트래픽 기하급수적 증가
—> 높은 성능 DBMS 필요
관계형 db는 수평적 확장 어렵고 수직적 확장 사용 해야 하는데? 하면되지!!!
그냥 cpu ram 추가해서 서버 자체 강화 하면 되는거 아냐? ㅎㅁㅎ!!!
==> (어우 안되겠다.. 장비 좋은 거 쓰면 될 줄 알았더니 비용 감당이 안되네..) —> 수직적 확장(scale-up) 비용 기하급수적 증가.
—> 데이터 일관성 포기하더라도 비용을 고려해 여러 대 서버에 데이터 분산 저장
∴ 수평적 확장(scale-out) 지원 목표!!!
(일관성을 포기회되, 비용 고려하여 여러 대의 서버에 데이터 분산 저장, scale-out 목표로 등장)
짜잔~!
■ Nosql
not only sql : 비관계형 db, 데이터 저장할 때 데이터 모델 사용
Key-value, document, graph, wide-column 등으로 데이터 저장
[Key-value, document, graph, wide-column ]
Key-value:
데이터를 Key와 Value의 쌍으로 저장하는 방식
간단하고 빠름. 확장성이 뛰어나며(어떤 데이터도 ok.), 일반적으로 분산형 시스템에서 많이 사용
주로 캐시 시스템이나 세션 저장소 등에 사용
Document:
JSON 또는 BSON과 같은 문서 형식으로 데이터를 저장 (key-document),(but 사용 번거롭고 쿼리가 sql과 다름)
(key-value와 다른 건 value가 게층적 도큐먼트로 저장)
스키마가 유연, 계층 구조로 데이터를 저장 (하나의 객체를 여러 테이블에 나눠 저장할 필요가 없어짐)
ex) NoSQL 데이터베이스인 MongoDB
Graph:
노드(Node)와 관계(Relationship)를 사용하여 데이터를 저장 (관게가 탐색의 키일 경우 적합)
데이터 간의 복잡한 관계를 표현하기에 적합
소셜 네트워크나 추천 시스템에서 사용. ex) Neo4j
Wide-column:
열 지향 데이터베이스로, 행이 아닌 열 단위로 데이터를 저장 (key에서 필드 결정)
(= like 속성이 계층적 구조 가지고 있는)
대용량 데이터 처리 및 분석에 적합, 증분적인 데이터 변경에 효율적
ex) Apache Cassandra
스키마 없어! 그래서 유연하고 자유로운 데이터 구조 가질 수 있음.
—> rdbms 단점인 스키마 변경 어려운 문제 해결!
ex) 데이터 구조 변경되더라도 db 구조 전체 변경 x
- 데이터 구조 자유로우니, 언제든 저장된 데이터를 조정하고 새로운 필드 추가 가능
[?]
스키마를 미리 정의하지 않고 데이터를 유연하게 저장할 수 있다는 것을 의미
So 애플리케이션의 요구사항 변경 & 새로운 데이터 필드가 필요한 경우
데이터베이스 구조 전체를 변경할 필요 없이 쉽게 데이터를 수정하고 확장 가능
- 수평/수직 확장 둘 다 가능
일관성만 포기하면 분산시켜서 성능 좋아지는거지?
단점 :
일관성, 가용성, 분할 허용성 특징 가지는 CAP(consistency, availability, partitioning tolerance)이론에 따라 설계됨
CAP 中 가용성 우선으로 고려하고, 일관성은 상대적으로 낮은 수준에서 보장
[CAP]
일관성(Consistency): 모든 노드에서 같은 시간에 같은 데이터를 볼 수 있어야 (= 데이터가 갱신되면 모든 노드에 반영되어야 함)
가용성(Availability): 모든 요청에 대해 응답을 받을 수 있어야 (= 시스템은 항상 사용 가능해야 함)
분할 허용성(Partition Tolerance): 시스템의 일부가 실패하거나 네트워크 통신이 실패하는 상황에서도 시스템이 계속해서 동작할 수 있어야 (= 네트워크의 분할로 인해 일부 노드 간 통신이 불가능해도 전체 시스템이 작동해야 함)
CAP 이론에서는 3 특성 中 2만 선택할 수 있다고 주장
일반적으로 CAP 이론에서는 분할 허용성은 필수로 선택되어야 함,
So 일관성과 가용성 중 한 가지를 희생하여 시스템을 설계
분산 환경에서 일관성 유지하는 건 매우 어려운 일,
각 대규모 분산 서버에 일관성 있는 복제 방법을 사용해야 일관성 유지됨
==> 그럼 지연 시간이 매우 큼;;;
또 복제된 데이터간 충돌 방지하기 위한 복잡한 알고리즘도 구현해야 됨
[ 복잡한 알고리즘 ? ]
버전 관리: 데이터를 변경할 때마다 버전을 부여, 충돌을 감지하고 해결
—> 각 데이터 변경 사항의 충돌을 식별하고 해소
분산 락(Lock): 여러 클라이언트가 동시에 데이터를 수정하려고 할 때 충돌을 방지하기 위해 락 사용
—> 한 번에 하나의 클라이언트만 데이터를 수정할 수 있도록 함
충돌 탐지 및 해결 알고리즘: 데이터 변경이 충돌을 일으킬 경우, 충돌을 탐지하고 해결하기 위한 알고리즘
—> 데이터의 일관성을 유지하고 데이터 손실을 방지
또...
- 데이터 중복 발생할 수 있으니, 중복 데이터 변경 경우 모든 컬렉션에서 수정해야 함
- 스키마 존재하지 않으니 명확 데이터 구조 보장하지 않음 —> 데이터 구조 결정 어려울 수도
- 데이터 중복되어있으니 update, delete 경우 모든 컬렉션에 수행해야 함 —> 느림
- key값에 대한 입출력만 지원
[ key값에 대한 입출력만 지원 ]
비관계형 데이터베이스에서 특정 데이터를 저장, 조회, 삭제할 때 key 값을 활용
—> 데이터에 접근하고 조작할 때 key 값을 이용하여 데이터를 식별하고 처리하는 방식 사용
—> 특정 key를 통해 데이터에 빠르게 접근 가능
==> 데이터의 입출력이 key에 의해 제한되는 특성
- 관계형 db와 다른 모델 사용 —> 기존 관계형 익숙 개발자 새로운 모델 대한 추가 학습과 적응 필요
그렇구나 !
그래서 nosql은
- schema 없어 다루기 쉬움 (스키마 선언 없이 필드 추가 삭제가 자유로운 schema-less)
- 데이터에 대한 규격화된 결과값 얻기 힘듦
[]
데이터의 구조가 자유롭고 유연하기 때문에
특정한 규격화된 형태로 결과를 얻는 것이 어려움
ex) 같은 종류의 데이터라도 각각 다른 문서나 열에 저장되어 있을 수도
—> 결과값의 형태가 다양하고 정형화되지 않음
==> 이런 유연성은 데이터의 다양한 형태와 구조를 다룰 수 있게 해주지만,
결과값을 일관된 형태로 얻는 데 어려움을 초래할 수 있음
- 서버 확장 용이(수평 확장)
- 고성능 (분산 처리)
- 가용성 (분산했으니 백업 서버 구성 가능, 장애에도 무중단 서비스 가능)
- 데이터간 관계 정의 안함 (join 불가)
- rdbms 복잡도 용량 한계 극복위해 등장한 만큼 훨씬 더 대용량 데이터 저장 가능
정도로 정리할 수 있겠네
요약하자면
Nosql db는
일반적으로 일부 데이터 일관성을 희생하고,
대신 높은 가용성과 분산 처리 능력을 보장하며 !!
[확장성과 유연성 강조]
Rdbms는
일반적으로 데이터 일관성과 무결성을 중시하며,
트랜잭션 처리 통해 데이터 일관성 유지하고 무결성 보장하여 !!
[항상 일관성 & 정확한 상태 유지 ]
출처
'CS' 카테고리의 다른 글
| S)DB_06_저장 프로시저 (1) | 2024.03.27 |
|---|---|
| CSS)DB_05_Schema (0) | 2024.03.25 |
| S)DB_03_트랜잭션3 (0) | 2024.03.14 |
| S)DB_03_트랜잭션2 (1) | 2024.03.14 |
| S)DB_03_트랜잭션 (0) | 2024.03.12 |