실시간 집계 및 저장을위한 몽고 (Mongodb) 디자인?

Question

mongodb 서버에 백만 개의 블로그 & 뉴스 기사를 저장한다고 가정 해 봅시다.

이러한 기사에는 범주, 작성자, 위치, 도메인 등 집계에 사용할 수있는 몇 가지 필드가 있습니다. 이러한 기사를 몽고 데이터베이스에 저장할 수 있지만 그 기사에는 텍스트, 요약 등의 필드가 있습니다. 꽤 많은 양의 데이터를 포함하고 아마도 상당히 큰 문서를 만들 수 있습니다 (여전히 < 16MB).

제 질문은 mongodb가 집계를 실행할 때 전체 문서를 메모리로 읽어서 집계를 수행합니까? 분명히 디스크의 모든 데이터는 메모리에 맞지 않습니다. 문서의 크기가 집계 성능에 영향을 줍니까?

저장을위한 좋은 디자인/대안 & "REALTIME"집계 란 무엇입니까?

Realtime aggregation이 필수이므로 Hadoop과 같은 배치 프로세스를 내 프로젝트에 사용하고 싶지 않습니다. 2 mongo dbs의 설정을 보았습니다. 원본 문서를 저장하는 저장 공간 1 개, 별표 스키마에 집계 필드를 저장하는 저장 공간 1 개가 있었지만 두 가지 버전을 유지해야하므로이 방법이 맘에 들지 않습니다. 2 곳의 문서.

감사합니다.

Answer 1

제 질문은 mongodb가 집계를 실행할 때 전체 문서를 메모리로 읽어 들여 집계를 수행합니까?

아니, 최신 버전 이후 어떻게 프로젝션 작품에 변경이있는 지금은 부분 부하, 오히려 덮여 쿼리를 사용 할 수 있습니다 또는 : http://docs.mongodb.org/manual/core/aggregation-pipeline-optimization/#projection-optimization

최적화 단계가 투사를 적용 _id 및 amount 필드 만 $ match 단계의 결과 문서로 반환되도록 파이프 라인의 헤드를 지정합니다.

그래서 전체 텍스트 내용 등을로드하는 것에 대해 걱정할 필요없이 문서 비트를로드 할 수 있습니다.

문서의 크기가 집계 성능에 영향을 줍니까?

모든 작동에 영향을줍니다. 하드 드라이브에서 할당이 연속적이더라도 문서가 커질수록로드하는 데 더 많은 IO가 필요합니다.

메모리 사용량에도 영향을 줄 수 있습니다. 작업 세트가 큰 문서에서 문제를 발견 할 수 있으며 페이지 스 래싱에 직면 할 수 있습니다.

저장을위한 좋은 디자인/대안 & "REALTIME"집계 란 무엇입니까? 증분지도 사전 집계가 감소

는 좋은 선택이다 : http://docs.mongodb.org/ecosystem/use-cases/pre-aggregated-reports/ 내가 개인적으로 훨씬 더 큰 성공을 그것을, 집계 프레임 워크보다 훨씬 더를 사용합니다.

실시간 집계가 필수이므로 내 프로젝트에는 Hadoop과 같은 배치 프로세스를 사용하고 싶지 않습니다.

"실시간"? "실시간"이란 정확히 무엇입니까? 서버가 약 30 분간 데이터를 크 런치하는 동안 사용자가 기다리는 동안 그 위치에 있습니까? 아니면 사용자 데이터가 2 분 지연되고 사용자가 페이지로드 시간 등을 전혀 기다리지 않았습니까?

높은 세분성이 필요한 경우 업데이트 간격을 5 초로 줄일 수 있습니다.

실시간 처리가 항상 진행되는 것은 아니며, 앞으로 많은 다른 사이트를 살펴보십시오.