MVC 패턴을 사용하여 개발 된 응용 프로그램이 있으며 이제 여러 모델을 인덱싱하고 싶습니다. 즉, 각 모델의 데이터 구조가 다릅니다.
-
각 모델마다 하나씩 또는 여러 모델에서 동일한 색인 내에 유형이있는 다중 인덱스를 사용하는 것이 더 낫습니까? 두 가지 방법 모두 내가 생각하는 다른 검색어가 필요합니다. 나는 이것을 시작했다.
-
데이터 세트가 작거나 큰 경우 두 개념간에 성능 차이가 있습니까?
누군가 나에게 그 목적을 위해 좋은 샘플 데이터를 추천 할 수 있다면 두 번째 질문을 직접 테스트 할 것입니다.
답변
두 방법 모두에 다른 의미가 있습니다.
Elasticsearch의 기본 설정을 사용한다고 가정 할 때 각 모델에 대해 1 개의 인덱스를 사용하면 1 개의 인덱스에 5 개의 샤드가 사용되고 5 개의 데이터 모델에 25 개의 샤드가 사용되므로 샤드 수가 크게 증가합니다. 1 인덱스에 5 개의 객체 유형이 있으면 여전히 5 개의 샤드를 사용합니다.
각 데이터 모델을 인덱스로 사용할 때의 의미 :
- 데이터가 다른 인덱스에 분산되므로 각 샤드에서 데이터 양이 작아야하므로 인덱스 내에서 효율적이고 빠른 검색이 가능합니다.
- 쿼리가 인덱스를 통해 더 많은 샤드로 보내지고 컴파일되어 사용자에게 다시 보내지기 때문에 2 개 이상의 인덱스에서 데이터 모델 조합을 검색하면 오버 헤드가 발생합니다.
- 추가 샤드가 생성 될 때마다 더 많은 스토리지가 발생하고 성능 향상이 미미하기 때문에 데이터 세트가 작은 경우 권장되지 않습니다.
- 전용 샤드가 특정 데이터를 저장하고 Elasticsearch를 쉽게 처리 할 수 있으므로 데이터 세트가 크고 쿼리를 처리하는 데 시간이 오래 걸리는 경우 권장됩니다.
인덱스 내에서 각 데이터 모델을 개체 유형으로 사용하는 의미 :
- 인덱스의 5 개 샤드 내에 더 많은 데이터가 저장되므로 여러 데이터 모델에서 쿼리 할 때 오버 헤드 문제가 줄어드는 반면 샤드 크기는 훨씬 커집니다.
- 필터링 할 문서가 더 많기 때문에 샤드 내 더 많은 데이터가 Elasticsearch를 검색하는 데 시간이 더 오래 걸립니다.
- 1 테라 바이트의 데이터를 처리하고 있고 Elasticsearch 매핑에서 여러 인덱스 또는 여러 샤드에 데이터를 배포하지 않는 경우 권장되지 않습니다.
- 각 샤드가 하드웨어에서 공간을 차지하므로 성능이 약간 떨어지기 때문에 스토리지 공간을 낭비하지 않기 때문에 소규모 데이터 세트에 권장됩니다.
너무 많은 데이터와 작은 데이터가 무엇인지 묻는다면? 일반적으로 프로세서 속도와 하드웨어의 RAM, Elasticsearch에 대한 매핑의 각 변수 내에 저장하는 데이터의 양 및 쿼리 요구 사항에 따라 다릅니다. 쿼리에 많은 패싯을 사용하면 응답 시간이 크게 느려집니다. 이에 대한 직접적인 대답은 없으며 필요에 따라 벤치마킹해야합니다.
답변
조나단의 대답은 당시에는 옳았지만, 전 세계는 발전해 왔으며 이제 ElasticSearch를 사용하는 사람들은 여러 유형에 대한 지원을 중단 할 장기적인 계획을 가지고있는 것 같습니다.
원하는 곳 : 부모 / 자식을 지원하면서 Elasticsearch에서 유형 개념을 제거하려고합니다.
따라서 새 프로젝트의 경우 인덱스 당 단일 유형 만 사용하면 최종적으로 ElasticSearch 6.x로 쉽게 업그레이드 할 수 있습니다.
답변
조나단의 대답은 훌륭합니다. 고려해야 할 몇 가지 다른 점을 추가하려고합니다.
- 선택한 솔루션별로 샤드 수를 사용자 지정할 수 있습니다. 기본 샤드 15 개가있는 하나의 인덱스가 있거나 5 개의 샤드에 대해 3 개의 인덱스로 분할 할 수 있습니다. 성능 관점이 변경되지 않습니다 (데이터가 균등하게 분산되어 있다고 가정)
- 데이터 사용에 대해 생각하십시오. 즉. kibana를 사용하여 시각화하는 경우 특정 색인을 포함 / 제외하는 것이 더 쉽지만 대시 보드에서 유형을 필터링해야합니다.
- 데이터 보존 : 애플리케이션 로그 / 메트릭 데이터의 경우 다른 보존 기간이 필요한 경우 다른 인덱스를 사용하십시오.
답변
위의 답변 모두 훌륭합니다!
색인에 여러 유형의 예를 추가하고 있습니다. 라이브러리에서 책을 검색하는 앱을 개발한다고 가정합니다. 도서관 소유자에게 물어볼 질문은 거의 없습니다.
질문 :
-
몇 권의 책을 보관할 계획입니까?
-
어떤 종류의 책을 도서관에 보관 하시겠습니까?
-
책을 어떻게 검색 하시겠습니까?
답변:
-
50k – 70k 권의 책을 저장할 계획입니다.
-
15k-20k 기술 관련 서적 (컴퓨터 과학, 기계 공학, 화학 공학 등), 15k의 역사 서적, 10k의 의료 과학 서적을 보유하게됩니다. 언어 관련 서적 10k (영어, 스페인어 등)
-
저자 이름, 저자 성, 출판 연도, 출판사 이름으로 검색합니다. (이것은 색인에 어떤 정보를 저장해야하는지에 대한 아이디어를 제공합니다)
위의 답변에서 우리는 인덱스의 스키마가 다음과 같이 보일 것이라고 말할 수 있습니다.
// 이것은 단지 예제를위한 정확한 매핑이 아닙니다.
"yearOfPublish":{
"type": "integer"
},
"author":{
"type": "object",
"properties": {
"firstName":{
"type": "string"
},
"lastName":{
"type": "string"
}
}
},
"publisherName":{
"type": "string"
}
}
위의 목적을 달성하기 위해 Books라는 하나의 인덱스를 만들 수 있으며 다양한 유형을 가질 수 있습니다.
색인 : 도서
유형 : 과학, 예술
또는 책이 더 많은 경우 기술, 의학, 역사, 언어와 같은 여러 유형을 만들 수 있습니다.
여기서 주목해야 할 것은 스키마는 비슷하지만 데이터는 동일하지 않다는 것입니다. 그리고 다른 중요한 것은 저장하는 총 데이터입니다.
위의 내용이 인덱스에서 다른 유형으로 갈 때 도움이되기를 바랍니다. 스키마가 다르면 다른 인덱스를 고려해야합니다. 적은 데이터를위한 작은 인덱스. 빅 데이터에 대한 빅 인덱스 🙂
답변
