언제 관계형 데이터베이스 이외의 것을 사용해야 할까?

일반적으로 우리가 만드는 시스템은 아마도 RDB만 써도 충분히 잘 동작할 것이다.

하지만 특정 시점에는 RDB에서 더 나은 성능을 가진 DB(NOSQL)로 넘어갈 필요가 있다.

 

구조적 현상으로는

1. 테이블이 점점 비정규화가 되어가고 Column수가 늘어나며 Table과 관련도가 떨어진 Column이 점점 추가될떄.

2. 하나의 Column에 JSON, yml, xml 등 구조화된 데이터를 점점 넣기 시작할떄

3. 데이터를 가져오기 위해 많은 조인을 해야하며 재귀적 커리가 늘어날때

4. 스키마의 변경이 잦을 때

 

성능적 현상으로는

1. 쓰기 용량이 벅찰 때

2. 데이터 셋이 너무 커서 하나의 DB에 저장하지 못할 떄

3. 배치 작업이나 분석 쿼리가 트랜잭션의 작업에 부하를 줄때 

 

Non-Relational Datbases

1. Key-value store :hashing index -> 빠른 검색 주로 Redis나 DynamoDb같은 메모리 DB에 사용 (캐싱, 세션) -> 낮은 지연 높은 처리율, 수평적 확장

2. Documented Databases: Json이나 Bson 같은 구조화된 데이터를 처리할 수 있고, 스키마가 유연하기 때문에 동적이고 변화가 잦은 개발에 알맞음 -> 주로 Mongodb -> 쿼리, 인덱싱 성능이 빠르고, 강력한 필터링 집계를 지원함

3. Column-Family Stores : 컬럼 단위로 데이터를 읽고 저장함, 필요한 Column만 골라서 쓰기때문에 쓰기 속도가 빠름 

이벤트 로그나, 시계열 데이터와 같은 고성능 쓰기 작업에 적합함.

4. Graph Databases: 컬럼간, 테이블간 관계가 복잡하게 연결되어있을 경우 사용

5. Distibuted Key-value Stores: 위와 같은 key-value store인데 자동으로 수평적 확장이 가능함 

 

MapReduce and Batch Processing

아주큰 배치작업일 경우 MapReduce 모델을 고려해봐야한다. 병렬적으로 많은 양을 처리할 수 있게한다.

하둡이나 스파크로 로그 분석, 머신러닝 등에 사용된다. 분할정복을 사용해서 성능을 높임, s3나 HDFS와 같은 Object storge에도 사용된다.

 

알맞은 데이터 베이스를 골라보자

1. 데이터 구조

데이터가 행렬에 알맞으면 RDB 사용하자

데이터가 계층적이고 나눠져있으며 서로 의존성이 크면 Documented, Graph Database를 고려해보자.

 

2. 수평적 확장 요구

RDB도 수평, 수직 확장은 가능하나 한계가 존재함

자동 스케일링이나 편한 스케일링을 위해서는 disributed stores를 고려해보자.

 

3. 쿼리 패턴

복잡한 데이터는 Graph Database가 적합하고

구저적인 데이터들을 쿼리용으로 만드는 DB는 Document Database가 적합하다.

 

정답은 없다. 팀의 상황 요구사항, 변화에 얼마나 유연히 대처할 수 있는지  등 잘 고려해서 선택 및 마이그레이션 해야할 것이다.