MongoDB - 하나의 콜렉션 인덱스 사용하기

Question

그래, Mongodb에서 점점 더 많이 발전한다. 다중 콜렉션과 인덱스를 가진 하나의 커다란 콜렉션이 필요하다. (컬럼과 필드는 테이블 형식의 데이터와 달리 각 문서마다 다를 수 있기 때문에). 가능한 가장 효율적인 방법으로 코드를 작성하고 재사용 가능한 코드를 개발하려고하면 모든 문서에 대해 하나의 콜렉션을 사용할 수 있고 필드의 인덱스 만 사용할 수 있습니다. 인덱스를 가진 하나의 콜렉션에 모든 문서를 가짐으로써, 모든 콜렉션은 동일한 콜렉션에 삽입되기 때문에 모든 폼 처리 코드와 다른 코드를 재사용 할 수 있습니다. 예를 들어

:

내가 접촉 관리자를 개발하고 내가 연락처 "개인"과 "기업"의 두 가지 유형이 있다고 할 수 있습니다. 저의 원래 생각은 개인이라고 불리는 컬렉션과 비즈니스라고하는 두 번째 컬렉션을 만드는 것이 었습니다. 그러나 그것은 sql에서 개발하는 데 익숙했기 때문에 어디에서 열이 각 테이블마다 다를 수 있기 때문에 적절할 것입니다. 문서 dbs의 유연성에 대해 생각하기 시작할수록 더 많은 것을 생각하기 시작했습니다. "정말 이걸로 두 개의 모음이 필요합니까?" 방금 "연락처 유형"이라고하는 각 문서에 필드를 추가하고 색인을 작성하면 실제로 두 개의 모음이 필요합니까? 각 문서의 필드/열이 모두 같을 필요는 없으므로 (SQL과 같이) "문서 유형"필드와 해당 필드의 인덱스가있는 한 각 문서는 고유 한 필드를 가질 수 있습니다.

그렇다면 나는 "개인"및 "비즈니스"에 대해 하나의 컬렉션 만 있으면 "사용자"또는 "연락처 기록"또는 다른 데이터에 대한 별도의 컬렉션이 필요하다고 생각하고 생각하기 시작했습니다. . 이론적으로 나는 한 번에 컬렉션 전체 솔루션을 구축 할 수 없으며 "사용자", "개별 연락처", "비즈니스 연락처", "연락처 기록"과 같은 "유형"및 인덱스를 지정하는 각 문서의 필드를 가질 수 없습니다 "등, 다른 문서와 관련된 문서 인 경우"부모 키/외부 "ID 필드에서 색인을 생성 할 수 있습니다 ...

이렇게하면 양식 처리 코드가 모두 동일합니다 (동일한 콜렉션에 삽입). 이것은 많은 코딩을 절약 할 수 있지만 인덱스와 보조 인덱스를 사용하여 db가 여전히 빠르게 실행되고 컬렉션이 커짐에 따라 미래의 문제가 발생하지 않도록하고 싶습니다. 상상할 수 있듯이 모든 것이 하나의 컬렉션에 있다면 사용자 기반이 커짐에 따라이 컬렉션에는 수십만 개의 문서가있을 수 있지만 성능을 최적화하려면 인덱스와 보조 인덱스가 필요합니다.

제 질문은 : 이것은 mongodb 개발자들이 사용하는 일반적인 방법입니까? 그 이유는 무엇? 만약 있다면, 낙오점은 무엇입니까? 이것이 일반적으로 사용되는 방법 인 경우이 방법을 사용하는 것에 대해서도 긍정적 인 반응을 나타내십시오. 고맙습니다.

Answer 1

일반적으로 MongoDB 및 NoSQL은 데이터를 비정형 화하고 조인을 줄이는 것에 관한 것입니다. 그것은 일반적인 SQL 사고에 반대합니다.

불필요한 복잡성과 성능 오버 헤드가 발생하기 때문에 별도의 컬렉션을 갖고 싶지 않은 이유가 있습니다. 예를 들어 모든 연락처를 알파벳 순서로 표시하는 화면을 원할 경우를 생각해보십시오. 연락처에 대해 하나의 컬렉션 만 있으면 정말 쉽지만 컬렉션이 두 개인 경우 더 복잡한 제안이됩니다.

