SQL - 관계형 데이터 베이스
구조
- 테이블
- 행과 열로 이루어진 테이블
- 제약
- 각 컬럼에 어떤 형태의 값이 올지 미리 규정하여 하며, 규정하면 그 형태 외에는 올 수 없음
- 데이터의 무결성 보장
- 관계형
- 테이블 간 관계를 형성하여, 유연한 query를 작성할 수 있음
저장
- 주로 한 곳에 저장 되어 있음 (비 분산)
확장성
- 수직
- CPU, RAM, 하드 디스크 등 성능 개선을 통하여 서버 개선이 가능함
- 수평
- Read Replica를 통해 달성
- Read Replica: 데이터 베이스의 복제 판
- 주 데이터 베이스에 과부하가 걸리면 복제 데이터 베이스를 통해서 읽기 가능
접근
- SQL은 언어가 유사
NoSQL - 관계형이 아닌 데이터 베이스
- 다양한 구현체
- 고성능
- 덜 유여한 쿼리문
구조
- 구현제에 따라 다름
- 도큐먼트, 컬럼, 그래프 등
- 보통 딕션더리처럼 key-value 형태를 뜀
저장
- 분산하여 저장 가능
확장성
- 수평
- 파티션 추가 가능
- 메모리, CPU, 저장공간 추가 가능
접근
- REST API
- 각 구현체마다 언어가 다름
- MongoDB랑 DynamoDB랑 언어가 다름
NoSQL 종류
Document Store
- MongoDB
- JSON 형태로 저장
- 계층적 구조
- 유연하게 형태를 가질 수 있음
Key-Value DB
- Dynamo DB
- 서버리스, 분산형, key-value database
- 아마존이 만듬
- 초당 24,000개 읽기 지원 등 읽고, 쓰기를 많이 해야 하는 경우 유용함
- 디즈니, 드롭박스, 줌
- 가장 간단한 구조의 NoSQL
Column Store Database
- Cassandra DB
- 애플, 넷플릭스, 페이스북 등 사용. 엄청 빠르게 데이터를 읽고, 쓸 수 있음. 10petabyte정도 저장
Graph Database
- TAO (made by Facebook), neo4j
- Facebook, Instagram
- 컬럼과 도큐먼트는 필요 없으나, 각 노드 간의 관계를 알아야 할 때 씀
언제 SQL 또는 NoSQL를 써야 하나?
정리하자면!
평범한 프로젝트는 SQL
시작은 SQL, 나중에 필요에 따라 NoSQL
인스타그램도 PostgreSQL로 시작한 다음 Graph Database로 넘어감.
공통적으로 하는 이야기가 작은 프로젝트는 SQL를 써라고 하는데 우리는 왜 1, 2차 프로젝트 때 NoSQL를 썼나?
엄밀히 말하면 우리는 NoSQL의 도큐먼트 방식인 MongoDB를 썼다.
MongoDB의 장점
- 개발자들이 구조화 또는 비 구조화 된 데이터를 저장하기 쉽게 함
- JSON 포맷을 사용하기 때문에 대부분의 프로그래밍 언어에서 바로 맵핑을 할 수 있음 (쓰기 편하다는 뜻임)
- 정규화를 신경 안 써도 됨
- 대용량을 처리할 수 있음
- 수직 또는 수평적으로 확장 가능함
한마디로 요약학면 MongoDB는 빠르게 변화하고 "우아하게" 확장 해야 하는 인터넷/비즈니스 앱을 만드는 사람들을 위해 만들어졌음.
뇌피셜: 우리가 1, 2차 프로젝트 때 Mongo DB를 쓴 이유는 관계형에 대해서 신경 안 써도 되고, 구조를 미리 안 정해도 되어서 였음.
면접 때 SQL과 NOSQL이 아닌, SQL과 NoSQL의 MongoDB의 차이점을 이야기 해야 되지 않나 싶음.
참고자료:
https://www.youtube.com/watch?v=Q_9cFgzZr8Q
https://www.youtube.com/watch?v=ruz-vK8IesE
https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/relational-vs-nosql-data
https://www.mongodb.com/why-use-mongodb