데이터베이스의 컬렉션 수 제한

데이터베이스의 컬렉션 수 제한

mongodb의 컬렉션 수에 실질적인 제한이 있다고 말할 수 있는 사람이 있습니까?여기에 https://docs.mongodb.com/manual/core/data-model-operations/ #많은 컬렉션이 있습니다.

일반적으로 컬렉션 수가 많으면 성능 저하가 크지 않고 성능이 매우 우수합니다.

그런데 어떤 이유에서인지 mongodb가 데이터베이스에 네임스페이스 수에 대한 제한을 24000으로 설정하면 증가할 수 있을 것 같은데, 데이터베이스에 많은 컬렉션이 있다고 해서 성능 저하가 발생하지 않는다면 기본 구성에 제한이 있는 이유가 궁금합니다.

즉, 하나의 데이터베이스에 실질적으로 무제한의 컬렉션을 보유하는 것이 실행 가능한 솔루션입니까? 예를 들어, 멀티테넌트 애플리케이션의 경우 데이터베이스에 하나의 계정의 데이터 컬렉션을 보유하는 것이 가능합니까?모든 테넌트에 대해 데이터베이스에 대해 매우 많은 수의 컬렉션을 보유하는 것이 실행 가능한 솔루션이라면, 한 컬렉션에 각 테넌트의 문서를 보유하는 것과 비교하여 어떤 이점이 있습니까?당신의 답변에 매우 감사드립니다.

이 답변은 늦었지만 다른 답변들은 약간...신뢰성과 사실적인 정보 면에서 약하기 때문에 저는 그것을 조금 개선하려고 노력할 것입니다.

그러나 어떤 이유로 mongodb는 데이터베이스에 있는 네임스페이스의 수에 대한 제한을 24000으로 설정합니다.

그것은 단지 기본 설정일 뿐입니다.예, 기본 설정이 있습니다.

