(MongoDB) 설계 기준

<데이터 발생량과 Accss Patterns은 분석되었는가 ? >



  • Data양(초단위, 일단위)과 보관년도는 어떤가 ? 
  • Read와 Write의 비율은 ?
  • Update 빈도는?
  • Map Reduce(빠른읽기와 통계분석)를 적용해야 하는가 ?
<컬렉션과 인덱스에 대한 충분한 설계가 고려되었는가 ? >
  • 적적한 Collection Type( Capped, Non-Capped )을 결정했나?
  • 필드와 Data Type, Validator 는 결정되었나?
  • 저장할 Document 크기는?
  • Lin & Embedded Document를 적절히 설계했나 ?
  • Secondary Indexs 의 사용 여부
  • 적절한 Index Type을 선택했는가?

<적절한 시스템 환경은 준비 되었나?>
  • 데이터가 발생하는 비즈니스 환경에 맞는 적절한 Storage-Engine을 선택했나?
  • 해당 Collection의 Sharding 여부는 결정되었나?
  • 효율적인 처리를 위한 적절한 시스템 환경은 준비 되었나?(메모리, 디스크, CPU 수 등)


* ACCESS PATTERN

해당 Collection 에 대해 얼마나 많은 데이터를 얼마나 자주 Read, Write 하는지에 대한 비율과 해당 데이터가 얼마나 오랫동안 보관 되어야 하는지에 대한 Life Cycle에 대한 이해에 따라 설계를 결정해야 한다.

하나의 컬렉션을 구성하는 필드 중에는 쓰기 작업 만 주로 수행되는 필드가 있는 반면,
쓰기/읽기 작업이 동시에 자주 발생하는 필드도 있다.
만약, 빅데이터에 대한 쓰기 작업이 빈번한 컬렉션을 여러 개의 컬렉션으로 분리 설계하게 되면 초당 몇 만건 의 데이터를 빠르게 저장하는데 한계가 존재한다.

또한, 빅데이터에 대한 읽기 작업이 빈번한 필드들을 여러 개의 컬렉션에 분리 설계한다면 읽기 성능은 저하 될 수 밖에없다.


댓글

이 블로그의 인기 게시물

(18장) WebSocekt과 STOMP를 사용하여 메시징하기

(네트워크)폴링방식 vs 롱 폴링방식

(ElasticSearch) 결과에서 순서 정렬