NoSQL, 클러스터링 vs 리플리케이션, DB샤딩

Previous Next


TL;DR




들어가기 전에

데이터 베이스를 사용하는 이유

데이터 베이스 이전에는 파일 시스템을 이용해 데이터를 관리했다. 이때 어플리케이션과 상호 연동이 되어야할 때 종속성 문제나 데이터 무결성 문제가 발생해 파일 시스템으로는 관리하기 한계가 있었다.

데이터 베이스는 이런 데이터 관련 문제를 해결해주는, 조직화된 데이터의 모음을 의미한다.

☝️ 여기서 잠깐!

  • 데이터의 종속성 (Dependency) : 프로그램의 구조가 데이터의 구조에 영향을 받는 것으로, 데이터의 구조가 변경되면 프로그램까지 같이 바뀌어야 하므로 프로그램 개발과 유지보수가 어렵다.

  • 데이터의 중복성 (Redundancy) : 파일 시스템은 프로그램마다 데이터 공유가 안되는 경우가 많아서 같은 정보를 중복해서 저장하는 경우도 많다. 저장 공간의 낭비이기도 하지만, 데이터 관리 측면에서 같은 정보를 여러 공간에 보관하면 수정 시 모든 데이터를 수정해야 한다는 문제가 발생한다.

  • 데이터의 무결성 (Integrity) : 데이터의 내용이 본래의 의도와 다른 형식을 갖게될 때 무결성이 침해됐다고 말한다. 데이터가 여러 경로를 통해 들어오기 때문에 잘못된 데이터가 들어오는 경우를 의미한다.



데이터 베이스 관리 시스템(DBMS)이란?


관계형 데이터 베이스란?


SQL 이란?

Structured Query Language


☝️ 여기서 잠깐!

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


특징


NoSQL 종류

Key-Value DB

Redis, Oracle NoSQL, Voldemorte, …

Key-Value DB


언제 사용하는게 좋을까?

  1. 성능 향상을 위해 관계형 데이터 베이스에서 데이터 캐싱
  2. 모바일 어플리케이션용 사용자 데이터 정보와 구성 정보 저장
  3. 이미지나 오디오 파일 같은 대용량 객체 저장



Doument DB

MongoDB, Azure Cosmos DB, CouchDB, …

Document DB


언제 사용하는게 좋을까?

  1. 대용량 데이터를 읽고 쓰는 웹 사이트용 백엔드 지원
  2. 다양한 유형의 메타 데이터 추적
  3. JSON 데이터 구조를 사용하는 어플리케이션



Wide Column DB

HBase, Cassandra, Hypertable, …

Wide Column DB


언제 사용하는게 좋을까?

  1. Log data 저장
  2. 주식 거래 데이터나 기온 모니터링 데이터 등 시계열 데이터 저장



Graph DB

Neo4J, Blasegraph, OrientDB

Graph DB


언제 사용하는게 좋을까?


NoSQL vs SQL

1) 스키마

  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간 통신이 실패하는 경우라도 시스템은 정상 동작


여기서 잠깐!

☝️ ACID 란?

트랜잭션은 여러 개의 작업을 하나로 묶어 모든 작업들을 완료해야 정상적으로 종료되는 실행 유닛이고, ACID는 데이터 베이스에서 트랜잭션의 안전성을 보장하기 위한 성질입니다.

예를 들면, 계좌 이체에서 나의 계좌에서 10만원을 빼고, A에게 10만원을 추가하는 종합적인 과정이 트랜잭션입니다.


여기서 잠깐!

✌️ CAP 이란?

2002년 버클리 대학의 Eric Brewer 교수가 발표한 분산 컴퓨팅 이론으로, 분산 컴퓨팅 환경에서 일관성, 가용성, 분산 가용성 세 가지 특징을 보장해야 함을 정의하고, 분산 시스템은 이중 두 가지만 만족할 수 있다는 이론이다.



그래서 둘 중에 뭘 선택해야 하는가?

정답은 없다. 어떤 데이터를 다루느냐에 따라 달라진다.


SQL 데이터 베이스 사용이 더 좋을 때


NoSQL 데이터 베이스 사용이 더 좋을 때




Replication vs Clustering


Replication


qwd

  1. Master Node에 쓰기 작업 실행
  2. 데이터를 저장하고 트랜잭션 로그를 파일에 기록(BinLog)
  3. Slave Node IO Thread는 BinLog를 복사
  4. Slave 노드의 SQL Thread는 파일을 읽으며 데이터 저장


  장점 단점
1 읽기 작업이 많은 DB 요청에서는 Replication만으로 충분히 성능 높이기 가능 Master 노드가 다운되면 복구, 대처가 까다로움
2 비동기 방식이라 지연 시간이 거의 없음 동기화가 보장되지 않아 일관성 있는 데이터 신뢰 불가



Clustering


qwd

  1. 1개의 노드에 쓰기 트랜잭션 수행
  2. 실제 디스크에 내용을 쓰기 전에 다른 노드로 데이터 복제 요청
  3. 다른 노드에서 복제 요청 수락 신호를 보내고, 디스크에 쓰기 시작
  4. 다른 노드로부터 신호를 받으면 실제 데이터 저장


  장점 단점
