2013-06-21 2 views
1

여러 유형의 문서 색인 작성이 각 유형의 항목 수에 불균형이있는 단일 색인에 성능 영향을 이해하고 싶습니다 (한 유형에는 수백만 개가 있으며 다른 유형에는 수천 개의 문서). 일부 인덱스에서 문제를 발견하고 유형이 단일 인덱스 내에서 개별적으로 인덱싱되는지 여부를 판단하는 데 도움이됩니다. 유형이 각 테이블이 효과적으로 분리 된 관계형 데이터베이스의 라인을 따라 개별적으로 색인화된다고 가정 할 수 있습니까?ElasticSearch 유형 및 색인 성능

위의 답변이 아니오이고 유형이 효과적으로 모두 일괄 처리되는 경우 나머지 부분을 정리하여 좀 더 자세하게 입력 해 보겠습니다.

이 예제의 유스 케이스는 트위터 사용자를위한 트윗을 캡처합니다 (명확하게하기 위해 소유자라고 부릅니다). 나는 트위터 소유자 당 하나의 색인을 가진 멀티 테넌트 환경을 가지고있다. 각 타임 라인 유형이를 갖는,

  • 내가 단일 인덱스로 각 타임 라인에서 트윗 (언급, 직접적인 메시지, 내 트윗과 전체 '집'타임 라인)을 캡처 : 그건 하나의 소유자에 집중했다 ElasticSearch의 다른 매핑
  • 각 트윗은 상위 매핑을 사용하여 트윗 (소유자 일 수도 있고 아닐 수도 있음)을 작성한 사용자 인 부모 유형을 나타냅니다. 모든 타임 라인 유형에 대해 하나의 '사용자'유형 만 있습니다.
  • 단일 쿼리에서 한 소유자 만 검색하고 여러 인덱스를 검색 할 필요가 없습니다.
  • 홈 타임 라인 소유자의 트윗이 수백 또는 수천의 결과를 가져올 수있는 수백만 개의 트윗을 캡처 할 수 있습니다.
  • 사용자 문서는 트위터 타임 라인 이외의 정보로 정기적으로 업데이트되므로 가능한 경우 상황을 피하고 싶습니다. 동일한 사용자 개체의 여러 사본을 여러 색인에 걸쳐 동기화 유지

나는 많은 것을 알아 챘다. 수백만 개의 문서가 색인 된 '홈 타임 라인'유형을 제외하고 수천 개의 항목이있는 유형 만 남겨도 수백만 개의 문서가 포함 된 색인에 대한 질의 응답이 줄어 들었습니다. 트윗과 사용자 간의 부모 - 자식 관계로 인해 유형을 별도의 색인으로 분할하지 않아도됩니다.

문제가 특정 인덱스의 문서 총 수, 'has_child'필터링 된 쿼리, 쿼리 또는 패싯의 다른 잘못된 디자인 또는 무언가와 관련이 있는지 이해할 수있는 방법이 있습니까? 그밖에?

모든 의견을 보내 주시면 감사하겠습니다.

편집 트윗 타임 라인별로 저장되어있는 문을 명확히하기 위해. 즉, 표준 twitter.com UI에서 볼 수있는 것과 일치하는 home_timeline, my_tweets_timeline, mentions_timeline, direct_messages_timeline 등에 대해 정의 된 ElasticSearch 유형이 있음을 의미합니다. 따라서 겹치는 부분이 있지만 트윗 집합 사이에는 자연스러운 갈등이 있습니다.

나는 has_child 쿼리를 확인하기 위해 다시 방문했으며,이 시점에서 분명히 붉은 청어입니다. 수천 개의 행 (my_tweets_timeline)이있는 유형을 쿼리 할 때에도 큰 인덱스에 대한 기본 쿼리는 훨씬 느립니다.

+0

내 대답은 불완전하다고 생각하지만 질문도 마찬가지입니다. 사용하고있는'has_child' 쿼리와 관계가있는 다른 문서의 예를 제공해주십시오. 특히 "홈 타임 라인"유형을 제외시키는 것이 무엇을 의미하는지 확신 할 수 없었습니다 - 나는 단지 트윗과 사용자 유형에 대한 이해가있어 혼란 스러웠습니다. –

+0

Paul, 일정을 명확히하기 위해 질문을 약간 편집했습니다. 또한 쿼리를 살펴보기 위해 has_child는 일반 쿼리보다 성능 문제가 더 이상 발생하지 않습니다. – Phil

+1

흠, 알았어. 다음은 일반적인 확장 성 문제와 같습니다. 다른 사람이 전화를 걸 수 있기를 바랍니다. +1 –

답변

1

유형이 각 테이블이 효과적으로 분리 된 관계형 데이터베이스의 라인을 따라 개별적으로 인덱싱된다고 가정 할 수 있습니까?

아니요, 유형은 모두 예상 한대로 하나의 색인으로 모두 정리됩니다.

문제가 특정 인덱스의 문서 총 수, 'has_child'필터링 된 쿼리 작업, 쿼리 또는 패싯의 다른 잘못된 디자인과 관련이 있는지 이해할 수있는 방법이 있습니까? 또는 다른 것?

인덱스의 총 문서 수는 분명히 하나의 요소입니다. has_child 쿼리가 특히 느린지 여부는 또 다른 질문입니다. has_child 쿼리의 성능을 예를 들어 term 쿼리와 비교해보십시오. 모든 _id 값이 빠른 조회를 지원하므로 충분한 메모리가 거기에 있는지 확인하기 위해 메모리 (힙)에로드되어, 현재 구현으로

다음 has_child documentation는 "메모리 고려 사항"에서 하나의 단서를 제공합니다.

잠재적 인 수백만 명의 어린이가있는 has_child 검색어에는 많은 양의 메모리가 필요합니다. 그러한 작업에 충분한 메모리가 있는지 확인하거나 has_child의 필요성을 제거하는 재 설계를 고려하십시오.

+0

이 답변의 첫 번째 부분에 대한 응답으로 _type에 따라 색인을 최적화 할 수있는 방법이 있습니까? 내 원래의 질문은 그 쿼리가 상당히 정기적 인 쿼리보다 느린 것으로 언급 언급하지 않았지만, has_child 메모리 문제를 이해합니다. 좋은 설명. – Phil