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에 대한 몇 번의 호출 비용이 더 많이 들지만 성능 및 메모리 사용량 측면에서 더 좋을 것이라고 생각합니다.