Tag Archives: nosql

MongoDB 특성 분석 01, 사용전 기능조사~ 에서 ~ 적용사례까지

개요

몽고디비는 처음 알게됐을 때 부터 써보고싶기는 했는데.. SI만 하다보니 쓸 기회가 없었다.
개인적으로 테스트용이나 회사에서 간단한 모듈을 만들 때 사용하긴 했지만, 제대로 분석을 해 보고 적용해본게 아니라서 깊이있는 지식은 없는 상태

사용목적

기술적으로 몽고디비가 꼭 필요한 상황은 아니라고 판단되지만… 나쁜 선택은 아닐 것 같아서 일단 적용 해 볼 생각이다.
저장할 데이터 : Crawling, Scrapping 데이터, 게시판 글, 댓글, GIS정보, GridFS를 이용한 이미지 저장

 

GIS 정보 관리
PostgreSQL의 PostGIS를 써도 되지만…. 내부정보가 아닌 사용자 데이터를 저장해야 한다. 서비스가 급성장하면서 데이터가 엄청나게 쌓일거라서 MongoDB를 쓸 수 밖에 없잖아

Crawling, Scrapping 데이터
텍스트 파일 저장

GridFS를 이용한 이미지 저장
이 부분은 써야할까? 모르겠다. 성능문제도… 별 생각없이봐도 문제가 잇겠지?
http://symplog.tistory.com/entry/MongoDB-MongoDB-GridFS-%EB%B6%80%ED%95%98%ED%85%8C%EC%8A%A4%ED%8A%B8
있다고하네…
그리고 cdn에 올리면 필요없는 부분 아닌가

몽고디비에 대해 잘 정리된 페이지
http://kkyunstory.tistory.com/65
이런 평가를 많이 보긴 했는데…

아몰랑 그냥 쓰다가 안되는거 한개씩 옮겨야겠다.

특성 ~~ 확인중

문서형 데이터베이스

데이터를 문서형태로 저장 – BSON을 이용하여 저장
BSON : JSON을 Binary 형태로 저장

장점

다양한 인덱스 제공
Sharding

 

인덱싱 방법

종류

Unique고유 인덱스
Sparse희소 인덱스 : Null인 경우 인덱스 생성하지 않음
다중 키 인덱스, 복합인덱스

주의점

롤백은 불가능
트랜잭션 안된다고 치고
인덱싱 걸면 디비 먹통

DBMS 간단한 선택 기준, Oracle, Mysql, postgresql, cubrid, MSSql…Mongo, Cassandra

DBMS를 뭘로 쓸지 선택하기가 정말 어렵다.

요즘에는 nosql db까지 추가되서 선택의 폭이 더 넓어지고 고민의 시간은 더 길어진다.

nosql을 써야지 왠지 간지가 날 것 같고…

신기술을 좋아하는 상사나 정부관련 사업 제안에는 MongoDB, Cassandra같은 nosql DB를 들이밀어야 할 것만 같다.(실제로 그러는게 좋다)

아무리 그래도 용도에 맞는 DB를 골라야 하겠지..

첫번째 선택 : nosql이냐 rdbms냐!!

간단히 두 선택지에 대한 정의를 내려본다 : nosql은 쉽게 말해 객체지향 DB라고 생각하면 쉽다. 구조도 그런 구조고… RDBMS는 엑셀의 표를 sql쿼리언어로 조회가 가능하게 해놓고 속도도 좀 잘 나오게 만들어놓은 놈들?

이 두 가지 중 한가지를 선택하는 것은 어렵지 않다.

1. 데이터가 들어오는 속도가 매우 빠른 경우

데스크탑 환경에서 테스트한거라 비싼서버에서는 더 빠를수도 있겠지만 열배 더 빠르다고 해도 딜레이가 걸리는건 마찬가지일 것 같다. 증권 가격데이터를 DB에 밀어넣어봤는데 9시~3시까지 초당 1000개이상의 데이터가 나오는데 이 데이터가 병목에 걸려서 밤새도록 입력하다가 다음날 9시가 되도 전날 데이터를 입력하고 있는 상황이 발생했다.

이런경우는 그냥 FileSystem에 디렉토리로 나눠서 저장하면 된다. 가장 간단한 구조는 2012/12/12/ 연월일로 디렉토리 계층만들기

2. 도메인 설계후 각 도메인간 연결고리가 많아서 조인이 많아진다~

nosql에 저장할 때 적합해보이는건…… 게시판? 쇼핑몰? 이정도인것같다

nosql 한 document의 사이즈 한계가 2메가랬나 어쨌나 그러니까… 한 document(row)밑에 자꾸 내용이 추가된다면 곤란하다. 이런경우 collention을 한개 분리시켜야되는데 그러면 join을 해야된다. nosql db에서 join은 지원되지 않는다.

이런경우에는 rdbms를 사용하면 된다.

써놓고보니 이거 읽고 딱 이거다 하는 결론을 내지는 못할 것 같다.

그냥 한마디로 말해서 도메인 구조 짜놓고보면 대충 감이 온다.

3. 잦은 읽고쓰기가 발생한다.

이런경우는 그냥 RDBMS를 쓴다. RDBMS가 감당하지 못할 정도의 규모라서 꼭 nosql을 써야겠다면 설계를 변경하는게 좋겠다. 데이터를 삭제하지 않고 로그처럼 쌓아가는 방향으로…

4. 관리인력문제

회사 내부에 이 DB를 관리할 인력이 있는가도 문제가 될 것 같다. nosql 클러스터 구성하고 레플리카셋 샤딩 마음것 주무를 수 있는 인력이 잘 잇을 것 같지는 않다. 개발자가 지가 다 할줄안다고 막 적용했다가는… 나중에 고생할거다.

 

어떤DB?

머 알아서…

약간 특성이 다릅니다.