DB 선택
특징
- 데이터는 정해진 스키마에 따라 테이블에 저장된다.
- 데이터는 관계를 통해 여러 테이블에 분산된다.
- 스키마를 준수하지 않은 레코드는 테이블에 추가할 수 없다.
- 데이터의 중복을 피하기 위해 관계를 이용한다.
장점
- 데이터의 분류, 정렬, 탐색 속도가 빠르다.
- 오랫동안 사용된 만큼 신뢰성이 높고, 데이터의 무결성을 보장한다.
- 관계형 데이터베이스들은 같은 오픈 소스를 공유하는 경우가 많기 때문에 다른 개발 환경에서도 쉽게 적응할 수 있다.
단점
- 관계를 맺고 있어서 JOIN이 많은 복잡한 쿼리가 만들어질 수 있다.
- 수평적 확장이 어렵고, 수직적 확장만 가능하므로 데이터 처리량 성장에 한계가 있다.
- 기존에 작성된 스키마를 수정하기 어렵다.
- 대량의 데이터를 다루는데 비효율적이다.
특징
- 스키마도 없고, 관계도 없다.
- 레코드 → 문서, 테이블 → 컬렉션
장점
- 스키마가 없어 유연하기 때문에 언제든지 저장한 데이터를 조정할 수 있다.
- 다양한 가변성 있는 데이터의 저장이 쉽다.
- 데이터를 읽어오는 속도가 빠르다.
- 수직 및 수평적 확장이 모두 가능하므로 애플리케이션에서 발생하는 모든 읽기, 쓰기 요청의 처리가 가능하다.
단점
- 유연성으로 인한 데이터 구조 결정이 어려울 수 있다.
- NoSQL마다 쿼리 언어를 다르게 사용하는 경우가 많아 이식성이 낮다.
- 데이터가 여러 컬렉션에 중복된다면 수정 시 모든 컬렉션에서 수행해야 한다.
- 명확한 스키마가 중요한 경우 →
SQL - 관계를 맺고 있는 데이터가 자주 변경될 경우 →
SQL - 정확한 데이터 구조를 알 수 없거나 변경, 확장될 수 있는 경우 →
NoSQL - 데이터를 자주 읽어오지만, 변경되지 않는 경우 →
NoSQL - 많은 양의 데이터를 다뤄야 하고 수평적 확장이 필요한 경우 →
NoSQL
- 우리에게 익숙하다.
- 실무에서도 많이 쓰인다.
- 우리는 명확한 스키마가 중요하다.
| MySQL | Oracle | PostgreSQL | |
|---|---|---|---|
| 비용 | 무료 (상업은 유료) | 유료 | 무료 |
| 장점 | 무료로 사용이 가능, 속도와 성능이 모두 일반적인 수준을 만족, update 성능이 potgresql보다 우수 |
성능이 좋음, 고성능 트랜잭션 처리를 제공 |
무료로 사용이 가능, 다양한 join 방법을 제공, 신뢰성과 안정성 높음, 데이터베이스 클러스터 백업 기능 제공 |
| 단점 | 복잡한 쿼리는 성능 저하 | 비쌈 | update 쿼리가 느리다 (행을 삭제 후 추가) |
| 이용 사례 | 구글, 링크드인, 아마존, 넷플릭스, 트위터 등 | 금융권 대기업, 삼성, 롯데, zoom 등 | 인스타그램, CISCO, 스카이프, 트립어드바이저, 이케아 등 |
- Oracle은 유료이므로 MySQL과 PostgreSQL 중에 고를 것
- 복잡한 쿼리를 요구하고, insert 위주의 대규모 서비스인 경우에는 PostgreSQL이 적합
- update가 빈번하고, 간단한 동작을 구현하는 서비스는 MySQL이 적합
- 무료다.
- 관련 자료가 가장 많다.
대표적인 In-Memory DB
인메모리란? 메인 메모리인 RAM에 데이터를 올려서 사용하는 방법, 빠른 속도가 장점
-
Key-Value 형식으로 데이터를 저장
→ RDB와 같이 쿼리 연산을 지원하지 않지만, 데이터의 고속 읽기와 쓰기에 최적화
-
memory 특성 때문에 데이터가 휘발성, I/O 속도가 매우 빠름
-
상대적으로 다룰 수 있는 용량의 크기가 제한적임
-
싱글 스레드로 동작 → 동시에 처리할 수 있는 명령어의 개수가 한 번에 하나
-
인증 토큰 저장 (Strings or Hash)
-
조회수와 같이 I/O가 빈번한 데이터의 관리
-
즉시 메세지를 주고 받아야 할 때 (메세지 큐잉)
-
장바구니 삭제
-
Twitter의 타임라인
타임라인 : 팔로우하는 유저들의 최근 트윗을 확인할 수 있는 페이지
15만명이 넘는 실시간 활동 유저와 초당 30만 건이 넘는 타임라인 요청이 발생, 이런 규모의 요청을 DB에 직접 접근하는 방식으로 처리하면 쿼리가 복잡해짐에 따라 속도가 현저히 떨어짐
이를 해결하기 위해 Redis 사용!
→ 트위터의 redis cluster는 각 유저의 타임라인에 노출될 트윗의 정보(트윗 id, 작성자 id)를 List 형태로 약 800개 정도 캐싱함
→ 발생하는 타임라인 요청은 바로 DB에 접근하지 않고 redis에 캐싱된 타임라인 정보를 먼저 가져와서, 이를 토대로 Query를 단순화하여 DB에 접근하여 처리
- 어디에 쓸지는 명세서가 나온 후에 좀 더 의논해보자.
- 후보 : 인증 토큰, 조회수