어디에서 응용 프로그램에 연락처를 저장하고있는 사용자가 여러 명있는 경우입니다. 그러면 각 사용자에 대해 하나의 컬렉션을 갖게됩니다. 이렇게하면 사용자 연락처를 쉽게 추출 할 수 있습니다.

Answer 2

이것은 Mongo의 중요한 점이며 대답은 과학보다 조금 더 예술입니다. 거대한 문서들로 가득 찬 컬렉션 하나는 확실히 Mongo의 많은 기능들에 대해 작동하기 때문에 반 패턴입니다.

예를 들어, 문서를 검색 할 때 컬렉션에서 전체 문서 만 검색 할 수 있습니다 (사실은 아니지만 대부분). 따라서 거대한 문서가 있으면 매번 거대한 문서를 가져옵니다. 또한 거대한 문서를 가지고 있으면 최상위 수준의 문서 만 각 컬렉션에서 색인을 생성 (따라서 샤드)되기 때문에 샤딩의 유연성이 떨어집니다. 값을 문서 깊숙이 인덱스 할 수 있지만 인덱스 값은 최상위 레벨 문서와 연관됩니다.

처음에는 Mongo로 이동하여 참조 무결성을 많이 잃어 버렸기 때문에 순전히 관계형으로가는 것도 반대 패턴입니다. 또한 모든 조인은 응용 프로그램 메모리에서 수행되므로 각 조인은 전체 왕복 (느린)을 필요로합니다.

그래서 대답은 사이에 뭔가를하는 것입니다. 나는 개인을위한 컬렉션과이 경우 비즈니스를위한 다른 컬렉션을 원할 것이라고 생각합니다. 왜냐하면 기업이 대량의 대량 데이터를 가질 수있을만큼 충분한 메타 데이터를 보유하고있는 것처럼 보였기 때문입니다. (또한 개인 - 비즈니스 관계는 다 대다 (many-to-many)처럼 보입니다. 그러나 개인에게는 first 및 last 속성이있는 Name 개체가있을 수 있습니다. 이름을 별도의 컬렉션으로 만드는 것은 좋지 않은 아이디어입니다.

10gen에서 스키마 설계에 대한 몇 가지 정보 : http://www.mongodb.org/display/DOCS/Schema+Design

편집

또한, 몽고 거래에 대한 제한된 지원이 - 원자 집합체의 형태를. mongo에 개체를 삽입하면 개체 전체가 삽입되거나 삽입되지 않습니다. 따라서 응용 프로그램 도메인에서는 특정 개체간에 일관성이 필요합니다. 동일한 개체/컬렉션에 보관해야 할 수 있습니다.

예를 들어, (FirstName, LastName 및 MiddleInitial을 포함)을 User 항상 Name 목적을 가지고 필요한 응용 프로그램을 고려하십시오. 이 어떤 식 으로든 Name이 삽입되어 삽입 된 경우 데이터가 손상된 것으로 간주됩니다. RDBMS에서는 조작 주위에 트랜잭션을 랩핑하여 User 및 Name을 삽입합니다. Mongo에서는 Name이 동일한 문서 (집계)에 User이라는 것을 확인하여 동일한 효과를 얻습니다.

귀하의 사례는 비즈니스 사례를 이해할 수 없으므로 다소 명확하지 않습니다. 마음에 떠오르는 한 가지 사실은 몽고가 유산을 훌륭하게 지원한다는 것입니다. 모든 사용자, 개인 및 잠재적 비즈니스를 응용 프로그램이 모델링 된 방식에 따라 동일한 컬렉션에 포함시키는 것이 이치에 맞을 수도 있습니다. 한 개인이 많은 대화 상대를 갖고 있다면 개인에게 ID 배열을 갖기를 원할 것입니다. 응용 프로그램에서 연락처를 빠르게 미리 볼 것을 요구하는 경우 개인의 일부를 복제하고 연락처 개체 배열을 저장하는 것이 좋습니다.

RDBMS 사고에 익숙하다면 모든 데이터가 항상 일관성이 있어야한다고 생각할 것입니다. 진실은, 그것은 아마 완전히 진실하지 않다이다. 도메인에 원자 응집체를 적용하는이 개념은 최근 DDD 공동체에 의해 널리 전파되었습니다. 비즈니스 사용자와 마찬가지로 깊이있는 도메인을 볼 때 일관성 경계가 달라야합니다.