DB의 종류와 특징

코딩애플 Node.js와 Mongo DB 강의에서 가져옴

 

심심할 때 읽어보는 DB의 종류와 특징

 

데이터베이스는 전통이 매우 깊습니다.

과거엔 계층형, 네트워크 이런 데이터베이스들이 있었고 최근들어 Graph 이런 데이터베이스까지도 등장했습니다. 

하지만 현재 실제 웹서비스 개발시 이용하는 데이터베이스는 대부분 이 둘 중 하나로 분류합니다. 

관계형 데이터베이스, NoSQL 데이터베이스인데 이게 무엇인지 상세히 알아보도록 합시다. 

 

 

1. 관계형(Relational) 데이터베이스 

 

정의

80년대 부터 흥하기 시작해서 아직까지도 사용하고 있는 데이터베이스의 표준 같은 데이터베이스입니다. 

관계형 데이터베이스는 짧게 요약하자면 

엑셀처럼 행과 열로 데이터를 저장할 수 있는 데이터베이스를 뜻합니다. 

 

 

어떻게 생겼나

엑셀의 시트처럼생긴 테이블이라고 부르는 공간을 하나 생성한 다음

행과열에 맞춰 데이터를 쭉 저장합니다. 

생긴 것도 엑셀처럼 생겼습니다. 

 

 

특징

- 거의 모든 곳에 사용할 수 있어 범용적입니다.  

- 구조화된 데이터를 저장하기 가장 좋습니다. 

- 보통 SQL이라는 언어를 이용해 데이터를 출력 입력합니다. 

- "이 열엔 숫자가 들어옵니다~"라고 스키마를 미리 정의하기 때문에 관리가 쉽습니다. 

- 구조화된 데이터 덕분에 원하는 데이터 뽑기도 쉽습니다.  

- 트랜잭션 롤백 이런 기능을 이용해 데이터의 무결성을 보존하기 쉽기 때문에 금융, 거래 서비스에 필수입니다. 

 

 

 

도대체 Relational 이라는게 무슨 뜻인가

데이터들 간의 관계를 정해서 데이터를 저장할 수 있다라는 뜻입니다.

뭔 소리인지 예를 들어보도록 합시다. 

 

학교를 운영하는데 학교 선생님들과 가르치는 과목 정보를 DB에 저장하려고 합니다.

 

 

선생님마다 가르치는 과목들을 이렇게 저장할 수 있겠죠? 

그런데 손흥민 선생님이 가르치는 과목이 많아지면 어떻게 DB에 저장하는게 좋을까요? 

 

 

 

▲ 대충 이렇게 저장하면 될까요?

아마 나중에 데이터 꺼내쓸 때 문제가 있겠죠. 좋은 생각은 아닙니다. 

손흥민 선생님 행을 하나 더 만든다고 해도 문제가 많겠죠. 선생님 번호 중복이 마구 생길 것 같습니다. 

이것이 테이블 형 데이터베이스의 단점인데, 데이터가 3차원으로 늘어나게 되면 2차원의 테이블 내에서 제대로 표현할 수가 없게 됩니다. 

그래서 테이블을 하나 더 만든 후 테이블간의 관계를 지어줍니다. 

 

 

 

 

 

이건 어때보입니까. 테이블을 하나 더 만들어서 

왼쪽엔 선생님 관리하는 테이블,

오른쪽은 과목 관리하는 테이블입니다. 그리고 과목에 선생님 번호를 적어서 어떤 선생님이 가르치는지 관계를 지어준 것이고요. 

이게 바로 관계형 데이터베이스의 특징이자 구축방법입니다. 

관계의 종류도 있는데  

- one to one, one to many, many to many 

이런 관계들이 있습니다. 

DB처리자격증 딸 것도 아니니 여기까지 하겠습니다. 

 

 

 

 

2. NoSQL 데이터베이스

 

정의 

용어자체는 약간 범용적입니다. SQL문없이도 사용할 수 있는 데이터베이스라고 보시면 됩니다. 

대부분 테이블에 국한되지 않고 자유로운 형식으로 데이터를 쉽게 분산저장할 수 있습니다. 

 

 

 

종류

종류는 매우 여러가지 입니다. 

- Key-value 모델 : Object, JSON 자료형 형식으로 데이터를 쉽게쉽게 저장, 출력이 가능합니다. 가장 심플함

- Document 모델 : 테이블 대신 Collection이라는 문서 기반으로 데이터를 분류하고 저장합니다. 테이블보다는 훨씬 유연합니다. 

(우리가 사용하고 있는 MongoDB도 Key-value, Document 모델 저장방식을 차용하고 있습니다)

- Graph 모델 : 데이터를 노드의 형태로 저장하고 노드간의 흐름 또는 관계를 저장할 수 있습니다. 

- Wide-column 모델 : 한 행마다 각각 다른 수, 다른 종류의 열을 가질 수 있습니다. (스키마가 자유로움) 

 

 

 

특징

1. Scaling이 쉽다는 장점이 있습니다. 

찰나의 순간에 대량의 데이터를 저장해야한다면 어떻게할까요? 

기존 올드한 관계형 데이터베이스는 확장이 매우 어렵습니다. 보통 scale up 이라는 방법으로 서버의 성능을 키워야합니다. 

하지만 대부분의 NoSQL 데이터베이스는 scale out이라는 방법으로 데이터를 분산저장하는 걸 기본적으로 지원합니다. 

그래서 대량의 데이터를 빠르게 입출력해야한다면 보통 NoSQL이 제격입니다. 

(관계형 데이터베이스도 잘 셋팅하면 분산저장 대충 잘합니다)

 

2. 대부분 다루기가 쉽습니다. 

