MongoDB - 전자 메일 픽셀 추적 데이터를 저장하는 데 가장 적합한 샤드 키는 무엇입니까

Question

현재 우리는 메일 링리스트의 가입자에게 전자 메일을 보냅니다. 이것은 SQL Server 데이터베이스에 데이터를 삽입하는 PHP 파일에 매핑되는 추적 픽셀을 특징으로합니다.

이메일 추적 픽셀 삽입물의 현재 평균치는 하루에 약 80,000 개입니다. 약 800,000 개의 인서트는 약 1GB의 하드 디스크 공간과 동일하므로 10 일의 1GB 데이터입니다.

이 외에도 다른 삽입물 및 추적 데이터가 SQL Server 데이터베이스에 삽입되며 웹 사이트에서 사용하는 것과 동일한 데이터베이스가됩니다. 따라서 공간, 성능, 라이선스 비용 및 수평 확장 이유 등으로이 분석 추적 데이터를 SQL Server DB +에서 이동하려고합니다.이 분석 추적 데이터는 웹 사이트에서 필요하지 않으므로이 무거운 삽입을 이동하려고합니다. 떨어져서 웹 사이트 DB가 바로 그 것이다. 순간

TrackingPixelId에서

테이블 구조 | 사용자 ID | 코드 | 중간 | 출처 | DateViewed | SessionId

9109616 | 1234 | 'BULLETIN120115'| '이메일'| 'BULLETIN120115'| {datetime} | bf7e2f801 ...

열 정보

TrackingPixelId : PK 정수 자동 증가

사용자 아이디 : 정수

코드, 매체 및 소스 끈/VARCHAR에

DateViewed : 날짜 시간 예 : 2015-01-13 06 : 18 : 24.920

S essionId : 예 : fa5cac87896e1c7b423051fffdb836a6

코드와 소스는 본질적으로 열어 본 이메일 메일의 고유 ID입니다.

데이터가보고되는 방식에 관해서 우리는 열린 전자 메일의 볼륨을 조사하게됩니다. 따라서 매일, 매주, 매월 및 연간 보고서가 생성되므로 보고서가 즉시 생성되어야 할 필요는 없습니다. 하루에 많은 양의 쓰기가 필요하지만 읽기가 넉넉하지만 가장 최근의 데이터를 먼저 원할 것입니다.

이러한 모든 요소를 ​​고려해 볼 때 가장 좋은 샤드 키는 무엇일까요?

Answer 1

먼저 샤딩에 뛰어 들지 않도록주의하십시오. 데이터 볼륨을 사용하면 트래픽을 단일 복제 세트에서 처리 할 수 ​​있어야합니다. 샤딩의 실제 트리거 포인트는 작업 세트가 단일 시스템의 RAM에 대해 합리적인 것보다 커지는 경우입니다.

당신이 쓰기 성능에 주로 관심이 있고보고를 위해 더 느린 읽기를 허용한다고 가정 할 때 해시 된 샤드 키가 가장 잘 작동한다고 생각합니다. MongoDB가 생성 한 ObjectId 값을 해싱하거나 고유 한 ID를 해시 할 수 있습니다. 이렇게하면 쓰기가 클러스터를 통해 균등하게 분산됩니다. 읽기는 분산 형 (scatter-gather)이 될 것이지만 아주 좋은 쓰기 배율을 얻으려면 견딜 수있는 것처럼 들립니다.

게다가, 매일, 매주 생성하는 데 관심이 있으니까 ...보고서에서는 전략을 사용하여 읽기로드를 최소화하고 상환 할 수 있다고 생각합니다. 이는 샤드 키 선택 때문에 쓰기로드보다 클러스터에 훨씬 더 많은 비용이 듭니다. 이렇게하면 새 데이터에 대해 점진적으로 보고서를 생성 한 다음 쿼리 할 때 생성하지 않고 완료된 보고서를 쿼리 할 수 ​​있습니다. 수동 페이지에서 map/reduce를 사용하더라도 map/reduce 대신 집계 파이프 라인을 사용하여 가능한 언제든지보고 데이터를 생성 할 것을 제안합니다.