원티드 프리온보딩 백엔드 챌린지 - 데이터베이스 1일차

1. 데이터 베이스의 원칙

(1) 무결성 (Data integrity)

- 데이터의 무결성은 데이터의 정확성(Accuracy), 일관성(Consistency)가 유지되는 것을 말하며, 데이터의 무결성을 유지하는 것은 DBMS의 중요한 기능이다.

 

(2) 안정성 (Data reliability)

- 데이터는 복원력이 있어야 하며(resilient), 고장이 나지 않아야 한다.

- 인증/인가되지 않은 사용자로부터 데이터를 보호해야 한다.

 

(3) 확장성 (scalability)

- 데이터베이스는 확장할 수 있어야 한다. (Scale-up & Scale-out)

 

2. 다양한 데이터베이스 종류

데이터베이스는 일반적으로 컴퓨터 시스템에 전자 방식으로 저장된 구조화된 정보 또는 데이터의 체계적인 집합을 의미하는데, DBMS란 사용자와 데이터베이스 사이에서 요구에 따라 정보를 생성해 주고 관리해주는 소프트웨어이다.

SQL(Structured Query Language)이란 RDBMS(관계형 DBMS)에서 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이며, 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정 등을 위해 만들어진 언어이다.

 

(1) RDBMS와 NoSQL의 비교

1) RDBMS

- 관계형 데이터베이스는 테이블이 다른 테이블들과의 관계를 맺고 모여 있는 집합체이다. 

이러한 관계를 나타내기 위해서 foreign key와 primary key를 사용하며, 외래키를 이용해 테이블 간의 join을 가능한것이 가장 큰 특징이다.

- MySQL, PostgreSQL, SQLite 등이 있다.

- Row와 Column으로 저장하기에 데이터 정합성이 보장되고 데이터 변경할 때마다 데이터를 스케일 업이 가능하다.

테이블 네임 중복 생성 안되기 때문에 같은 크기 서버 여러 개 둘 수 없고 크기를 키워서 스케일링 할 수 있다.
- order가 인덱스 테이블로 따로 관리한다. 
- 분산 저장하지 않기 때문에 데이터 분산성, 일관성이 잘 유지된다.

 

2) NoSQL

- NoSQL이란 Not Only SQL의 약자로 RDB와 달리 테이블 간의 관계를 정의하지 않는다. 

따라서 데이터 테이블은 그냥 하나의 테이블이며, 테이블 간의 관계를 정의하지 않아 테이블 간 join 또한 불가능하다.

 그럼 왜 이러한 NoSQL db가 나왔을까?

A. 등장 배경

- 빅데이터의 등장으로 데이터와 트래픽이 기하급수적으로 증가함에 따라 RDBMS의 단점인 scale up 비용이 기하급수적으로 증가하기에, 성능 향상을 위해 데이터 일관성은 포기하되 비용을 고려해 여러 대의 데이터에 분산해 저장하는 scale-out을 목표로 등장하였다.

 

B. NoSQL의 4가지 카테고리

① Document DB

- MongoDB가 대표적이다. xml이나 json document로 저장하여 SQL처럼 row와 column으로 존재하는 것이 아닌 원하는 종류의 어떤 모양의 데이터든 저장할 수 있다. 

- SQL에서는 유연성이 없지만, MongoDB는 각 데이터가 같은 형태일 필요가 없다.

- 블로그 같이 타입이 사진과 글 같이 타입이 다른 내용을 한번에 저장할 때 사용할 수 있다.

 

② Key-Value DB

- Redis, 카산드라 db, dynamo db가 대표적이다.

* Redis:

key와 value 형태로 값을 저장하는데, key 값이 겹쳐지지 않게 최대한 유연하게 값을 넣을 수 있다. 하지만 구체적인 검색은 불가하다. 따라서, 배열 형식 데이터에 빈번한 추가/삭제가 일어나는 경우 사용한다

하지만 in-memory db로 모든 데이터를 메모리로 불러오는 메모리 기반의 DBMS이므로, scalable하지는 않다.

*  DynamoDB: 

AWS에서 제공하는 NoSQL DB이기 때문에, 

같은 key-value db 유형이지만 redis와 다른점이 partition key와 sort key로 나누어짐. 

매우 빨리 많이 써야할 때 사용된다.

장점은 serverless이기 때문에 관리할 서버가 없으며, 자동으로 확장/축소하는 auto scaling 기능을 이용해 높은 성능을 유지한다. (scalable한것이 장점)

 

- document db랑 비교해본다면,  Key-Value db는 어떤 종류의 db를 얻을 수 있는지가 제한적이다.
그리고, 저장하기 전에 db에서 무엇을 얻을 것인지 미리 생각을 해 놓아야 한다.
예를들면, SQL에서는 데이터 구조를 걱정을 하지 어떻게 얻을 것인지는 고민 하지 않지만,  dynamodb에서는 저장하기 전에 미리 어떻게 할 것인지를 고민해야하는 단점이 있다. 
dynamodb처럼 빠른 속도를 얻으면 잃는 것도 있는데, SQL처럼 쿼리를 할 수 없기에 저장 전, 어떻게 데이터를 얻을 것인지 고민해야한다.

 