제한 페이지에 24000이 제한(http://docs.mongodb.org/manual/reference/limits/ #Number%20 of%20 Namespaces)이라고 나와 있는데, 이는 확장할 방법이 없지만 확장할 방법이 있는 것처럼 보입니다.

그러나 네임스페이스 파일의 크기에는 최대 제한이 있습니다(http://docs.mongodb.org/manual/reference/limits/ #Size%20 of%20Namespace%20File). 이는 2GB입니다.그것은 대부분의 경우에 가지고 놀 약 3백만 개의 네임스페이스를 제공하는데, 이는 꽤 인상적이며 많은 사람들이 그 한계에 빠르게 도달할지 확신할 수 없습니다.

구성(http://docs.mongodb.org/manual/reference/configuration-options/ #nssize) 내에서 또는 MongoDB 실행에 사용되는 명령을 조작하여 런타임에 nssize 매개 변수를 사용하여 기본값을 16MB보다 높게 수정할 수 있습니다(http://docs.mongodb.org/manual/reference/mongod/ #nssize option-mongod--nssize).

MongoDB가 nssize를 위해 기본적으로 16MB를 구현하는 이유는 실질적인 이유가 없습니다. 제가 알기로는 "세부 사항 하나하나로 사용자를 귀찮게 하지 않는다"는 모토에 대해 들어본 적이 없어서 저는 그것을 사지 않습니다.

제 생각에 MongoDB가 이것을 숨기는 주된 이유는 문서에서 언급하고 있는 것과 같이 다음과 같습니다.

고유한 컬렉션은 높은 처리량의 배치 처리에 매우 중요합니다.

MongoDB가 설계한 것처럼 클러스터를 통해 수평적으로 확장하기보다는 수직적으로 확장하기 위한 수단으로 여러 컬렉션을 사용하는 것은 대규모 웹 사이트에서는 좋지 않은 관행으로 간주됩니다. 이러한 12K 컬렉션은 일반적으로 사람들이 절대 확인하지 않을 것이며 절대 확인해서는 안 되는 것으로 간주되기 때문입니다.

더 이상의 제한은 없습니다!

다른 답변에서 언급했듯이 네임스페이스 파일의 크기에 따라 결정됩니다.이것은 기본 제한이 16MB이고 최대 2GB이기 때문에 이전에는 문제가 있었습니다.그러나 MongoDB 3.0 및 WiredTiger 스토리지 엔진이 출시되면서 이 제한이 제거된 것으로 보입니다.Wired Tiger는 거의 모든 면에서 더 나은 것 같습니다. 따라서 레거시 지원 이유를 제외하고는 누구나 구형 엔진을 사용할 이유가 거의 없다고 봅니다.사이트에서:

MMAPv1 스토리지 엔진의 경우 네임스페이스 파일은 2047MB 이하여야 합니다.

기본적으로 네임스페이스 파일은 16MB입니다.nsSize 옵션을 사용하여 크기를 구성할 수 있습니다.

Wired Tiger 스토리지 엔진은 이 제한을 받지 않습니다.

http://docs.mongodb.org/manual/reference/limits/

약간의 배경:

mongo는 데이터베이스를 만들 때마다 데이터베이스에 대한 네임스페이스(db.ns) 파일을 만듭니다.네임스페이스(또는 원하는 컬렉션) 파일에는 컬렉션에 대한 메타데이터가 저장됩니다.기본적으로 네임스페이스 파일의 크기는 16MB이지만 수동으로 크기를 늘릴 수 있습니다.각 컬렉션의 메타데이터는 648바이트 + 일부 오버헤드 바이트입니다.이를 16MB로 나누면 데이터베이스당 약 24000개의 네임스페이스를 얻을 수 있습니다.더 큰 네임스페이스 파일을 지정하여 mongo를 시작할 수 있습니다. 그러면 데이터베이스당 더 많은 컬렉션을 만들 수 있습니다.

기본 구성의 아이디어는 모든 세부 사항(및 구성 가능한 노브)으로 사용자를 번거롭게 하지 않고 대부분의 사용자에게 적합한 것을 선택하는 것입니다.또한 실행 가능성은 최상의/우수 설계 관행과 밀접하게 관련되어 있습니다.Chris가 말했듯이, 당신의 데이터의 모양을 고려하고 그에 따라 결정하세요.

다른 사용자가 언급했듯이 기본 네임스페이스 크기는 16MB이며 약 24000개의 네임스페이스 항목을 가져올 수 있습니다.실제로 Ubuntu의 64비트 인스턴스는 기본 16MB 네임스페이스 파일을 사용하여 23684에서 끝이 났습니다.

FAQ에서 언급되지 않은 한 가지 중요한 사항은 인덱스에서도 네임스페이스 슬롯을 사용한다는 것입니다.

네임스페이스 항목 수는 다음과 같습니다.

db.system.namespaces.count()

그리고 그 안에 무엇이 있는지 실제로 살펴보는 것도 흥미롭습니다.

db.system.namespaces.find()

일단 데이터베이스가 생성되면 네임스페이스 파일을 확장할 수 없기 때문에 필요한 것보다 더 높게 제한을 설정하십시오(내가 이해하기로는 - 방법이 있다면 말해주세요!!).

사실, 저는 최대치에 도달한 적이 없습니다.하지만 저는 분명히 24,000개의 수집 한도를 넘은 적이 없습니다.저는 성능 테스트를 할 때를 제외하고는 200개 이상을 기록한 적이 없다고요.인정해야 할 것은, 제가 보기에 데이터처럼 자신의 컬렉션으로 그룹화하는 것이 아니라 하나의 데이터베이스에 그렇게 많은 컬렉션을 갖는 것은 엄청난 혼란으로 들린다고 생각합니다.

데이터 및 비즈니스 규칙의 모양을 고려합니다.멀티 테넌트 애플리케이션을 위해 데이터를 서로 다른 논리적 그룹으로 분리해야 할 정도로 데이터를 배치해야 하는 경우에는 다른 데이터 저장소를 고려해야 합니다.왜냐하면 몽고는 훌륭하지만, 그들이 수집량에 제한을 둔다는 사실은 그들이 성능이 영향을 미치는 곳에 어떤 이론적인 한계가 있다는 것을 알고 있다는 것을 말해주기 때문입니다.

데이터 모양과 일치하는 상점을 고려해야 할 것 같습니다.예를 들어 Riak에는 응용 프로그램에서 가질 수 있는 '버킷'(이론적 최대치 없음)의 수가 무제한입니다.계정당 버킷 하나는 완벽하게 수행할 수 있지만, 이러한 방향으로 진행함으로써 쿼리 가능성을 일부 희생할 수 있습니다.

그렇지 않으면 유사한 그룹화의 관계형 모형을 따르는 것이 좋습니다.제가 보기에 Mongo는 관계형 데이터베이스와 키 값 저장소 사이의 중간 지점처럼 느껴집니다.즉, 관계형 데이터베이스 환경에서 제공되는 개념화하기가 더 쉽다는 것입니다.

수집품을 관리하는 데 막대한 비용이 드는 것 같습니다.11,000개 컬렉션에 약 150만 개의 문서가 있는 데이터베이스를 300개 컬렉션에 동일한 수의 문서가 있는 데이터베이스로 축소했습니다. 이로 인해 데이터베이스 크기가 8GB에서 1GB로 감소했습니다.저는 MongoDB의 내부 작업에 대해 잘 모르기 때문에 이것은 분명하지만 이러한 맥락에서 주목할 가치가 있다고 생각했습니다.

언급URL : https://stackoverflow.com/questions/9858393/limits-of-number-of-collections-in-databases