몽고디비의 속도가 빠르다는 이유만으로 도입한뒤 몇일만에 포기하고 기존 디비로 개발하는 경우를 많이 봤다
결론적으로 몽고디비는 빠른 디비라고 말하기 어렵다
검색엔진의 기본인 Binary 검색 방식이 달라지지 않는한 모든 데이타베이스에서 하나의 데이타를 읽어오는데 걸리는 시간은 동일하다
몽고디비가 빠른것은 join 을 하지 않기 때문이다
하나의 레코드에 이미 모든 데이타가 들어있는 설계방식으로 구현하기 때문이다
몽고디비에서 aggregater 라는 기능은 RDBMS의 테이블 join의 기능을 비슷하게 처리할 수 있다
하지만 aggretater 는 join 보다는 group by 에 가까운 기능이라고 생각한다
몽고디비를 이용해서 프로젝트를 성공하기 위해서는 데이타 입출력시 join 없는 단일 테이블 구성의 설계가 익숙해 져야한다
쇼핑몰 테이블 설계
주문 : 사요자정보, 상품1, 상품2, 상품3
기존의 방식에서는 buy, user, goods 라는 3개의 테이블을 조인해서 설계하지만
몽고에서는 order : { user, goods[3] } 과 같은 형태로 설계해야 한다
데이타의 중복성으로 용량을 차지할거 같지만 실제 서비스에서는 join 이 될 데이타는 생각보다 많지 않다
쇼핑몰에서 동일한 제품이라도 판매자에 따라서 결국 다른 제품처럼 판매하고 재 판매가 될때도 다른 상품 코드로 등록되는 경우가 대부분이다
계층형 컬렉션구조에 대한 이해가 중요하다
NoSQL에서는 레코드의 모임을 테이블이라고 하지 않고 컬렉션(모음)이라고 말하는것이 정규화되지 않음을 의미한다. 하나의 레코드에 한줄이 아닌 파일디렉토리와 비슷한 Hirachy 형태로 구성하게 된다
화면 처리와 데이타 저장의 구성이 다르게 구성해야 하기 때문에 기존의 RDBMS의 구조와 동일한 1차원 적인 구조와 다수의 컬렉션을 aggretation으로 해결하다가는 오히려 더 느리고 개발만 어려워지는 경험을 하게 될것이다
적어도 6개월 이상 내부개발 테스트를 해보고 나서 선택해야 실패를 줄일 수 있다
본인역시 서비스 제품에 도입하기 까지 약 2년의 내부사용 이후에 했음에도 초기에 도입한 설계를 지금에서 점검하면 상당 부분은 문제가 있는 설계였다고 생각한다
하지만 지금은 모든 서비스를 몽고 디비로 개발하고 있다