NoSQL의 단점
데이터베이스를 목적에 맞게 관리하기 위해서는 다양한 조건을 따져보아야 합니다. 그중 기존에 사용 중인 데이터베이스 관리 시스템(DBMS)을 NoSQL 방식으로 변경하기 위해서는 어떠한 단점이나 문제점이 발생할 수 있는지에 대해 먼저 생각해 보아야 합니다. 이 글에서는 몽고 디비의 단점 및 문제점에 대한 내용을 다루어 보겠습니다.
몽고 디비 (MongoDB)의 단점
첫 번째로 몽고 디비는 데이터 업데이트 중 장애가 발생하면 데이터가 손실될 수 있다는 치명적인 단점을 가지고 있습니다. 이러한 문제점이 발생하는 이유가 몇 가지 존재하는데 분산 처리 시스템을 사용하여 데이터의 부분 결함 가능성이 있고, 데이터 갱신 및 입력 시 바로 디스크에 쓰지 않으며, 쓰기가 비동기식으로 이루어지기 때문입니다. 몽고 디비는 60초 간격이나 2GB의 저널 데이터가 기록되었을 때 메모리의 변경점을 디스크에 기록 요청하는 것 또한 데이터 손실 문제에 영향을 줄 수 있으나, Journal 기능을 활용하여 메모리를 조금 더 사용하고, 쓰기 속도를 약간 낮추며 변경점 이후의 데이터를 복구할 수 있게 되었습니다.
두 번째로 많은 인덱스를 사용할 때, 충분한 메모리 확보가 필요합니다. 시스템의 기억 장치가 다양한 기기와 프로그램들 간에 동적인 재배치가 어떻게 할당되어 있는가를 나타내는 메모리 매핑(Memory mapping) 기술이 충분한 시스템 메모리를 요구하여, 메모리 크기가 성능을 좌우합니다. 또한 메모리를 넘어서는 경우가 발생하면 성능이 급격하게 저하되는 문제점을 확인할 수 있습니다.
세 번째로는 비효율적인 Key 중복 입력으로 인해 데이터 공간 소모가 관계형 데이터베이스 관리 시스템(RDBMS)에 비해 많다는 점을 들 수 있습니다. 그 외에도 두 개 이상의 테이블을 결합하여 데이터를 검색하는 Join 기능을 지원하지 않고, 트랜잭션 지원이 RDBMS에 비해 미약합니다. 또한 제공되는 분산처리 기술(MapReduce) 작업 성능이 '아파치 하둡'에 비해서 떨어지고, Multi Node의 insert 연산 중에 연산 실패가 일어나는 경우가 발생하며 Cascade(종속 개체를 변경 또는 삭제할 때 대상 개체가 다른 개체를 참조할 경우 연쇄적으로 함께 변경 또는 삭제)가 불가능합니다.
데이터의 유실 가능성이 존재하는 몽고 디비의 불안정성은 데이터양이 많을 경우에 일부 데이터가 손실될 수 있는 것을 의미합니다. 이러한 문제는 섀딩(데이터 분산 저장)의 비정상적인 동작이나, 레플리카 프로세스(복제 기능)의 비정상적인 동작을 의심할 수 있고, 문제를 해결하기 위해서 Chunk size(데이터 블록 크기)와 Shard key(올바른 shard에 일관성 있는 방식으로 들어갈 수 있도록 entry를 위치시키기 위해, hash 함수에 들어가는 value들은 같은 열에서 나오는 데 이 열을 의미)를 적절하게 설계하면 해결할 수 있습니다.