Month: September 2012

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?

머 알아서…

약간 특성이 다릅니다.