SQL 이라는 언어를 새로 배우지 않아도 데이터를 쉽게 입출력할 수 있습니다. 

자바스크립트 object{} 자료형 다루듯이 데이터를 입출력할 수 있으니 사용자에게 매우 편리하죠. 

그리고 여러분이 서버에서 쓰던 프로그래밍 언어로 DB를 다룰 수 있다는 장점이 있습니다. MongoDB도 그러고 있죠?

 

3. 대부분 스키마 정의 없이도 쉽게 쓸 수 있습니다. (이 열의 데이터는 정수입니다~ 라고 표현하는 짓거리 안해도 됨)

장점이자 단점일 수 있습니다. 그래서 MongoDB에선 스키마를 미리 정의하기 위한 Mongoose같은 라이브러리를 추가해서 사용하기도 합니다. 

 

4.  NoSQL 데이터베이스는 기본적으로 SQL에서의 JOIN 연산을 적용하는게 기본적으로 어렵습니다. 

서버 단에서 JOIN 연산을 쉽게 처리해주는 라이브러리를 이용합니다.

이건 뭔지 모르면 스킵합시다. 

 

 

 

 

 

 

아까 relational 데이터베이스의 문제도 나름 쉽게 해결할 수 있습니다. 

 

 

▲ 여기서 손흥민 선생님이 가르치는 과목이 수학, 영어 이렇게 2개로 늘어나야하면 어떻게 코드를 짜야할까요? 

NoSQL의 대표 주자인 MongoDB에선 그냥 ['수학', '영어'] 이걸 array로 만들어서 저 자리에 그냥 집어넣으시면 됩니다. 

얘는 DB에 array, object 집어넣는건 자유니까요. 

 

 

 

 

물론 MongoDB에서도 Relational Database처럼 관계를 표현해 저장하기도 합니다.

 

뭐 예를 들어서 게시물을 만들었는데

거기 달린 댓글도 저장해야한다고 칩시다. 

그럼 게시물 document 안에 댓글란도 만들면 되겠네요? 

 

 

▲ 편의상 엑셀로 표현해봤습니다. (가로줄 하나가 document 하나입니다)

array 자료 쓸 수 있다니까 이렇게 써본 것입니다. 훌륭합니다. 

하지만 게시물 하나가 댓글이 1억개가 되면 문제가 생깁니다. 

한 게시물에 댓글 1억개를 어떻게 array에 저장할 것임 

(실은 MongoDB document 하나의 최대 용량이 16mb 라서요)

 

 

 

 

 

▲ 이렇게 만드는건 어떨까요. 

댓글용 collection (table)을 하나 더 만들었습니다.

거긴 댓글을 전부 밀어넣어두는 곳인데 어떤 게시물에 달린 댓글인지 부모 게시물 번호도 함께 저장했습니다.

그럼 나중에 0번 게시물 + 댓글을 불러오고 싶으면 

1. 우선 0번 게시물 불러오고

2. 부모게시물번호가 0인 댓글도 전부 찾아오면 되는 것입니다.

뭔가 1억개 중에 번호 0을 가진 댓글을 찾아야하니 오래걸릴 것 같지만 DB는 검색 빨리빨리 잘해줍니다.

아무튼 MongoDB도 이런 식으로 관계형스럽게 개발하면 편리할 수 있습니다.

 

 

 

 

 

 

 

두 데이터베이스가 공존하는 이유는 바로 각각의 명확한 장점 때문입니다. 

정규화된 데이터와 안정성이 필요하다면 관계형 데이터베이스를 사용합니다. 

금융서비스를 만든다, 은행 전산시스템을 만든다면 당연히 안정적인 관계형이 최고입니다.

 

하지만 일초에 수백만개의 데이터 입출력 요청이들어오는 SNS 서비스를 만들 때,

뭔가 서비스의 변경사항이 잦아서 쉽고 유연하게 데이터를 저장하고 싶으면 NoSQL을 사용합니다. 

실제로 Facebook은 이런 대량의 데이터를 저장하기 위해 HBase 데이터베이스를 이용해 분산저장합니다. 

 

 

 

 

 

요즘은 블록체인같은 새로운 형태의 데이터 저장 방법들이 등장하고 있습니다. 

블록체인이 뭐냐면..

여러분이 멋진 음반을 하나 발표했다고 칩시다. 그래서 멜론, Vibe 이런 곳에 음원을 판매등록했습니다. 

그래서 멜론에서 이번달엔 500회 재생했습니다~ 라는 기록에 따라 저작권료를 정산받습니다.

하지만 멜론같은 스트리밍 사이트의 음원 재생기록을 믿을 수 있겠습니까?

멜론 CEO 입장에서 멜론의 DB를 조작한다면 정산금액을 일부러 낮추어 비용을 줄일 수도 있잖아요? 

 

 

그래서 블록체인이라는 거래장부 저장형식이 등장합니다. 

전세계 모든 사람이 거래내역을 저장하고 관리해줄 수 있습니다. 

관리해주는 대가로 비트코인을 지급받고요.  

블록체인 장부를 살펴보면 A가 B에게 1코인을 지급했다~ 라는 내용이 전부입니다. 물론 A의 정보는 암호화되어있고요. 

덕분에 거래내역의 투명성과 익명성과 공정성을 보장해줍니다. 

여러분이 많이 들어본 이더리움, 비트코인이 그런 장부를 사용하고 있습니다.

 

 

지금은 처리시간, 스케일링, 수수료 문제 등 특유의 비효율성 때문에 실용화되진 못하고 있지만

언젠가는 효율적인 블록체인 장부저장 시스템도 실생활에서 구경해볼 수 있을 것입니다