NoSQL 입문
NoSQL 개념과 특징
- NoSQL : Non-Relational Operational Database SQL. 또는 Not only SQL
- 마틴 파울러의 [NoSQL: 빅데이터 세상으로 떠나는 간결한 안내서]에는 NoSQL이 아래의 조건을 만족하는 데이터라 정의했다.
1. 대용량 웹 서비스를 위하여 만들어진 데이터 저장소
2. 관계형 데이터 모델을 지양하며 대량의 분산된 데이터를 저장하고 조회하는 데 특화된 저장소
3. 스키마 없이 사용 가능하거나 느슨한 스키마를 제공하는 저장소
NoSQL을 잘못 이해하면 스키마가 없는 DataModel 이라 이해할 수 있는데 그렇지 않다는 점을 집고 넘어가자. - NoSQL은 저마다 고유한 특징을 가진다. 하지만 일반적인 특징을 정의하고 넘어가자면,
읽기 작업보다 쓰기 작업이 더 빠르며, 일반적으로 RDBMS에 비하여 쓰기와 읽기 성능이 월등히 빠르다. - 잠시 주저리를 하자면, NoSQL은 제대로 알고 쓰지 못하면 성능 저하를 불러오고, 문제를 발생시킨다는 언급이 자주 눈에 띈다.
그런데 나의 꿈은 성능저하를 맞이 할만한 시스템을 만나 혼꾸녕 나며 배우는 것이 목적이다.
NoSQL 탄생배경
- NoSQL이 뭐시고 저시고 공부를 하다 문득 한가지 의문이 생겼다. RDBMS라는 확고한 Database 시스템이 존재하는데!!!!
왜???? 기존의 패러다임과는 너무나도 상반된 NoSQL 시스템이 나타난것인가?!!! 빅데이터 세상을 맞이함에 있어 구글과 같은 대규모 서비스 업체들은
관계형 데이터베이스 만으로 트래픽을 감당하기 어려워젔고, 이를 해결 하기 위한 결과로 NoSQL을 탄생시켰다.
NoSQL은 분산 환경에서 대용량의 데이터를 빠르게 처리하기 위해서 단점을 가진채 개발되었다.
NoSQL 분류
- NoSQL은 분류 방식에 따라 다르게 나누어진다. 이 글에서는 키에 저장된 값의 데이터 형식에 따라서 분류하겠다.
- 키-값 모델
- 키 값 모델의 가장 큰 특징은 단순한 저장구조를 갖으며, 복잡한 조회 연산을 지원하지 않는다.
- 저장되는 값을 단지 의미 없는 바이너리 데이터로 처리.
- 고속 읽기와 쓰기에 최적화된 경우가 많다.
- 키-값 모델 NoSQL 예 : Redis, Riak 등 키-값 모델의 특징을 고려해 볼때, 단일 연산에 처리할 수 있는 데이터들을 저장하는데 적합하다.
- 문서 모델
- 문서모델 NoSQL 은 하나의 키에 구조화된 문서를 저장하고 조회한다.
문서모델에서 의미하는 구조화된 문서란 가장 대표적으로 JSON이 있으며, XML과 같이 구조를 갖는 문서를 말한다. - 저장된 문서를 컬렉션으로 관리하고, 저장과 동시에 문서 ID에 대한 인덱스를 생성한다.
문서모델의 키는 문서에 대한 ID로 표현됨. - 키-값 및 컬럼 모델에 비하여 많은 종류의 기능을 제공하며, RBMS와 유사한 검색조건을 포함한 쿼리를 처리할 수 있다.
이러한 특징 덕분에 문서모델 NoSQL은 많은 인기를 얻고 있다. - 대부분의 문서 모델 NoSQL은 B트리 인덱스를 사용하여 2차 인덱스를 생성한다.
그러나 B트리는 크기가 커질수록 새로운 데이터를 입력하거나 삭제할때 성능이 떨어지게 된다.
이러한 이유로 B트리를 사용하는 문서 모델 NoSQL은 읽기와 쓰기 비율을 7:3 이상으로 유지할때 더 좋은 성능을 보인다.
결국 사용하는 문서 모델 NoSQL의 특징을 파악하고 사용하자. - B트리의 특성 떄문에 한 번 작성되면 자주 변하지 않는 정보를 저장하고 조회하는데 적합하며,
로그저장, 타임라인 저장, 채팅로그 기록이나 조회에 적합하다. - 문서 모델 NoSQL :
많은 인기를 얻고 있는 MongoDB 가 있으며,
NoSQL의 개념을 빠르게 잡고 MongoDB를 학습, 프로젝트를 진행할 예정이다.
여러분 함께해요~ - 그 밖의 모델
- 위 두가지 모델 이외에도 컬럼 모델 NoSQL, 그래프 모델 NoSQL 등이 있으나 필자의 능력을 벗어암으로 판단
다음 가장 중요한 파트라 생각되는 "언제 어떤 NoSQL을 사용해야 하는가?"로 넘어가겠다.
참여한 프로젝트의 경우는 자주검색되는 데이터를 Redis에 set하고,
RDBMS 조회전에 Redis를 먼저 바라봄으로서 검색속도를 비약적으로 개선했다.
결론, 하나의 서비스 요청에 단일 연산 처리로 대응할수 있는 시스템에 적합하다.
언제 어떤 NoSQL을 사용해야 하는가?
- NoSQL은 RDMS를 단순히 대체하기 위해 나온 시스템이아니다. 그렇기에 정확한 기본지식 없이 사용하면 많은 시행착오와 장애를 맞이하게 될 수 있다
- 대량의 단순 정보를 빠르게 저장하고 조회할 때, 관계형 데이터베이스가 처리하지 못하는 대량의 데이터를 입력할때
스키마가 고정되지 않은 데이터를 저장하고 조회할 떄 등이 이에 해당된다.
하지만 위와 같은 상황에서 무턱대고 아무 NoSQL을 적용한다면 큰 낭패를 보게 될 것이다.
결국 시스템의 상황을 고려하여, 서비스 특징에 맞는 적합한 NoSQL 저장소를 택하여야 한다.
NoSQL의 선택에 있어 고려해야 할 사항으로는 다음과 같다.- 일관성 모델 : 서비스에서 저장하려는 데이터가 어느 정도의 일관성이 필요한지 확인하여야한다.
- 데이터 모델 : 저장하려는 데이터가 키-값 모델과 같은 간단한 데이터 모델로 처리가 가능한지
또는 문서 모델과 같이 중첩된 구조를 지원해야 하는지 판단해야 한다. - 읽기 쓰기 성능 : 앞에서 말했듯이 읽기와 쓰기 비율에 따라서 적합한 NoSQL이 다르다.
빠른 응당시간이 필요하다면 인메모리 NoSQL이 적합하며,
상대적으로 읽기 비율이 높다면 문서-모델 NoSQL이 후보가 될 수 있다.
(듣던 중 반가운 소리!! 필자가 개발하는 서비스의 특성상 읽기의 비율이 높다.) - 원자성 지원 : 선택한 NoSQL의 트랜잭션 지원 여부, 단일 연산에 대한 연자성 지원 여부 등도 학인해야 한다. (이 부분은 확인 필요)
그렇다면 NoSQL 시스템을 서비스에 적용하기 위해서는 무엇이 필요할지 정리해 볼 것이다.
작성자의 수준에 맞춰 이해가 어려운 부분은 제외 하였으니 더 많은 정보를 원한다면 아래 Reference를 참고하기 바란다.
결론
- 장점만 갖는 시스템은 존재하지 않는다. NoSQL의 환상에 빠지지 말고, 서비스가 NoSQL 적용이 적합한지, 적합하다면 어떤 NoSQL 이 알맞는지
판단하여야 할 것이다.
위 내용은 아래 Reference의 내용을 토대로 작성되었습니다.
특히, 이번 포스팅은 제가 즐겨 듣는 팟케스트 꿈과 희망의 나는프로그래머다 공식 후훤사 한빛미디어의 책
"정경석 - 이것이 Redis다" 를 대부분 참고하였습니다.