③ Graph DB

column이나 document가 필요없고 각 노드 사이 관계를 알아야 할때 필요하다.

페이스북 같은 경우가 대표적이다. (자체 tao라는 db를 만들어서 사용함)

document column을 저장하는 것이 아닌 entity를 저장하고 관계를 설정한다.

neo4j 가 대표적인 graph db로서, 링크드인의 1촌, 2촌 기능 같은 관계를 형성할때 사용하면 좋다.

 

④ Wide-Column DB (Column Family Database)

행마다 키와 값을 저장할 때마다, 각각 다른 값의 다른 수의 스키마를 가질 수 있다.

대량의 데이터 압축, 분산처리에 사용되며, 쿼리 동작속도와 확장성이 뛰어난 것이 특징이다.

 

* Cassandra DB:

특징은 읽고 쓰기가 매우 빠르다. 
카산드라는 많은 수의 아이템을 매우 빠르게 쓸 수 있다.
애플, 넷플릭스, 인스타, 우버 같은 회사에서 많은 양의 데이터를 빨리 저장하거나 검색 엔진처럼 많은 데이터를 빠르게 읽어야할때 유용하다.

 

3. RDB에서 Row oriented database와 Column oriented database

(1) Row oriented DB:

스키마의 레코드에 의해서 데이터를 organize하는 방식으로, 메모리에서 각 데이터가 담긴 레코드를 한줄로 유지하는 방식이다.

- 데이터를 구성하는 전통적인 방식이며, 데이터를 빠르게 저장하는데 좋다. (insert하는게 매우 간단)

- row를 read하고 writing하는데 최적화 되어 있다.

- MySQL과 PostgreSQL이 대표적이다.

위 방식으로 저장하기 때문에 row를 쓰는것이 빠르다. 추가하면, 마지막에 append해주면 된다.

하지만 단점은,

row를 읽어오는데는 빠르지만, column단위로 aggregation을 수행할 때, 연산을 수행할 column들만 선택하는 것보다 더 느리다.  (예를들어, 위의 예시에서 age를 다 더해줘야한다면, 9개 data를 다 메모리에 가져와서 관련된 data 뽑아 연산해야한다)

또한 row oriented db가 접근해야하는 디스크의 수는 일반적으로 더 크다.

 

또한 이 경우, 데이터를 삭제하고 추가함다면, db에서 저장 순서를 보장하지 않고, remove 한 자리에 추가된다. 순서가 보장되지 않기 때문에, read가 어렵다.

 

(2) Column oriented DB:

데이터를 필드로 구성하는 데이터베이스 방식이다.

- 메모리에 필드끼리 한줄로 유지하는 방식이다.

- 데이터를 querying하는데 성능적으로 이점이 있다.

- column을 효과적으로 read하고 계산하는데 최적화되어 있다.

- Redshift, BigQuery, Snowflake가 대표적이다.

이 경우에서는 레코드를 추가할 때, 데이터를 탐색해 각 열이 있어야할 위치에 연결해야 한다.

위 경우처럼, single disk에 데이터가 저장되어 있다면, 모든것을 메모리에 가져와야 하기 때문에, row oriented db와 같이 메모리 문제가 발생한다.  하지만 column oriented db는 disk들에 분리되어 있을때 장점이 두드러진다.

위에서, age의 합을 구하려 한다면, disk3에만 접근해 합을 구하면 된다. 더 추가적인 메모리가 필요하지 않고, 최소한의 disk에 접근한다.

이렇게 접근하는 disk수가 적어지고, 메모리에 있는 추가적인 데이터 양이 줄어들면서, 전체적인 computation의 속도는 매우 증가한다.

 

4. CAP theorem

그래서 많은 DB중에 어떤 것을 선택해 사용해야 할까?

CAP theorem에 따라서 어떤 DB를 적용할지 선택한다.

이것은 분산 시스템에서 일관성(Consistency), 가용성(Availability), 분할 용인(Partition tolerance)라는 세 가지 조건을 모두 만족할 수 없다는 정리이다.

 

(1) 일관성(Consistency)

일관성이란 어떤 노드에 연결되어 있는지와 무관하게 모든 클라이언트가 동시에 동일한 데이터를 볼 수 있음을 의미한다.

쉽게 말해 어떤 DB를 요청할 때 마다 같은 값이 와야하는 것이다. 금융 데이터가 예가 될 수 있다.

데이터베이스 안의 모든 노드들이 같은 값을 가지고 있어야 하며, request를 보내면 해당 request가 delay 될 수 있다.

 

(2) 가용성(Availability)

가용성이란 하나 이상의 노드가 작동 중지된 경우에도 데이터를 요청하는 클라이언트가 응답을 받음을 의미한다.

분산 시스템의 모든 작업 중인 노드는 예외 없이 모든 요청에 대해 유효한 응답을 리턴한다. 

(DB에 request 보내면 항상 response 받음. Consistency는 response 바로 안옴.)

