예전에 database라는 것은 mysql, mariadb, mssql등 관계형 데이터베이스들을 많이 사용하였으나 근래에는 mongodb, supabase 등 nosql들이 유행을 하고 있어 왜 nosql을 쓰는 것을 좋아하는지 알아보자
데이터베이스란?
데이터베이스란 일반적으로 컴퓨터 시스템에 전자적으로 저장되는 구조화된 정보 또는 데이터의 조직화된 모음이며, 이 데이터를 관리하기 위해서 DBMS(데이터베이스 관리 시스템)을 사용해서 관리하게 되며, 이 DBMS를 통해 데이터를 조작, 열람하기 위한 명령어를 SQL이라고 한다.
RDB
일명 관계형 데이터베이스라고 부르며, 관계형 모델을 기반으로 하며, 정해진 스키마 형식에 따라 테이블 형식으로 구성되어 row, column을 가진 데이터 구조여서 정해진 값들만 넣고 관계를 통해 특정 값들을 여러 테이블에 나눠서 관리한다.
다른 테이블과의 연결은 foreign key라는 참조 키를 기반으로 특정 테이블끼리의 연결 id를 관리해 테이블 연결을 한다.
장점
- 스키마 정의가 명확하게 되어있다.
- 어떤 데이터가 어떤 역할인지와 어떻게 설계되어있는지 구조를 보기 쉽다.
- 데이터 무결성을 보장한다.
- 각 데이터를 중복 없이 한번만 저장한다.
단점
- 유연성이 떨어져 데이터 스키마를 사전에 계획하고 만들어야하고 추후 수정이 많이 복잡하다.
- DB 설계를 잘못하면 추후 마이그레이션을 위해 플랜, 새로운 DB 테이블 설계 등 해야할 작업들이 많아 매우 불편하다.
- 관계형 DB는 테이블 간의 연결들이 많아 간혹 JOIN문이 매우 많은 복잡한 쿼리가 만들어질 수 있다.
- 대체로 수직적인 확장만 가능하다.
- 수평적인 확장도 불가능하지는 않으나 데이터 동기화가 복잡하고 성능 저하 문제 발생의 가능성이 있다.
NoSQL
RDB와는 반대로 비 관계형 데이터베이스로 관계형 DB를 제외한 나머지를 전부 비 관계형 데이터베이스라고 부른다.
비 관계형 데이터베이스는 애플리케이션이 보다 보편화되고 복잡해지면서 주목받고 있는 기술이기도 하다.
NoSQL의 데이터베이스는 테이블 형식이 아닌 다른 방식으로 저장하는데, 다양한 유형으로 저장이 가능하고 대표적으로 document, (key, value) 형식, 그래프 등으로 저장한다.
NoSQL이라고 해서 꼭 스키마가 없는 것은 아니고 유연한 스키마를 제공하고 대용량 데이터와 높은 사용자 부하 환경에서도 확장이 매우 쉽다라는 것이 장점이며 데이터를 읽어올 때 스키마에 따라 데이터를 읽어온다.
- Scheme (스키마)
- 데이터의 구조 혹은 설계를 의미한다.
장점
- 스키마가 따로 없어 유연하고 언제든지 저장된 데이터를 조정하고 필드를 추가하기 편하다
- 애플리케이션이 필요로 하는 형식으로 저장되어 읽어오는 속도가 빨라진다.
- 수직, 수평 확장에도 유리해 애플리케이션이 발생시키는 모든 읽기와 쓰기 요청 처리가 가능하고 쉽다.
수직 확장 (Scale Up)
하나의 서버에 더 많은 CPU, 메모리, 스토리지 등 즉 서버 자체의 스펙을 추가해 성능을 향상시키는 방식
구현이 간단하고 다른 서버와의 동기화 작업이 없어 데이터 일관성을 유지하기 편하나 확장에 한계가 있고 비용이 많이들 수 있다.
수평 확장 (Scale Out)
여러 서버에 데이터를 분산해 처리함으로써 성능을 향상시키는 방식
확장성이 높고 효율적으로 비용 관리가 가능하나 구현이 복잡하고, 데이터 일관성을 유지하기 어려워 많은 작업을 필요로 한다.
단점
- 유연성으로 인해 데이터 구조 결정을 미루고 마구잡이로 추가하기도 쉽다.
- 규칙이 깨져 난잡한 데이터 구조가 될 수 있음.
- 데이터 중복에 대한 업데이트가 필요하다
- 데이터가 여러 컬렉션에 중복되어 있을 수 있어 수정이 필요하다면 모든 컬렉션을 대상으로 비교, 수정이 필요하다.
선택 기준?
RDBMS와 NoSQL은 각각의 특징이 명확하고 장단점 또한 명확하다.
그래서 각각의 상황에 따라 DB를 선정하고 관리해주면 좋을 것 같다.
RDBMS 사용 시
- 데이터베이스의 ACID 원칙을 준수해야할 때
- 데이터베이스에 들어가는 데이터의 원자성, 일관성, 격리성, 지속성의 원칙을 지켜가면서 보관해야하는 데이터의 경우는 RDB
- 관계 데이터가 자주 변경되는 경우
- 관계 테이블의 데이터가 자주 변하는 경우라면 RDBMS를 써서 관리해주는 것이 불필요한 컬렉션 비교, 수정이 필요하지 않아 좋음
- 명확한 스키마가 사용자와 데이터에게 중요한 경우
- 결제나 코어 시스템 처럼 데이터의 동기화 및 최신화가 잘 되어 있어야함. (즉 정확성이 중요한 데이터)
NoSQL 사용 시
- 정확한 데이터 구조를 알 수 없거나 변경, 확장될 가능성이 있는 경우
- 크롤링한 데이터도 이에 해당될 수 있고, 자주 스키마가 변할 수 있는 데이터
- 데이터의 정확도보다 읽기가 중요하고 데이터 변경이 자주 없는 데이터, 많은 양의 데이터의 경우
- 로그성 데이터, 잘 안변하는 특정 프로덕트의 수많은 정보의 저장
