-
MongoDB 기본 이론 정리 (관계형 데이터 베이스와 몽고디비 차이??)개발일지/mongoDB 2019. 4. 19. 23:40
회사에서 사용하던 관계형DB Mysql 를 사용하다 새로운 서비스를 개발하면서
중요한 데이터에 대해서는 Mysql를 사용하고 방대한 데이터에 대해서는 비관계형 DB 인 몽고DB를 사용하기로 결정되었다. 몽고DB에 대해서는 몇년 전부터 많이 들어왔고 대충 어떤 이유에서 사용하는지는 지식 적인 측면에서 알고 있지만 이왕 사용하게 된거 정확하게 학습하고 사용하는것이 좋을것같아서 이렇게 정리하기로 한다.
몽고DB가 왜 수면위로 나왔으며 급부상한 이유는 왜일까?
2000년대 초반에 sns 플렛폼들이 많이 활성화 되고 iphone 과 안드로이드가 나오면서 데이터의 양이 급속도로 상승하게 되었다. 그래서 기존에 관계형 데이터로 잘 사용해오다가 방대한 양의 데이터를 빠르게 처리가 힘들어지게 되어 해결책이 필요 했고 2007~2009년때에 이를 해결하기위한 솔루션들이 나오게 됐다.
몽고DB 역시 2009년 초반에 출시가 되면서 지금까지 빅데이터를 위한 솔루션으로 사용하고 있다.
그렇다면 왜 기존 관계형 데이터 베이스로 방대한 양의 데이터를 처리하기가 힘든것일까?
관계형 데이터 베이스 VS 비관계형 데이터 베이스 차이는?
다양한 차이가 있겠지만 내가 정리할 이야기
는 ACID 에 대한 내용만 정리할것이다.
관계형 데이터베이스 ACID
-
원자성(Atomicity)은 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력이다.
-
예) 영화관 예매를 예를 들어볼께요 많이들 영화 예매 해보셔서 아시겠지만 영화 좌석을 선택합니다 . 그 순간 결제까지 가지 않았지만 그 자리는 예약으로 잡아 놓습니다 그러다가 결제를 하려고 하는데 시간을 잘못 선택했거나 마음이 변해서 예매를 취소합니다 그러한 상태에서 원자성에 따르자면 그 자리는 예약을 풀어야 하는것이고 만약 좌석이 그대로 예약된상태가 된다면 원자성의 원칙을 어기는 것이 되는것입니다.
-
일관성(Consistency)은 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미한다.
-
예) 영화관 좌석이 55좌석인데 예약인원은 55명이어야지 60명 70명이 되어서는 안된다는 뜻입니다. 일관성있게 유지 되어야 한다 라는 의미입니다.
-
고립성(Isolation)은 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미한다.
-
예) 영화관 예매하는 기기가 3대가 있다고 가정하고 3명이 동일한 영화에 동일한 시간 동일 좌석표를 열고있다고 가정합시다 그럼 선택은 동시에 가능한 상태가 되겠지요 하지만 결제하는 과정에서는 3명중 한명만 결제가 되어 예매가 되어야 하고 나머지 2명은 실패처리가 되어야 하는것입니다.
-
지속성(Durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미한다. 시스템 문제, DB 일관성 체크 등을 하더라도 유지되어야 함을 의미한다. 전형적으로 모든 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있다.
-
예) 예매를 완료 하고 표를 발급받았는데 갑자기 영화관 정전이 되고 20~30분뒤에 전기가 들어왔다 했을때 예매한 내용이 유지 되어야 한다는 의미입니다.
관계형 데이터베이스는 위의 ACID 원칙을 지키기 위해 위와 같은 절차를 진행하게된다.
그래프를 보시면 아시겠지만 정보유지를 위한 자원을 너무 많은것을 사용한다는것을 알게된다 실질적으로 데이터를 넣고 빼고 하는 부분은 오직 12프로인 Useful Work 만 사용하면되는데 말이다.
그래서 몽고DB는 빠른 속도를 위해 ACID 원칙을 사용하지 않고 12프로인 useful work 을 온전히 다 사용하게 됨으로 속도가 빠르다는 장점이 있는것이다.
그렇다면 ACID 원칙을 지키지 않는다면 안전한 데이터가 아닌데 어떻게 믿고 사용할수 있냐고 볼수 있겠지만
몽고DB는 속도도 유지하면서 안전성도 맞춰줄수 있도록 셋업이 가능하다 물론 관계형 데이터 베이스보다는 아닐지 모르지만 몽고DB도 BASE 원칙으로 데이터를 저장한다.
-
Basically Available 기본적으로 이용 가능할수 있어야 한다
-
예 ) 영화관 예매기에서 예매를 하다가 디비가 따운된다 할지라도 리플리카 셋 으로 셋팅된 복제 디비가 활성화 되게 되어 바로 이용이 가능하도록 한다.
-
Soft state eventually consistent 의 문제가 발견되면 일관성을 유지하기 위해서 데이터를 자동으로 입력하는 성질입니다.
-
Eventually consistent 일관성을 유지되지 않는 상태가 발생될때 일관성을 유지 되도록 이벤트를 잡아주는 성질입니다.
위에 BASE 원칙을 잘 지켜지기 위해서 사용되는 replica set 과 sharding 부분을 실습해보면서 기록할 예정이다
참고로 replica set은 이미 테스트까지 해보았다 아래 글에서 확인할수있다.
오늘은 기본적인 이론을 정리해보았다
다음에는 sharding 테스트를 기록하고 정리하며 글을 작성하도록 하겠다.
'개발일지 > mongoDB' 카테고리의 다른 글
[ MongoDB + ElasticSearch + Monstache ] 도커 기본 셋팅을 해보자 (4) 2019.10.02 [ mongodb Sharding] 몽고디비 샤딩 적용하기 / config sever + replica set (0) 2019.04.22 mongoDB replicaSet 환경을 실 서비스에 적용해보자 with mongoose (1) 2019.04.17 docker + mongodb replSet 우분투 몽고디비 리플리카셋업 하기 with Docker (3) 2019.04.16 window 로컬 환경에 mongoDB replSet 셋업하기. (0) 2019.04.16 -