1 노드들 간의 데이터를 동기화하여 일관성 있는 데이터 신뢰 Replication에 비해 쓰기 성능이 떨어짐
2 1개의 노드가 죽어도 다른 노드가 살아있어, 시스템을 장애 없이 운영 장애가 전파된 경우 처리가 까다로움.




Sharding


qwd


샤딩 적용시 문제점 및 고려사항

  1. 데이터 재분배 (Rebalancing Data)
    • 샤딩된 DB의 물리적 한계나 성능 한계 도달 시 scale-up 작업이 필요한데,
    • 이때 서비스 정지 없이 scale-up 할 수 있도록 설계 방향 잡아야 한다.
  2. 데이터 조인하기
    • 샤딩 DB 간 조인이 불가능 하므로 데이터 중복에 대한 trade-off
  3. Global Unique Key

    DBMS에서 제공하는 auto-increament를 사용하면 Key가 중복될 수 있기 때문에 어플리케이션 레벨에서 Key 생성을 담당해야 한다.

    => 라우팅을 위해 구분할 수 있는 유일한 키값이 있어야 한다.

  4. 프로그래밍 복잡도가 증가하고, 데이터가 한 쪽 샤드로 몰리면 샤딩이 무의미해짐

  5. 한 번 샤딩 사용하면 샤딩 이전 구조로 돌아가기 힘들다.


샤딩 방법




면접 질문

데이터베이스란?

데이터 베이스는 데이터의 저장소입니다.



데이터 베이스는 왜 등장했나요?

데이터 베이스를 사용하기 전에는 파일 시스템을 이용해 데이터를 관리했습니다. 이때 데이터가 중복해서 저장되거나, 어플리케이션에 종속성 문제가 발생해 데이터를 체계적으로 관리하는데 한계가 있었기 때문에 데이터를 보다 효율적이고 문제없이 관리하기 위해 데이터 베이스를 사용하게 됐습니다.



데이터 베이스는 어떻게 관리하나요?

DBMS, 데이터 베이스 관리 시스템이라고 불리는 소프트웨어를 통해 관리합니다.

DBMS는 다수의 사용자가 DB를 통해 데이터를 검색하거나 저장하기 편리하고 효율적인 환경을 제공해줍니다.




데이터 베이스에는 어떤 종류가 있나요?

현재 많이 사용하는 데이터 베이스에는 크게 관계형 데이터 베이스와 NoSQL 이 있습니다.



사용해보신 DB 종류가 어떤 게 있나요?

졸업 프로젝트로 사용자가 촬영한 사진을 통해 재료를 인식해 ‘모바일 냉장고’에 넣고, 해당 재료로 레시피를 추천하는 웹 프로그램을 만들었습니다. 그 때 모바일 냉장고에 재료를 저장하기 위해 SQLite 를 사용해 DB를 구축했습니다.



사용해본 DB에 대해 설명해주세요.

SQLite는 낮은 메모리 환경에서도 좋은 성능을 내기로 알려진 오픈 소스 관계형 데이터 베이스입니다. 선택한 가장 큰 이유이기도 한 장점은 우선 무료이고, 공간 차지가 적으며 빠릅니다.

단점으로는 동시성에 제한이 있다는 점과 다른 RDBMS보다 보안이 약하다는 점이 있습니다. 하지만 진행한 프로젝트는 상업 용도가 아니었기 때문에 AWS 비용 문제로 인해 빠르고 공간 차지가 적은 SQLite을 선택해 사용했습니다.



NoSQL을 사용하여 프로젝트를 해본 적은 있나요? 프로젝트에 대한 간략한 소개와 왜 해당 DB를 사용했는지?

챗봇 프로젝트에서 mongoDB를 사용한 경험이 있습니다. 해당 프로젝트는 심리 컨텐츠를 사용자에게 설명해주는 챗봇을 개발하는 프로젝트로, 사용자의 정보와 질의응답 등을 DB에 저장할 필요가 있었습니다.

당시 챗봇이 앞으로 더 많은 기능을 추가할 예정이라 이에 따라 DB 구조가 변경될 가능성이 컸고 챗봇 구축을 RASA로 했는데 python 언어를 사용했기 때문에 mongoDB를 선택했습니다.




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 트래픽을 분산하기 위해 수행합니다.




교착상태의 조건 4가지

교착상태는 한 리소스는 한 번에 한 프로세스만 사용할 수 있고, 강제로 리소스를 뺏을 수 없는 상황에서 hold and wait 관계의 프로세스들이 환형으로 기다리고 있는 상황에 발생합니다.



트랜잭션 고립 수준에 대해서 아는대로 설명해주세요



추가

Dynamic sharding 단점

Locator에 의존해야 한다는 단점이 있습니다. 만약 Lacator가 성능을 위해 Cache 하면 잘못된 routing으로 인해 Error가 발생할 수 있습니다.



NoSQL의 의의

NoSQL이 RDBMS를 대체할 수는 없지만, NoSQL은 그만의 장점이 뚜렷합니다.

로그 데이터처럼 매 초 엄청난 양이 생성되지만 한 번 저장되면 수정될 일이 거의 없는 류의 데이터를 효율적으로 저장할 수 있고, 특히 분산형 구조를 통해 여러 대의 장비에 빠른 속도로 저장하고 데이터가 많이 누적되더라도 수평적 확장이 용이합니다.




References