이제 다음 주면 프로젝트 시작이다.
프론트, 백 어떤 걸 하든 상관 없긴하나 백앤드를 해보고 싶긴 하다.
(둘 다 자신이 없어서 뭘 하든 상관 없다는 뜻.🤯)
백앤드 프로젝트 경험이 있다면 프론트 개발자가 되더라도 백이랑 협업하기 좀 더 원활할 것 같기 때문이다.
프론트를 한다 하더라도 나중에 백앤드 경험을 또 쌓으면 되니 크게 신경쓰진 않기로 했다.
DB의 종류와 특징에 대해 한번 짚어보고 가자.
현재 웹서비스 개발시 관계형 데이터베이스, NoSQL 데이터베이스를 주로 이용한다고 한다.
둘에 대해 좀 더 자세히 알아보자.
80년대부터 유행하기 시작해 아직까지 많이 사용중이기 때문에 데이터베이스의 표준이라 할 수 있다.
짧게 요약하자면 엑셀처럼 행과 열로 데이터를 저장할 수 있는 데이터베이스를 뜻한다.
엑셀의 시트처럼 생긴 테이블이라고 부르는 공간을 생성 후 행과 열에 맞춰 데이터를 저장한다.
생긴 것도 엑셀과 유사하다.
거의 모든 곳에 사용 가능해 범용적이다.
구조화된 데이터를 저장하기 가장 좋다.
보통 SQL이라는 언어를 이용해 데이터를 입출력 한다.
"이 열엔 숫자가 들어온다" 라고 스키마를 미리 정하기 때문에 관리가 쉽다.
구조화된 데이터 덕분에 원하는 데이터를 뽑기 쉽다.
트랜잭션 롤백 이런 기능을 이용해 데이터의 무결성을 보존하기 쉽기 때문에 금융, 거래 서비스에 필수적이다.
데이터들 간의 관계를 정해서 데이터를 저장할 수 있다는 뜻이다.
군대에서 병사들의 각종 정보를 DB에 저장하려고 한다.
군인마다 각자 병과를 위처럼 저장할 수 있다.
그럴 일은 없겠지만? 담당하는 업무가 많아지면 어떻게 저장하면 좋을까?
이런식으로 테이블을 하나 더 만들어서 왼쪽엔 군인을 관리하는 테이블, 오른쪽에는 병과를 관리하는 테이블을 만드는 것이다. 그리고 병과마다 병과 번호를 부여해서 어떤 병사가 담당하고 있는지 관계를 지어주었다.
이게 관계형 데이터베이스의 특징이며 구축방법이다.
용어는 약간 범용적이다. SQL문 없이도 사용할 수 있는 데이터베이스라 보면 된다.
대부분이 테이블에 국한되지 않고 자유로운 형식으로 데이터를 쉽게 분산저장할 수 있다.
key-value 모델 : Object, JSON 자료형 형식으로 데이터를 쉽게 저장, 출력이 가능하다.
Document 모델 : 테이블 대신 Collection이라는 문서 기반으로 데이터를 분류하고 저장한다. 테이블보다 유연하다.
(MongoDB도 key-value, Document 모델 저장방식을 차용 중이다.)
Graph 모델 : 데이터를 노드 형태로 저장하고 노드간의 흐름 또는 관계를 저장할 수 있다.
Wide-column 모델 : 한 행마다 각각 다른 수, 다른 종류의 열을 가질 수 있다.(스키마가 자유롭다.)
스케일링이 쉽다.
갑자기 대량의 데이터를 저장해야한다면 관계형 데이터 베이스는 확장이 매우 어렵다.
scale up 이라는 방법으로 서버의 성능을 키워야한다.
하지만 NoSQL 데이터베이스는 scale out이라는 방법으로 데이터를 분산저장하는 걸 기본적으로 지원한다.
때문에 대량의 데이터를 빠르게 입출력할 때 NoSQL이 좋다.
다루기가 쉽다.
SQL이라는 언어를 새로 배우지 않더라도 데이터를 쉽게 입출력 가능하다.
자바스크립트 object 자료형 다루듯 데이터를 입출력이 가능하기 때문이다.
그리고 서버에서 사용하던 프로그래밍 언어로 DB를 다룰 수 있다.(MongoDB 처럼)
대부분이 스키마 정의 없이 쉽게 쓸 수 있다.
n열의 데이터는 정수입니다~ 라고 표현할 필요가 없다. 이것은 장점이자 단점일 수 있기 때문에 MongoDB에서는 스키마를 미리 정의하기 위해 Mongoose같은 라이브러리를 사용하기도 한다.
SQL 데이터베이스 문제도 쉽게 해결 가능하다.
여기서 담당하는 업무가 늘어날 경우 MongoDB에서는 ['통신병','행정병'] 이걸 array로 만들어 저 자리에 집어넣으면 된다.
두 데이터베이스가 공존하는 이유는 장점이 확실하기 때문이다.
정규화된 데이터와 안정성이 필요할 경우 관계형 데이터 베이스를 사용하고(금융, 은행 전산시스템),
SNS처럼 초당 수백만개의 데이터 입출력이 들어오는 경우 NoSQL을 사용한다.
엘리스 화이팅!