좋은 MongoDB 서버를 만드는 하드웨어는 무엇입니까? 어디서 구할 수 있습니까?


13

지금 dell.com에 있고 소규모 시작을 위해 MongoDB 데이터베이스를 실행할 서버를 구입한다고 가정 해보십시오. 분당 수만 번의 쓰기 및 읽기 (작은 개체)를 처리해야합니다. 2 개의 프로세서를 사용 하시겠습니까? RAM에 더 투자 하시겠습니까?

MongoDB는 RAM에서 가능한 한 많은 것을 처리 한 다음 디스크로 모든 것을 플러시합니다.이 경우 큰 L2 캐시가있는 CPU, 아마도 40GB 이상의 RAM에 투자해야합니다 그리고 솔리드 스테이트 드라이브 .. 맞아?

고급 (~ $ 11,309, 2 개의 비싼 프로세서, 96GB의 RAM) 서버 또는 2x (~ $ 6,419, 2 개의 비싼 프로세서, 12GB의 RAM) 서버를 사용하는 것이 더 나을까요?

Dell은 괜찮습니까? (저는 포르투갈 이외의 미국 이외 지역에 있습니다)


3
시작을 위해 EC2와 같은 제품 대신 하드웨어를 구매하는 이유는 무엇입니까? 요구 사항이 무엇인지 알 때까지는 적어도 처음에.

톰과 동의하십시오. 클라우드에서 일부 인스턴스를 가져 오지 않는 이유는 무엇입니까?

1
@mixdev는 틀렸다 : "Linux, NUMA 및 MongoDB는 잘 작동하지 않는 경향이있다." 출처 : mongodb.org/display/DOCS/NUMA
Shadok

답변:


19

처음에는 RAM을 강화하고 싶을 것입니다. 필요한 RAM은 저장하는 데이터 양, 컬렉션 수, 해당 컬렉션의 인덱스, 데이터 액세스 패턴 등에 따라 다릅니다. 많은 요소.

가장 중요한 것은 RAM에 인덱스를 유지하기에 충분한 RAM이 있어야합니다. 그렇지 않으면 Mongo가 메모리 매핑 된 파일을 RAM 안팎으로 이동시키는 동안 서버가 지속적으로 페이징되므로 성능이 크게 저하됩니다. 이 모든 것에도 불구하고, 우리는 쓰기 속도에 영향을 미치지는 않았지만 다른 모든 것은 영향을 받았습니다. 인덱스가 더 이상 RAM에 맞지 않으면 큐에서 쓰기, 플러시, 덤프 등의 처리가 모두 대히트됩니다.

따라서 짧은 대답은 없습니다. 기본적으로 인덱스에 대해 똑똑하십시오. 필요한 것만 사용하십시오. 가능한 경우 컬렉션을 작게 유지하십시오 (예 : 가능한 한 여러 개로 나눕니다).


1
우리의 경험에서 Mongo가 쿼리를 위해 RAM을 사용하지 않으면 쿼리는 문서로 이동 할뿐만 아니라 (5 분, 15 분, 시간 ...) 실행되지 않고 삽입이 실패하기 시작합니다.
Jonesome Reinstate Monica


6

MongoDB에서 원하는 것은 RAM입니다. 그리고 더 많은 RAM. RAM을 구입하면 상처를 줄 수 없습니다.


3

프로덕션 하드웨어를 구매하는 단계에 있다면 실행중인 응용 프로그램이 이미 작성되어 있어야합니다. 따라서 보유한 하드웨어에서 앱을 실행하고 메트릭을 가져옵니다. 일부 구성 요소를 점차적으로 변경하고 더 많은 메트릭을 취합니다. 완료되면 응용 프로그램 및 시나리오에 가장 중요한 초점을 알 수 있습니다.


3

먼저-가능한 한 많은 RAM을 구입하십시오. 두 번째 제한 요소는 디스크 속도입니다. RAID가 도움이됩니다. SSD가 도움이됩니다. 더 많은 샤드가 도움이됩니다. 디스크 효율성 및 필요한 응답 시간과 비교하여 처리량을 측정 한 다음 예산 내에서 수행 할 작업을 결정하십시오.


1

Linux 클러스터 솔루션이 더 좋고 저렴한 대안인지 궁금합니다.

MongoDB를 사용하면 많은 서버에 데이터를 배포 할 수 있습니다. 하나의 호닝 서버로는 불가능합니다.

MongoDB는 호닝 서버에 관계형 데이터베이스를 배포하는 것이 충분히 확장되지 않았다는 것을 알게 된 다음 단계 중 하나라고 생각했습니다.


1

분당 수만 쓰기는 아무것도 아닙니다. 당신은 당 50.000 이상 쓰기 얻을 수있는 두 번째 괜찮은 하드웨어를. 하드웨어 사양은 실제로 수행하려는 작업에 따라 다릅니다. 일반적으로 큰 데이터베이스와 빠른 IO 시스템에 충분한 RAM이 적절한 CPU 옆에 중요합니다 ...


0

하드웨어를 설계하기 전에 확실한 기준을 세우는 것이 중요합니다. 일반적으로 경험이 많은 mongoDB 직원이 이러한 종류의 질문을 요청하면 누구나 질문에 대한 답변을 고려할 수 있습니다.

현재 응용 프로그램 통계 (있는 경우)

  • 현재까지의 총 기록은?
  • 저장 용량 견적을 시작 하시겠습니까?
  • 월간 % 성장률이 예상됩니까?
  • 평균 문서 크기?

데이터 처리 작업 부하

  • 새로운 삽입 / 일, 초당 피크 및 평균?
  • 초당 업데이트, 피크 및 평균?
  • 읽기 / 일, 피크 및 평균 / 초?
  • 쿼리 당 반환 된 평균 문서 수 : 70
  • 삭제 / 일, 피크 및 평균 / 초 : 없음
  • 대량로드 / 대량 업데이트가 있습니까? 그렇다면 얼마나 크고 얼마나 자주?
  • 몇 가지 유형의 문서가 있습니까?
  • 각각 몇 개입니까?
  • 문서가 어떻게 보일 것으로 예상하십니까 (샘플 문서)?

쿼리 패턴 및 성능 기대

  • 응답 SLA를 읽으시겠습니까?
  • 응답 SLA를 작성 하시겠습니까?
  • 읽기는 범위 기반이거나 무작위입니까?

예상되는 액세스 패턴

  • 필요한 보조 인덱스 수는?
  • 속성의 개수?
  • 정렬 조건?
  • 단일 또는 복합?
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.