잡동사니

반응형

질문

Introduction:

  • 시스템은 현재 2 개의 장치로 구성되어 있습니다.
  • 각 장치에는 데이터를 측정하는 10 개의 노드가 있습니다. 해당 데이터는 5 초마다 DB에 기록됩니다.
  • 지금은 해당 설정에 대해 최대 50 : 1 (읽기 : 쓰기) 비율을 추정했습니다. 이것은 새로운 장치 / 노드가 도입 될 때 변경 될 가능성이 매우 높습니다.
  • 현재 하나의 문서에 모든 것을 포함하고 있습니다 (예 : http://pastebin.com/4dATY5NF).
  • 내 3 가지 주요 사용 사례는 다음과 같습니다.
    • DB에 측정 값 추가
    • 모든 노드에서 마지막 측정 값 가져오기 (5 개 노드의 경우 5 개의 측정망이 반환 됨)
    • 주어진 날짜의 측정 목록 가져오기 (입력 날짜 / 시간 기준과 일치하는 긴 측정 목록)

Problem:

내 주요 관심사는 시간이 지남에 따라 크게 증가하는 문서 (내장 된 측정 배열에 삽입)와 주어진 날짜 / 시간 범위에 대해 측정을 쿼리하기 어렵게 만드는 일반적인 문서 구조에 관한 것입니다.

예 : 5 초마다 데이터를보고하는 노드가 하나 뿐인 경우에도 임베디드 어레이의 총 측정 수 (하루 만)는 24 * 60 * 60 / 5 = 17280입니다. 한 달에 5 개의 노드를보고하면 다음과 같은 결과가 나타납니다. 518400 요소가 포함 된 5 개의 임베디드 배열 (한 문서에!) 장치가 더 오래 작동할수록 연결된 각 노드에 대한 내장 측정 배열에 더 많은 항목이 있습니다.

Questions:

  • 예상 읽기 / 쓰기 비율이 임베딩과 링크 결정에 어떤 영향을 미칩니 까?
  • 이 경우 임베딩의 모든 장점을 희생하고 데이터를 2 개의 컬렉션으로 분할하는 것이 정당한가요?

    제가 생각했던 것은 하나는 장치 / 노드 구성을위한 컬렉션이고 (많은 정보가 없기 때문에 여기에 정보 포함), 두 번째는 측정만을위한 것입니다 (디바이스 및 노드에 대한 참조 포함). 이것은 DB에 대한 몇 번의 호출 비용이 더 많이 들지만 성능 및 메모리 사용량 측면에서 더 좋을 것이라고 생각합니다.


답변1

순서대로 :

  • 그렇지 않습니다. 무한히 증가하는 구조를 단일 문서에 포함하는 것은 확장되지 않으므로 피해야합니다. 각 측정 값을 단일 문서로 저장하는 것이 훨씬 바람직합니다. 쓰기 성능이 더 안정적이지만 읽기 / 쓰기 비율은 그다지 중요하지 않습니다 (MongoDB는 증가하는 문서를 정기적으로 이동해야하므로 쓰기 지연 시간이 급증 할 수 있습니다).
  • 실제로 임베딩에 대한 "좋은 점"이 많지 않습니다. 그것은 쿼리를 복잡하게 만들고 내장 된 구조의 작은 부분을 얻을 수있는 방법이 없습니다. 따라서 정당화 될뿐만 아니라 두 개의 개별 컬렉션으로 이동하는 것이 좋습니다. 미래의 증명 스키마에서는 최상위 문서를 쿼리하고 시스템이 처리해야하는 사용자 또는 데이터 수에 관계없이 포함 된 구조가 크기 제한이있는 경우 항상 전체 포함 된 구조가 필요한 경우에만 포함합니다.


 

 

 

 

출처 : https://stackoverflow.com/questions/12962814/mongodb-schema-design-for-a-measurement-acquisition-system

반응형

이 글을 공유합시다

facebook twitter googleplus kakaoTalk kakaostory naver band