NoSQL(Not Only SQL)
-
질의 명령어가 SQL이 아니다
-
정보의 형식을 미리 정하지 않는다
mySQL 이라면 schema를 먼저 정의해서 해당 데이터만을 넣을 수 있지만, mongodb 에서는 사전 정의 없다. -
전통적인 관계형 데이터베이스(RDBMS)보다 덜 제한적인 일관성 모델을 제공하는 DB
배경
-
전통적인 RDBMS의 규칙(안정성, 범용성 중심)
- ACID 원칙을 준수
- 2차원의 테이블 형태
- SQL을 통한 질의
- MySQL, postgreSQL, ORACLE
-
서버에 요구되는 정보처리량이 점점 증가하며 이 처리량을 늘리기 위해 기존 규칙을 파괴했다(확장성, 유연성 중심)
- 특정 기능에 대해서는 RDBMS 규칙이 비효율적이었다(캐싱, 전문검색 등)
- 초반의 테이블 설계없이 데이터를 저장할 수 있다
- mongoDB, redis, elasticsearch
분산 컴퓨팅
-
복제: 복사하여 저장하는 방식
클라이언트가 데이터를 입력했을 때 자식(복제 서버)에게 복사하여 그대로 다시 저장한다. 그리하여 서버가 불안정하거나 문제가 생겼을 때 대처할 수 있도록 안정성을 확보한다.
(원본 서버가 망가져도 정상적으로 서비스를 운영할 수 있다) -
샤딩: 나누어 저장하는 방식
예를 들어 100개의 데이터를 저장해야할 때, 여러 서버에 각각 20개씩 분산하여 저장한다. 이렇게 나누면 서버 하나의 성능보다 여러 서버를 활용해 효율성과 성능을 향상시키려 한다. -
주의점: 만약 단일 DBMS(서버 하나)에서 쓰기 작업을 하는 도중에 서버가 꺼진다면?
mongoDB 경우, 데이터가 완전하지 않거나 유실될 수 있다. 왜냐하면 분산 컴퓨팅을 가정하고 데이터를 다루기 때문에 단일 서버 환경에서 문제가 생기면 의도하지 않은 상태로 정보가 저장될 수 있기 때문이다.
MySQL과 같은 RDBMS 경우, 엄격한 데이터 관리 규칙을 적용하기 때문에 완전하지 않은 상태로 데이터를 저장하지 않는다.
이런 점에서 NoSQL은 안정성 문제를 지니고 있다.
Why Javascript
- 기존의 RDBMS 내부 명령어는 SQL, 이와 다르게 mongoDB 내부 명령어는 Javascript
- Node.js 와 더불어 서버와 데이터 영역의 진입장벽을 낮추었다
- JSON(Javascript Object Notation) 과 유사한 BSON 이라는 구조로 정보 저장
활용
- 유저의 규모를 예측할 수 없는 경우
- 데이터 구조를 정의하기 어렵고 쉽게 바뀔 수 있는 경우
- 비정형화된 정보가 많은 경우
- 안정성보다 성능이 중요한 경우
활용하면 안될 때
- 안정성과 무결성이 중요한 경우(결제, 예약 등)
- 복잡한 쿼리가 빈번하여 SQL의 함수가 자주 필요한 경우
