데이터베이스란?

간단히 말하면, 데이터베이스는 데이터의 모음이다. 일정한 규칙을 통해 구조화 되어 있어서 정보를 효율적으로 검색하거나 수정 등 쉽게 관리할 수 있다.

데이터베이스는 크게 관계형 데이터베이스와 비관계형 데이터베이스로 구분할 수 있다.

관계형 데이터베이스(RDB, Relational DataBase)

관계형 데이터베이스(RDB)는 테이블 간의 관계를 기반으로 데이터를 구조화하고 저장하는 데이터베이스를 의미한다. RDB의 데이터는 테이블이라는 2차원 구조로 구성된다. 각 행은 레코드(OR 튜플), 각 열은 속성(OR 필드)로 나타내고, 테이블간의 관계는 키(Key)로 정의할 수 있다. 또한, 테이블간에는 상호 관련성을 가질 수 있다. 이를 위해 외래키를 사용한다.

이러한 데이터베이스를 관리하기 위한 관계형 데이터베이스 시스템(RDBMS, Relational DataBase Management System)은 대표적으로 Oracle, MySQL, PostgreSQL 등이 있다.

혼동하면 안되는 것이 RDB와 RDBMS는 다르다.
RDB는 관계형 데이터베이스이고, RDBMS는 RDB를 관리할 수 있는 소프트웨어를 말한다.

관계형 데이터베이스 용어

테이블(Table)

데이터를 저장하는 기본 단위이다. 하나의 데이터베이스에는 여러개의 테이블로 구성된다. 2차원 행렬 전체가 하나의 테이블이다.

행(튜플, 레코드)

튜플 또는 레코드라고 불리는데

name, age 라는 속성이 있을 때 "홍길동", 12가 하나의 행이고 실제 데이터가 되는 것이다.

열(컬럼, 속성)

데이터의 속성을 의미한다. 예를 들어, 고객 테이블에서 name과 age가 속성이 된다.

기본키(Primary Key)

각 행을 고유하게 식별하는 데 사용되는 데이터베이스의 제약조건이다. 기본키는 중복되지 않으며 NULL값을 허용하지 않는다.

외래키(Foreign Key)

다른 테이블의 기본 키를 참조하는 속성이다. 외래키로 서로 다른 테이블끼리 Join연산을 수행해서 필요한 데이터를 한 곳에 모을 수 있다.

회원테이블의 name과 주소테이블의 address 속성이 필요하다면, 회원테이블의 pk와 주소테이블의 회원fk로 Join연산을 수행하면 된다.

SQL(Structured Query Language)

Structured Query Language 즉, 엄격한 스키마를 갖는다. SQL은 데이터베이스 자체를 의미하는 것이 아니라, 특정 유형의 데이터베이스(주로 RDB)와 상호작용을 위해 사용하는 쿼리 언어이다. 결국 RDB에서 데이터는 테이블에 레코드로 저장되며 각 테이블에는 명확하게 정의된 구조가 있다.

관계형 데이터베이스는 스키마와 맞지 않는 형식의 데이터는 저장할 수 없다. 이는 다른 구조의 데이터를 얼마든지 추가할 수 있는 NoSQL과는 상반된다.

name, age로 정의된 속성이 있다고 하면 넣을 수 있는 데이터는 "홍길동", 12같은 형태만 가능하다.

어디서는 SQL을 RDB랑 같게 취급하기도 하던데 , 정확하게 SQL은 RDB를 다루기 위한 쿼리 언어이다. 둘의 차이점을 명심하자!

비관계형 데이터베이스(Non-Relational DataBase 또는 NoSQL)

NoSQL(Not Only SQL)은 유연한 데이터 구조와 수평 확장성을 갖춘 데이터베이스이다.

