MongoDB : 모음의 문서 모음

Question

컬렉션에 66 억 개의 bigram을로드해야하지만이 작업을 수행하는 가장 좋은 방법에 대한 정보는 찾을 수 없습니다.

하나의 기본 키 인덱스에 많은 문서를로드하는 데 영원히 걸릴 것이지만 mongo가 파티션 분할과 동등한 기능을 지원하지 않는다는 것을 알고있는 한?

샤딩의 도움이 될까요? 많은 컬렉션을 통해 데이터 세트를 분리하고 그 로직을 내 애플리케이션에 구현해야합니까?

Answer 1

최적의 대량 삽입물이 무엇인지 말하는 것은 어렵습니다.이 부분적으로 삽입하는 개체의 크기 및 기타 헤아릴 수없는 요인에 따라 달라집니다. 당신은 몇 가지 범위를 시도하고 당신에게 최고의 성능을 제공 볼 수 있습니다. 대안으로, 어떤 사람들은 mongoimport를 사용하는 것을 좋아합니다. 꽤 빠르지 만 가져 오기 데이터는 json 또는 csv 여야합니다. 데이터가 BSON 형식 인 경우 명백히 mongodrestore가 있습니다.

Mongo는 수십억 개의 문서를 쉽게 처리 할 수 ​​있으며 수십억 개의 문서를 하나의 컬렉션에 포함 할 수 있지만 maximum document size is 16mb을 기억하십시오. MongoDB에는 수십억 개의 문서가 담긴 많은 사람들이 있으며, MongoDB Google User Group에 관한 많은 토론이 있습니다. 마음이 바뀌고 대신 여러 개의 컬렉션을 갖고 싶다면 많은 수의 컬렉션을 사용하고 싶다면 document을 읽어보세요. 컬렉션이 많을수록 더 많은 인덱스를 갖게되고 아마도 원하는 것은 아닙니다.

수십억 개의 문서를 MongoDB에 삽입하고 그 사람의 blogpost에 Craigslist의 presentation이 있습니다.

sharding이 좋은 해결책이 될 것 같지만 일반적으로 샤딩은 여러 서버에서 스케일링에 사용되며 많은 사람들이 쓰기를 확장하려는 경우 또는 작업 세트를 유지할 수없는 경우 (예 : 데이터 및 색인)을 RAM에 저장합니다. 단일 서버로 시작한 다음 데이터가 커지거나 여분의 중복성과 복원력이 필요하면 샤드 또는 복제 세트로 이동하는 것이 가장 이상적입니다.

그러나 다른 사용자는 쓰기가 많은 단일 mongod의 잠금 제한을 없애기 위해 여러 mongod를 사용합니다. 그것은 분명하지만 여전히 가치가 있지만 다중 mongod 설정은 단일 서버보다 관리가 더 복잡합니다. IO 또는 CPU가 여기에서 최대치로 설정되지 않았고 작업 세트가 RAM보다 작고 데이터의 균형을 유지하기가 쉬운 경우 (단일 서버에서 샤딩으로) 개선되어야합니다. 참고로, 메모리 및 IO 경합 가능성이 있습니다. 2.2가 개선 된 concurrency을 db locking으로 사용하면서, 나는 그러한 배치의 이유가 훨씬 적을 것으로 생각합니다.

샤딩으로의 이동을 계획해야합니다. 즉 샤드 키를 신중하게 선택해야합니다. 이 방법을 사용하면 밸런서를 미리 분할하고 끄는 것이 가장 좋습니다. 일들을 균형있게 유지하기 위해 데이터를 움직이는 것은 비생산적 일 것입니다. 즉,이를 분할하는 방법을 정면으로 결정할 필요가 있다는 것을 의미합니다. 또한 일부 필드는 샤딩이나 기본 키로 유용 할 것이라는 생각으로 문서를 디자인하는 것이 중요합니다.

여기 좋은 링크입니다 -

• Choosing a Shard Key
• Blog post on shard keys
• Overview presentation on sharding
• Presentation on Sharding Best Practices

Answer 2

shard data in MongoDB (shard key에 N 개의 서버에 걸쳐 분할)이 가능합니다. 사실, 그 중 하나가 핵심 강점입니다. 응용 프로그램에서 그렇게 할 필요는 없습니다.

대부분의 사용 사례에서 66 억 건의 문서를 작성하는 것이 좋습니다. 필자가 경험 한 바에 따르면, MongoDB는 하나의 대형 서버가 아닌 다수의 중급 서버로 더 잘 수행됩니다.