mongodb, 성능에 컬렉션 데이터 구조의 영향

컬렉션 데이터 구조를 정의하는 방법, 어떤 구조가 좋은 디자인이나 결정인지 판단하는 방법? 이는 데이터베이스 성능에 대한 후속 액세스에 영향을 L (니다. 예mongodb, 성능에 컬렉션 데이터 구조의 영향

경우처럼 하나 개의 데이터 :

{ 
    _id:'a' 
    index:1, //index 1~n 
    name:'john' 
}

N이 큰 데이터가 증착 크고 빈번한 것 것을 의미한다.

컬렉션 데이터 구조는 one dimensional object에있을 것입니다 :

{ 
    _id:'a' 
    index:1, 
    name:'john' 
} 
. 
. 
. 
{ 
    _id:'a' 
    index:99, 
    name:'jule' 
}

아니면 composite two-dimensional object :

{ 
    _id:'a' 
    info:[ 
     {index:1,name:'john'},...,{index:99,name:'jule'} 
    ] 
}

은, 그러나, 검색 방법은 쓰기에 편리 composite two-dimensional object 효과적으로 데이터의 수를 줄일 수없는

, 그리고 데이터베이스를 검색하거나 입금하는 효과를 실제로 줄이는 지 여부 등이 포함됩니다.

또는 데이터 수는 데이터베이스의 효율성에 영향을주는 핵심 요소입니다.

출처

2017-11-27 Albert Chen

단일 문서 내에서 배열을 무한대로 추가하려는 경우 나는 그것이 문서를위한 기억의 재 할당을 촉발시킬 것이라고 믿는다. 나는 또한 mongodb가 "건초 더미에서 바늘을 찾는 것"을 잘 알고 있다고 들었다. –

50,000 개의 합성 2 차원 물체와 같은 배열이 제한되어 있으며 50,000 개의 데이터로 분해되었다고 가정 해보십시오. 어느 것이 더 낫습니까? –

"더 나은"은 다른 사용 사례와 다른 것을 의미합니다. 귀하의 케이스에서 효과가있는 것은 다른 유스 케이스에서는 반드시 작동하지 않을 수도 있습니다.

MongoDB의의 문서 크기 제한 (16메가바이트) :

일반적으로, 인해, 큰 배열을 방지하는 것이 좋습니다.
큰 배열을 인덱싱하는 것은 일반적으로 성능이 좋지 않습니다.

그러나 이것은 일반적인 관찰 일뿐 특정 경험 법칙이 아닙니다. 데이터가 배열 기반의 표현에 적합하고 16MB의 문서 크기에 도달하지 못할 것이라는 확신이 든다면, 그 설계가 사용법에 따라 달라질 수 있습니다.

당신은 도움이 링크를 찾을 수 있습니다

스키마 디자인을 시작합니다 :

출처

2017-11-28 03:43:03

이것은'_id'를 검색 할 때 '복합 2 차원 객체'구조가 더 적합하다는 것을 의미합니다.'info'를 검색 할 때, 1 차원 객체가 더 적절합니까? –

@AlbertChen은 앱을 디자인하는 방법과 문서의 어떤 정보가 당신에게 더 관련이 있는지에 달려 있습니다. 옳고 그른 것은 없습니다. 게시 한 링크를 통해 아이디어를 얻을 수 있습니다. 한 가지 방법은 응용 프로그램 설계에서 데이터베이스가 어떻게 구성되어 있는지를 관리하는 것이지 일반적인 SQL 디자인과는 다른 방식으로 데이터를 구조화해야합니다. –

@AlbertChen 또한 생산에 투입하기 전에 예상되는 작업량으로 설계를 테스트해야합니다. 성능 문제가 있는지 확인하십시오. –

mongodb, 성능에 컬렉션 데이터 구조의 영향

답변

관련 문제