NoSQL, 클러스터링 vs 리플리케이션, DB샤딩
TL;DR
데이터 베이스 (Database, DB)
란 ? 데이터의 저장소데이터 베이스 관리 시스템(DBMS)
이란? 데이터 베이스를 운영하고 관리하는 소프트웨어SQL
이란? 구조화된 질의 언어라는 뜻으로 관계형 데이터 베이스에서 사용되는 언어-
NoSQL
이란? 클러스터링
vs리플리케이션
: DB를 수평적, 수직적으로 확장하는 두 가지 방법DB샤딩
: DB 트래픽을 분산할 목적으로 데이터를 분산해서 저장하는 기법
들어가기 전에
데이터 베이스를 사용하는 이유
데이터 베이스 이전에는 파일 시스템을 이용해 데이터를 관리했다. 이때 어플리케이션과 상호 연동이 되어야할 때 종속성
문제나 데이터 무결성
문제가 발생해 파일 시스템으로는 관리하기 한계가 있었다.
데이터 베이스는 이런 데이터 관련 문제를 해결해주는, 조직화된 데이터의 모음을 의미한다.
☝️ 여기서 잠깐!
데이터의 종속성 (Dependency) : 프로그램의 구조가 데이터의 구조에 영향을 받는 것으로, 데이터의 구조가 변경되면 프로그램까지 같이 바뀌어야 하므로 프로그램 개발과 유지보수가 어렵다.
데이터의 중복성 (Redundancy) : 파일 시스템은 프로그램마다 데이터 공유가 안되는 경우가 많아서 같은 정보를 중복해서 저장하는 경우도 많다. 저장 공간의 낭비이기도 하지만, 데이터 관리 측면에서 같은 정보를 여러 공간에 보관하면 수정 시 모든 데이터를 수정해야 한다는 문제가 발생한다.
데이터의 무결성 (Integrity) : 데이터의 내용이 본래의 의도와 다른 형식을 갖게될 때 무결성이 침해됐다고 말한다. 데이터가 여러 경로를 통해 들어오기 때문에 잘못된 데이터가 들어오는 경우를 의미한다.
데이터 베이스 관리 시스템(DBMS)이란?
- 데이터 베이스를 관리하고 운영하는 소프트웨어
- 다수의 컴퓨터 사용자들이 컴퓨터에 수록 된 수 많은 자료들을 쉽고 빠르게 추가, 수정, 삭제 할 수 있도록 해주는 시스템
- 데이터베이스 내의 정보를 검색하거나 정보를 저장하기 편리하고 효율적인 환경을 제공하는 것이 목적
- DBMS의 종류
- MySQL, MariaDB, Oracle, SQLite, DB2, SQL Server, PostgreSQL, …
- 계층형(Hierarchical), 망형(Network), 관계형(Relational), 객체지향형(Object-Oriented), 객체관계형(Object-Relational) 등으로 분류할 수 있으나 현재는 RDBMS를 제외하고는 거의 사용되지 않는다.
관계형 데이터 베이스란?
- 데이터를 열(column)과 행(row)으로 구성된 테이블(table)에 저장
- 각 열은 하나의 속성에 대한 정보를 저장하고, 행은 각 열의 데이터 형식에 맞는 데이터가 저장된다.
- 테이블의 구조와 데이터 타입 등을 사전에 정의하고, 해당 테이블에 알맞은 형태의 데이터만 삽입할 수 있다.
SQL 이란?
Structured Query Language
- 관계형 데이터 베이스에서 사용되는 언어
- 관계형 데이터 베이스에서 모두 SQL이라는 언어를 사용하므로 관계형 데이터 베이스를 총칭해서 SQL이라고 부르기도 한다.
☝️ 여기서 잠깐!
SQL은 누가 만드나요?
- 국제 표준화 기구에서 SQL에 대한 표준을 정해서 발표하고 있고, 이를 표준 SQL이라고 한다.
- 다만 표준 SQL이 각 회사의 DBMS 특성을 모두 포용하지 못하기 때문에 표준 SQL을 준수하되 각 제품의 특성을 추가한 SQL을 사용한다.
- Oracle은 PL/SQL, SQL Server는 T-SQL, MySQL은 SQL로 명칭한다.
비관계형 데이터 베이스의 등장 배경
관계형 데이터 베이스는 20년 이상 데이터 베이스 시장을 지배했는데, 기술과 빅데이터 응용 프로그램이 발전함에 따라 SQL 기반 데이터베이스는 빠르게 확장되는 데이터의 양과 복잡해지는 데이터 구조를 처리하기에 한계에 부딪혔다. 이를 해결하기 위해 CPU나 메모리를 추가하는 방편을 사용했지만 이 방식은 비싸고 임시 방편일 뿐이었다.
대표적인 인터넷 기업이면서 대용량 단순 데이터를 많이 보유해 단순 대용량 데이터 처리에 대한 요구가 가장 많은 구글과 아마존에 의해 Bigtable과 Dynamo라는 논문이 발표되었고, 이 두 논문은 새로운 데이터 저장 기술을 만들어내는 시발점이 됐다.
결국 대용량 데이터 관리 작업에 필요한 유연하고, 확장 가능하며, 비용적으로 효율적이면서 높은 가용성을 가지는 데이터 베이스 스키마를 재설계하게 됐고, 이것이 NoSQL이다.
NoSQL
Not Only SQL
- 비관계형 데이터 베이스
-
관계형 데이터 베이스 이외의 형식으로 데이터를 저장하는 데이터 베이스를 총칭
-
RDBMS의 한계를 극복하기 위해 Join이 없고, 고정된 스키마를 갖지 않는 새로운 형태의 데이터 저장소
- Document, Graph, Key-Value, Column Store 등의 방식이 있다.
특징
- RDBMS와 달리 데이터 간의 관계를 정의하지 않는다.
- 관계형 데이터 베이스가 데이터의 관계를 Foreign Key 등으로 정의하고 이를 이용해 Join 등의 관계형 연산을 한다고 한다면, NoSQL은 데이터 간의 관계를 정의하지 않는다.
-
RDBMS에 비해 훨씬 대용량의 데이터를 저장 가능
- 분산형 구조를 통해 여러 대의 서버에 분산해 저장하고 상호 복제해 데이터 유실이나 서비스 중지에 대비 가능
확장성
가용성
- RDBMS는 보통 하나의 고성능 머신에 데이터를 저장함
- 고정되지 않은 테이블 스키마 (테이블의 스키마가 유동적)
유연성
- 데이터 베이스 설계를 변경하지 않고도 필요한 속성을 동적으로 추가할 수 있다.
- 읽기 작업보다 쓰기 작업이 더 빠르고, 일반적으로 RDBMS에 비해 쓰기와 읽기 성능이 빠르다.
고성능
- 대량의 데이터를 빠르게 처리하기 위해 메모리에 임시 저장하고 응답하는 등의 방법을 사용
NoSQL 종류
Key-Value DB
Redis, Oracle NoSQL, Voldemorte, …
-
Amazon의 Dynamo Paper에서 유래
-
Key와 Value의 쌍으로 데이터가 저장되는 유형
-
Key는 값에 접근하기 위한 용도이고 (Unique 값)
Value에는 어떤 형태의 데이터(이미지, 비디오 포함)도 담을 수 있다.
-
간단한 API를 제공해 질의 속도가 굉장히 빠름
언제 사용하는게 좋을까?
- 성능 향상을 위해 관계형 데이터 베이스에서 데이터 캐싱
- 모바일 어플리케이션용 사용자 데이터 정보와 구성 정보 저장
- 이미지나 오디오 파일 같은 대용량 객체 저장
Doument DB
MongoDB, Azure Cosmos DB, CouchDB, …
- Lotus Notes에서 유래
- Key-Value 와 차이는 값을 문서로 저장한다는 점
- 여기서 문서란 JSON, XML과 같은 형식을 말한다.
- Document 내 객체는 서로 다른 필드를 가질 수 있음
- 데이터를 여러 서버에 분산 저장이 가능하고 복제와 회복이 가능한 형태라 장애가 발생해도 대응에 유리하다.
- 단점이라면 쿼리가 SQL과 다르고, 질의 결과가 JSON이나 XML 형태로 출력된다는 점
언제 사용하는게 좋을까?
- 대용량 데이터를 읽고 쓰는 웹 사이트용 백엔드 지원
- 다양한 유형의 메타 데이터 추적
- JSON 데이터 구조를 사용하는 어플리케이션
Wide Column DB
HBase, Cassandra, Hypertable, …
- Big Table DB라고도 하며, Google의 BigTable Paper에서 유래
- Column Family 데이터 모델을 사용
- 행마다 각각 다른 값과 다른 수의 스키마를 가질 수 있음
- 사용자 이름(Key)에 해당하는 값에 스키마들이 각각 다름
- 대량의 데이터의 압축, 분산 처리, 집계 처리 및 쿼리 동작 속도 그리고 확장성이 뛰어남
언제 사용하는게 좋을까?
- 열이 모든 행에 대해 항상 동일하지 않고, 여러 데이터 베이스 노드에 분산될 수 있는 대규모 데이터 셋이 필요할 때 사용하는 것이 이상적
- Log data 저장
- 주식 거래 데이터나 기온 모니터링 데이터 등 시계열 데이터 저장
Graph DB
Neo4J, Blasegraph, OrientDB
- Euler & Graph Theory에서 유래
- 노드, 엣지, 프로퍼티와 함께 그래프 구조를 사용해 데이터를 표현하고 저장
-
질의가 그래프 순회를 통해 이루어진다.
- RDBMS보다 성능이 좋고 유연하며 유지보수에 용이하다.
- 클러스터링에 적합하지 않고 질의 언어도 특화되어 있어 배우기 어렵다.
언제 사용하는게 좋을까?
-
데이터 간의 관계가 탐색의 키일 경우
-
페이스북이나 트위터 같은 SNS 에서 내 친구의 친구를 찾는 질의 등에 적합하고,
-
연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 데이터 베이스로도 적합
-
NoSQL vs SQL
1) 스키마
- DB의 구조, 제약조건에 관한 명세
- 개체의 특징을 나타내는 속성(Attribute)
- 속성들의 집합으로 이루어진 개체(Entity)
- 개체 간 존재하는 관계(RelationShip)
SQL | NoSQL | |
---|---|---|
1 | Table에 데이터가 저장됨 (2차원 테이블로 모델링) | Document에 저장됨 Document가 모여 Collection Collection이 모여 Database |
2 | Row, Col 구조 | Key-Value 형태로 데이터 저장 |
3 | 스키마를 정의 해야 데이터를 저장할 수 있음 | 스키마를 정의하지 않아도 된다. |
2) Relation(관계)
SQL | NoSQL | |
---|---|---|
1 | SQL에서 가장 중요 | Join 이란 개념이 없음 |
2 | Table간의 관계(Join)을 통해 데이터를 파악할 수 있음 | Users 의 데이터가 Orders에 다 담김. -> Join을 통해 확인 X |
3 | 데이터를 중복 없이 저장 가능(정규화 필요) | Collections 별로 중복된 데이터 존재 -> 업데이트 할 때 주의 필요 |
3) Scalability(확장)
SQL | NoSQL | |
---|---|---|
특징 | Vertical | Horizontal |
= Scale up | = Scale out | |
성능을 향상시키는 것 | 더 많이 서버를 늘리는 것 |
4) Property(특성)
SQL | NoSQL | |
---|---|---|
특징 | ACID | CAP (ACID를 완벽히 구현하지 않고 “Eventual consistency” 개념을 도입.) |
트랜잭션이 안전하게 수행되도록 보장하는 것 | CAP 의 Consistency나 Avaliability를 포기해 분산 확장성을 보장 | |
A+P : 비동기식 서비스 C+P : 성능 보장형 대용량 분산 파일 시스템 |
||
Atomicity(원자성) : 트랜잭션의 작업이 부분적으로 실행되거나 중단되지 않는 것을 보장 | 트랜잭션 ACID를 느슨하게 유지 | |
Consistency(일관성) : 미리 정의된 규칙에서만 수정이 가능한 특성 (숫자 컬럼에 문자열 값 저장 안되도록 보장) | Consistency (일관성) : 모든 요청은 최신 데이터 또는 에러를 응답 (DB가 3개로 분산되었다고 가정할 때, 하나의 특정 DB의 데이터가 수정되면 나머지 2개의 DB에서도 수정된 데이터를 응답받아야 한다.) | |
Isolation(고립성) : 트랜잭션 수행시 다른 트랜잭션의 작업이 끼어들지 못하도록 보장 | Availability (가용성) : 모든 요청은 정상 응답을 받는다. (특정 DB가 장애가 나도 서비스가 가능해야 한다.) | |
Durability(영구성) : 성공적으로 수행된 트랜잭션은 영원히 반영 | Partitions Tolerance (분리 내구성) : DB간 통신이 실패하는 경우라도 시스템은 정상 동작 |
- NoSQL은 분산형의 특성상 정보의 일관성을 유지하기가 어렵다. 수많은 머신에 데이터를 분산저장했는데 한 영역에 Update가 생길 시 그것을 실시간으로 다른 영역에 전파하는 것이 쉽지만은 않기 때문이다. 반드시 어느 정도의 전파 비용은 수반될 수밖에 없다. 그래서 NoSQL은 Consistency를 조금 타협하고 꼭 실제 최신은 아닐 수 있지만 “업데이트가 되기 전까지는” 가지고 있는 최신의 데이터를 반환한다는 “Eventual Consistency”라는 개념을 사용한다.
여기서 잠깐!
☝️ ACID 란?
트랜잭션은 여러 개의 작업을 하나로 묶어 모든 작업들을 완료해야 정상적으로 종료되는 실행 유닛이고, ACID는 데이터 베이스에서 트랜잭션의 안전성을 보장하기 위한 성질입니다.
예를 들면, 계좌 이체에서 나의 계좌에서 10만원을 빼고, A에게 10만원을 추가하는 종합적인 과정이 트랜잭션입니다.
여기서 잠깐!
✌️ CAP 이란?
2002년 버클리 대학의 Eric Brewer 교수가 발표한 분산 컴퓨팅 이론으로, 분산 컴퓨팅 환경에서 일관성, 가용성, 분산 가용성 세 가지 특징을 보장해야 함을 정의하고, 분산 시스템은 이중 두 가지만 만족할 수 있다는 이론이다.
그래서 둘 중에 뭘 선택해야 하는가?
정답은 없다. 어떤 데이터를 다루느냐에 따라 달라진다.
SQL 데이터 베이스 사용이 더 좋을 때
- 관계를 맺고 있는 데이터가 자주 변경되는 어플리케이션
- 변경될 여지가 없는 명확한 스키마가 사용자와 데이터에게 중요한 경우
- 데이터베이스의 ACID 성질을 준수해야 하는 경우 (금융 서비스)
NoSQL 데이터 베이스 사용이 더 좋을 때
-
정확한 데이터 구조를 알 수 없거나 변경/확장 될 수 있는 경우
- 읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
- 데이터 정합성이나 일관성이 최고 우선순위가 아닌 경우
- 데이터베이스를 수평으로 확장해야 하는 경우 (막대한 양의 데이터를 다뤄야 하는 경우)
Replication vs Clustering
- 리플리케이션은 여러 개의 DB를 수직적인 구조(Master-Slave)로 구축하는 방식
- 데이터 베이스 서보와 스토리지를 모두 확장
- 클러스터링은 여러 개의 DB를 수평적인 구조로 구축하는 방식
- 데이터 베이스 서버를 확장
Replication
- 여러 개의 DB를 권한에 따라 수직 구조로 구축하는 방식.
- 데이터 베이스 서버와 스토리지를 모두 확장
- Master Node는 쓰기 작업만, Slave Node는 읽기 작업만. (기존의 부하를 분산)
- 비동기 방식으로 노드 데이터 동기화
- Master Node에 쓰기 작업 실행
- 데이터를 저장하고 트랜잭션 로그를 파일에 기록(BinLog)
- Slave Node IO Thread는 BinLog를 복사
- Slave 노드의 SQL Thread는 파일을 읽으며 데이터 저장
장점 | 단점 | |
---|---|---|
1 | 읽기 작업이 많은 DB 요청에서는 Replication만으로 충분히 성능 높이기 가능 | Master 노드가 다운되면 복구, 대처가 까다로움 |
2 | 비동기 방식이라 지연 시간이 거의 없음 | 동기화가 보장되지 않아 일관성 있는 데이터 신뢰 불가 |
Clustering
- 여러 개의 DB를 수평 구조로 구축하는 방식. (데이터 베이스 서버 확장)
- Fail Over 시스템을 구축하기 위해 사용.
- 데이터 베이스가 동작하지 않으면 전체 서비스가 동작할 수 없다는 점을 해결하기 위해 Clustering을 통해 데이터 베이스 서버를 늘린다.
- 동기 방식으로 노드들 간의 데이터 동기화
- 1개의 노드에 쓰기 트랜잭션 수행
- 실제 디스크에 내용을 쓰기 전에 다른 노드로 데이터 복제 요청
- 다른 노드에서 복제 요청 수락 신호를 보내고, 디스크에 쓰기 시작
- 다른 노드로부터 신호를 받으면 실제 데이터 저장
장점 | 단점 | |
---|---|---|
1 | 노드들 간의 데이터를 동기화하여 일관성 있는 데이터 신뢰 | Replication에 비해 쓰기 성능이 떨어짐 |
2 | 1개의 노드가 죽어도 다른 노드가 살아있어, 시스템을 장애 없이 운영 | 장애가 전파된 경우 처리가 까다로움. |
Sharding
-
같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법.
= Horizontal Partitioning
-
DB 트래픽을 분산할 목적
- 데이터가 급격히 증가하게 되거나 트래픽이 특정 DB로 몰리는 상황을 대비해서 빠르고 유연하고 안전하게 DB를 증설할 수 있게 한다. (DB 서버의 부하를 분산)
- Scale-up 에는 한계가 있고, Scale-out은 동기화라는 제약이 따르게 되므로 DB 서버의 샤딩은 대규모 시스템 설계와 확장성 확보에 필수 불가결인 요소가 된다.
-
다수의 복제본으로 구성하고 각 샤드에 어떤 데이터가 저장될 지를 Shard Key를 기준으로 분리한다.
-
Shard Key를 어떻게 정의하느냐에 따라 데이터를 효율적으로 분산시키는 것이 결정됨
샤딩 적용시 문제점 및 고려사항
- 데이터 재분배 (Rebalancing Data)
- 샤딩된 DB의 물리적 한계나 성능 한계 도달 시 scale-up 작업이 필요한데,
- 이때 서비스 정지 없이 scale-up 할 수 있도록 설계 방향 잡아야 한다.
- 데이터 조인하기
- 샤딩 DB 간 조인이 불가능 하므로 데이터 중복에 대한 trade-off
-
Global Unique Key
DBMS에서 제공하는 auto-increament를 사용하면 Key가 중복될 수 있기 때문에 어플리케이션 레벨에서 Key 생성을 담당해야 한다.
=> 라우팅을 위해 구분할 수 있는 유일한 키값이 있어야 한다.
-
프로그래밍 복잡도가 증가하고, 데이터가 한 쪽 샤드로 몰리면 샤딩이 무의미해짐
- 한 번 샤딩 사용하면 샤딩 이전 구조로 돌아가기 힘들다.
샤딩 방법
- Hash Sharding : 데이터를 어디에 넣을지 해싱하여 결정
- Dynamic Sharding : Locator Service 를 통해 동적 샤딩 키를 얻어 사용
- Entity Group : 관련된 데이터를 하나의 샤드로 사용하는 방식
면접 질문
데이터베이스란?
데이터 베이스는 데이터의 저장소입니다.
데이터 베이스는 왜 등장했나요?
데이터 베이스를 사용하기 전에는 파일 시스템을 이용해 데이터를 관리했습니다. 이때 데이터가 중복해서 저장되거나, 어플리케이션에 종속성 문제가 발생해 데이터를 체계적으로 관리하는데 한계가 있었기 때문에 데이터를 보다 효율적이고 문제없이 관리하기 위해 데이터 베이스를 사용하게 됐습니다.
데이터 베이스는 어떻게 관리하나요?
DBMS, 데이터 베이스 관리 시스템이라고 불리는 소프트웨어를 통해 관리합니다.
DBMS는 다수의 사용자가 DB를 통해 데이터를 검색하거나 저장하기 편리하고 효율적인 환경을 제공해줍니다.
- (추가) 알고 있는 DBMS에는 MySQL, Oracle, SQLite, MongoDB 등이 있습니다.
데이터 베이스에는 어떤 종류가 있나요?
현재 많이 사용하는 데이터 베이스에는 크게 관계형 데이터 베이스와 NoSQL 이 있습니다.
사용해보신 DB 종류가 어떤 게 있나요?
졸업 프로젝트로 사용자가 촬영한 사진을 통해 재료를 인식해 ‘모바일 냉장고’에 넣고, 해당 재료로 레시피를 추천하는 웹 프로그램을 만들었습니다. 그 때 모바일 냉장고에 재료를 저장하기 위해 SQLite 를 사용해 DB를 구축했습니다.
사용해본 DB에 대해 설명해주세요.
SQLite는 낮은 메모리 환경에서도 좋은 성능을 내기로 알려진 오픈 소스 관계형 데이터 베이스입니다. 선택한 가장 큰 이유이기도 한 장점은 우선 무료이고, 공간 차지가 적으며 빠릅니다.
단점으로는 동시성에 제한이 있다는 점과 다른 RDBMS보다 보안이 약하다는 점이 있습니다. 하지만 진행한 프로젝트는 상업 용도가 아니었기 때문에 AWS 비용 문제로 인해 빠르고 공간 차지가 적은 SQLite을 선택해 사용했습니다.
NoSQL을 사용하여 프로젝트를 해본 적은 있나요? 프로젝트에 대한 간략한 소개와 왜 해당 DB를 사용했는지?
챗봇 프로젝트에서 mongoDB를 사용한 경험이 있습니다. 해당 프로젝트는 심리 컨텐츠를 사용자에게 설명해주는 챗봇을 개발하는 프로젝트로, 사용자의 정보와 질의응답 등을 DB에 저장할 필요가 있었습니다.
당시 챗봇이 앞으로 더 많은 기능을 추가할 예정이라 이에 따라 DB 구조가 변경될 가능성이 컸고 챗봇 구축을 RASA로 했는데 python 언어를 사용했기 때문에 mongoDB를 선택했습니다.
- (추가) mongoDB의 단점
- mongoDB는 CASCADE 기능을 지원하지 않아, 자주 변경되는 데이터를 저장하면 오히려 성능 저하 문제가 있다는 점
SQL과 NoSQL의 특성을 설명해주세요
SQL은 관계형 데이터베이스를 총칭하는 말로, 데이터를 열과 행으로 구성된 테이블에 저장하고, 미리 정의된 형태의 데이터만 삽입할 수 있고, 트랜잭션 수행을 보장합니다.
NoSQL은 비관계형 데이터베이스를 총칭하는 말로, SQL과 달리 관계를 정의하지 않아 정해진 데이터 구조가 없고 읽기 쓰기 성능이 빠릅니다.
NoSQL에는 어떤 종류가 있나요?
NoSQL은 데이터를 저장하는 방식에 따라 다른데, 저는 Key-Value DB, Document DB, Wide Column DB, Graph DB 를 알고 있습니다.
Key-Value DB는 말 그대로 key와 value 쌍으로 데이터가 저장되는 유형으로 key는 값에 접근하기 위한 unique 한 값을 갖고, value에는 문자열 뿐 아니라 이미지나 비디오 등 어떤 형태의 데이터든 담을 수 있습니다.
Document DB는 Key-Value DB와 유사하나 Value가 JSON 이나 XML 형식의 문서라는 점이 다릅니다.
Wide Column DB는 행마다 다른 값과 다른 수의 스키마를 가질 수 있는 DB입니다.
Graph DB는 그래프 구조로 데이터를 표현하고 저장하며 질의도 그래프 순회로 이루어지는 DB입니다.
본인이라면 RDB와 NoSQL 기술을 결정해야 할 때 어떤 기준을 가지고 결정하시겠어요?
저장할 데이터에 따라 다를 것 같습니다. 만약 데이터의 구조가 명확하고 관계를 맺는 데이터가 자주 변경된다면, 또는 금융 서비스처럼 트랜잭션이 보장되어야 할 때는 RDB를 선택할 것입니다.
반면 정확한 데이터 구조가 없거나 변경될 수 있는 경우거나, 변경보다는 읽는 작업이 많을 때, 또는 다뤄야 하는 데이터의 양이 매우 많을 때는 NoSQL을 사용할 것입니다.
데이터 베이스를 확장하는 방법은?
데이터를 확장하는 방법으로는 수직적으로 확장하는 리플리케이션, 수평적으로 확장하는 클러스터링, 그리고 수평적으로 분할하는 샤딩이 있습니다.
리플리케이션 vs 클러스터링
리플리케이션은 여러 개의 DB를 수직적인 구조로 구축하는 방식입니다. 하나의 master DB에서는 쓰기 작업만 하고, 여러 개의 slave DB에서는 읽기 작업만 함으로 기존의 트래픽을 분산합니다.
클러스터링은 여러 개의 DB를 수평적인 구조로 구축하는 방식입니다. 서버를 확장해서 Fail over 시스템을 구축하기 위해 주로 사용하는데, 하나의 DB가 동작하지 않더라도 다른 DB를 통해 계속해서 서비스를 제공할 수 있도록 하는 방식입니다.
클러스터링의 단점은?
일반적으로 리플리케이션에 비해 성능이 떨어지고 동기화 방식이기 때문에 만약 에러가 전파되면 처리하기 까다롭다는 단점이 있습니다.
리플리케이션의 단점은?
리플리케이션은 비동기 방식이기 때문에 일관성 있는 데이터 신뢰가 불가능하고, 만약 Master 노드가 다운되면 복구나 대처가 까다롭다는 단점이 있습니다.
가장 큰 데이터를 다룬 프로젝트는 무엇인가요? 데이터 양이 많아질 때 어떻게 하면 효율적으로 관리가 가능할까요?
챗봇 프로젝트가 가장 큰 데이터를 다룬 프로젝트였습니다. 사실 해당 프로젝트에서는 DB 확장이 필요할만큼의 대용량 데이터는 아니라 확장과 관련된 기술을 적용해본 경험은 없습니다. 만약 데이터 양이 많아진다면 DB를 확장하거나 혹인 리플리케이션 방식으로 트래픽을 분산해 관리할 것 같습니다.
하지만 RDB를 사용한다면 그 외에도 샤딩 방식으로 데이터를 분산 저장해 관리하는 방법도 생각해볼 것 같습니다.
DB 샤딩이란?
DB 샤딩이란 같은 테이블 스키마를 가진 데이터를 다수의 DB에 분산해 저장하는 방법으로, DB 트래픽을 분산하기 위해 수행합니다.
-
(추가) DB 샤딩의 문제점 및 고려사항
샤딩 DB 간 Join 연산이 불가하기 때문에 trade-off가 발생하고, 만약 한 쪽 샤드로 몰리면 샤딩이 무의미해지므로 분산 저장을 위한 샤딩 키를 적절하게 잘 찾는 것이 성능에 큰 영향을 미치게 됩니다.
또 샤딩은 적용하면 이전 구조로 돌아가기 어렵다 것도 고려해야합니다.
교착상태의 조건 4가지
교착상태는 한 리소스는 한 번에 한 프로세스만 사용할 수 있고, 강제로 리소스를 뺏을 수 없는 상황에서 hold and wait 관계의 프로세스들이 환형으로 기다리고 있는 상황에 발생합니다.
트랜잭션 고립 수준에 대해서 아는대로 설명해주세요
추가
Dynamic sharding 단점
Locator에 의존해야 한다는 단점이 있습니다. 만약 Lacator가 성능을 위해 Cache 하면 잘못된 routing으로 인해 Error가 발생할 수 있습니다.
NoSQL의 의의
NoSQL이 RDBMS를 대체할 수는 없지만, NoSQL은 그만의 장점이 뚜렷합니다.
로그 데이터처럼 매 초 엄청난 양이 생성되지만 한 번 저장되면 수정될 일이 거의 없는 류의 데이터를 효율적으로 저장할 수 있고, 특히 분산형 구조를 통해 여러 대의 장비에 빠른 속도로 저장하고 데이터가 많이 누적되더라도 수평적 확장이 용이합니다.