SQL은 엄격한 스키마를 갖는다고 했는데 No-SQL이라는 말을 보면 느슨한 스키마를 갖는다는걸 추측할 수 있다. 즉, NoSQL은 다른 구조의 데이터를 추가할 수 있는 유연한 구조로 되어있다. 결국 RDB는 엄격한 데이터 구조를 지켜야하고, NoSQL은 어떤 구조로 되어있든 저장할 수 있다.

RDB와 문서 구조를 갖는 NoSQL을 비교하자면 이렇다.

NoSQL은 데이터의 구조와 스키마에 대해서 유연성을 갖기 위해 문서(Document), 키-값(Key-Value) 등과 같은 다양한 모델로 설계되어 있다. 문서 구조를 가지는 모델은 MongoDB가 있고, 키-값 구조를 가지는 모델은 Redis가 있다.

NoSQL의 장단점은 뭘까?

장점

NoSQL은 느슨한 스키마 구조를 갖는다했는데, 사실 스키마라는 개념이 없다. 즉, 스키마가 없기 때문에 유연한 구조를 가지며 언제든지 새로운 필드를 추가할 수 있다.

MongoDB로 예를 들면, 컬렉션(Collection)에는 스키마가 정의되어 있지 않기 때문에name : "홍길동", age: 12 를 넣고, name : "장발장", age: 20, address: "서울" 를 넣어도 상관없다.

또한, 다큐먼트 모델의 MongoDB에서는 데이터가 애플리케이션이 필요로 하는 Bson(Binary JSON) 형식으로 저장되기 때문에, 데이터를 읽어오는 속도가 빠르다. 키-값 모델도 해시테이블(Hash Table) 구조로 되어있기 때문에 읽는 속도가 빠르긴 하다.

수직적 확장, 수평적 확장이 가능하기 때문에 애플리케이션이 발생시키는 모든 읽기/쓰기 요청을 처리할 수 있다. 여기서 수직적 확장은 서버의 개수를 늘리는 것이고 수평적 확장은 서버의 부품을 좋은걸로 바꾸는 것이다.(CPU 성능을좋게 하든지, 다다익램이라든지)

RDB도 수평확장이 가능하긴 하지만 이 부분은 다른 포스팅에서 자세히 다뤄보겠다.

단점

제약조건이라던지, 테이블간의 관계가 없기 때문에 데이터의 정합성이 깨질 수 있다. 이름을 홍길동에서 장발장으로 바꾸면 홍길동으로 사용하고 있을때 저장된 데이터가 있을것이고, 장발장으로 바꾸고 저장된 데이터가 있을건데, 이러면 서로 맞지 않는다.

NoSQL은 수정에 불리하다. NoSQL은 이미 필요한 모든것을 포함한 데이터가 저장되기 때문에 데이터의 중복이 생길 수 있다. RDB에서는 데이터의 중복을 피하고 정합성을 보장하기 위해 정규화를 수행하지만, NoSQL은 그런게 없다. 그래서 중복이 발생할 수 있고 중복이 발생한다는 것은 수정할 때 정합성을 맞추기 위해 모든 컬렉션을 수정해야 한다는 의미이다. 이는 비용이 많이 발생한다.

그럼 언제 어떤걸 써야하는데?

RDB는 이럴때 사용하면 좋다.

• 데이터가 자주 변경될 경우
• 테이블간의 관계가 중요하고 복잡한 조인 연산이 필요할 경우
• 엄격한 스키마의 구조를 가지는 데이터를 저장할 경우

NoSQL은 이럴때 사용하면 좋다.

• 데이터의 구조가 정해져있지 않거나 변경 또는 확장될 수 있는 경우
• Read연산은 많고 Wirte연산은 적으면
• 데이터베이스를 수평적으로 확장해야 할 경우

이것 외에 다양한 경우가 있지만 RDB와 NoSQL의 특성을 비교해가며 현재 상황에 맞게 사용하면 된다. 나는 프로젝트에서 TTL로 스케줄링 비용을 감소시키기 위한 목적으로 NoSQL을 채택한적도 있기 때문에 비교해보고 더 적합하다고 판단되는 것을 사용하자