하지만 해당 response가 가장 최근 데이터라는 것을 보장받을 수 없다.

쉽게 말해 살아 있어야 한다는 것이다. write했을때 바로 response가 오는 것을 말하며 e-commerce 대표적이다.

 

(3) 분할 용인(Partition tolerance)

분할(파티션)이란 시스템 내의 통신 단절, 즉 두 노드 간의 연결이 유실되거나 일시적으로 지연된 상태이다. 파티션 허용이란 시스템의 노드 간에 다수의 통신 단절에도 불구하고 클러스터가 계속해서 작동해야 함을 의미합니다.

분산저장했을때 중요한 특징이다.

 

위 세가지 특징을 동시에 다 가질 수는 없기 때문에, 성질에 맞게 DB를 잘 선택해야한다.

예를들어, 넷플릭스는 MySQL을 사용하는데, 이렇게 하면 DB 분산은 덜 될수가 있다.

인스타그램 경우, DB에 write 된것이 중요하기에 Availability를 중요시 여겨 DB를 선택해야한다.

위 특성들을 잘 고려해서 상황에 알맞은 DB를 선택하는 것이 중요하다.

 

5. Scale-up과 Scale-out

(1) 스케일 업 (Scale-up)

쉽게 말하면 기존의 서버를 보다 높은 사양으로 업그레이드하는 것을 말한다.

하드웨어적인 예를 들면, 성능이나 용량 증강을 목적으로 하나의 서버에 디스크를 추가하거나, cpu나 메모리를 업그레이드시키는 것을 말한다.

하나의 서버의 능력을 증강시키는 것이기에 vertical scaling 이라고도 한다.

 

추가적인 네트워크 연결 없이 용량을 증강할 수 있다. 

따라서 scale out보다 관리 비용이나 운영 이슈가 적고, 사양만 올리면 되는 것이기에 비교적 쉽다.

하지만 성능상 한계가 있고, 성능 향상에 따른 비용 부담이 크고, 서버 한 대가 부담하는 양이 많아 자연 재해 등으로 서버에 문제가 생기면 큰 타격을 입게된다.

또한 기존의 서버를 교체함으로써 성능을 올릴 때에는 서비스를 이용할 수 없는 다운타임이 불가피하다.

 

(2) 스케일 아웃(Scale-out)

장비를 추가해서 확장하는 방식을 말한다.

기존 서버만으로 용량이나 성능의 한계에 도달했을 때, 비슷한 사양의 서버를 추가로 연결해 처리할 수 있는 데이터 용량이 증가할 뿐만 아니라 기존 서버의 부하를 분담해 성능 향상의 효과를 기대할 수 있다.

서버를 추가로 확장하기에 horizontal scaling 이라고도 불린다.

 

Scale-out의 큰 장점 중 하나는 확장의 유연성이다.

서버를 필요한 만큼만 도입해 놓고, 장기적인 용량 증가 추이를 예측할 필요 없이 그때 그때 필요한 만큼 서버를 추가해 용량과 성능을 확장할 수 있다.

 

단점은, 무엇보다 여러 노드를 연결해 병렬 컴퓨팅 환경을 구성하고 유지하려면 아키텍처에 대한 높은 이해도가 요구된다.

서버의 수가 늘어날 수록 관리가 힘들어 지고, 아키텍처의 설계 단계에서부터 고려되어야 할 필요가 있기 때문이다.

 

여러 노드에 부하를 균등히 분산시키기 위해 로드 밸런싱이 필요하고, 노드를 확장할수록 문제 발생의 잠재 원인 또한 추가한 만큼 늘어나게 된다.

 

* Auto Scaling: 클라우드 서비스에서 자원 사용량을 모니터링하여 자동으로 서버를 증설 (scale out)하는 기능.

 

** 더 찾아볼것

- Big Query와 데이터 웨어하우스

- elastic search

 

Reference:

원티드 강의 1일차

노마드 코더 유튜브:

https://www.youtube.com/watch?v=Q_9cFgzZr8Q&ab_channel=%EB%85%B8%EB%A7%88%EB%93%9C%EC%BD%94%EB%8D%94NomadCoders

Redis: https://newtoner.tistory.com/23

DynamoDB: https://dev.classmethod.jp/articles/introduce_amazon_dynamodb/

NoSQL:

https://jaemunbro.medium.com/nosql-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%ED%8A%B9%EC%84%B1-%EB%B9%84%EA%B5%90-c9abe1b2838c

http://www.incodom.kr/NoSQL_DB_%EC%9D%98_%EC%A2%85%EB%A5%98#h_38691cefb3cd82117e6e8c1d3f903c0f

Row-oriented vs Column-oriented:

https://dataschool.com/data-modeling-101/row-vs-column-oriented-databases/

Cap Theorem:

https://www.ibm.com/kr-ko/cloud/learn/cap-theorem

http://eincs.com/2013/07/misleading-and-truth-of-cap-theorem/

Scale-up & Scale-out: https://tecoble.techcourse.co.kr/post/2021-10-12-scale-up-scale-out/