Elasticsearch 확장 Elasticsearch는 로그 분석, 텍스트 검색, 실시간 분석 등에 사용하기 쉽게 시작할 수 있는 NoSQL 검색 및 분석 엔진입니다. 즉, Elasticsearch의 내부에는 최적의 성능을 달성하기 위해 활용해야 할 수단이 많은 복잡한 분산 시스템이 있습니다. 이 블로그에서는 느린 인덱싱, 검색 속도, 샤드 및 인덱스 크기 조정, 멀티 테넌시를 포함하여 규모에 따른 일반적인 Elasticsearch 성능 문제에 대한 솔루션을 안내합니다. 많은 솔루션은 대규모 시스템 운영 경험이 있는 엔지니어링 리더 및 설계자와의 인터뷰 및 토론에서 비롯됩니다. Elasticsearch에서 인덱싱 성능을 어떻게 향상시킬 수 있나요? 쓰기 처리량이 높은 워크로드를 처리할 때 Elasticsearch를 조정하여 인덱싱 성능을 높여야 할 수도 있습니다. 작업이 애플리케이션의 검색 성능에 영향을 미치지 않도록 인덱싱을 위한 적절한 리소스를 확보하기 위한 몇 가지 모범 사례를 제공합니다. 늘리기: Elasticsearch는 인덱스를 새로 고쳐서 새 데이터를 검색할 수 있게 만듭니다. 인덱스가 지난 30초 동안 쿼리를 수신하면 새로 고침이 1초마다 자동으로 발생하도록 설정됩니다. 새로 고침 간격을 늘려 인덱싱을 위해 더 많은 리소스를 예약할 수 있습니다. 새로 고침 간격 사용: 대규모 데이터를 수집할 때 Update API를 사용하여 인덱싱하는 데 것으로 알려져 있습니다. 이러한 시나리오에서는 대량 API를 사용하여 보다 리소스 효율적인 방식으로 데이터 인덱싱 속도를 높일 수 있습니다. 대량 API를 사용하더라도 클러스터 성능을 방해하지 않도록 인덱싱된 문서 수와 대량 요청의 전체 크기를 알고 싶을 것입니다. Elastic에서는 대량 크기를 벤치마킹할 것을 권장하며 일반적으로 입니다. Bulk API 몇 주가 걸리는 5~15MB/대량 요청 늘리기: 처리되지 않은 인덱싱 요청에 대한 메모리 제한을 기본값인 힙의 10% 이상으로 늘릴 수 있습니다. 이는 인덱싱이 많은 워크로드에 권장될 수 있지만 메모리를 많이 사용하는 다른 작업에 영향을 미칠 수 있습니다. 인덱스 버퍼 크기 복제 비활성화: 인덱싱 속도를 높이기 위해 복제를 0으로 설정할 수 있지만 Elasticsearch가 워크로드에 대한 기록 시스템인 경우에는 권장되지 않습니다. : 삽입, 업데이트 및 삭제를 수행하려면 전체 문서를 다시 인덱싱해야 합니다. CDC 또는 트랜잭션 데이터를 Elasticsearch로 스트리밍하는 경우 다시 색인화할 데이터가 적기 때문에 더 적은 양의 데이터를 저장하는 것이 좋습니다. 내부 upsert 및 데이터 변형 제한 데이터 구조 단순화: 와 같은 데이터 구조를 사용하면 쓰기 및 인덱스가 증가한다는 점을 명심하세요. 필드 수와 데이터 모델의 복잡성을 단순화하여 인덱싱 속도를 높일 수 있습니다. 중첩된 개체 Elasticsearch에서 검색 속도를 높이려면 어떻게 해야 합니까? 쿼리를 실행하는 데 너무 오랜 시간이 걸린다면 이는 데이터 모델을 단순화하거나 쿼리 복잡성을 제거해야 함을 의미할 수 있습니다. 고려해야 할 몇 가지 영역은 다음과 같습니다. 생성 : 두 개의 낮은 카디널리티 필드 값을 병합하여 쉽게 검색할 수 있는 높은 카디널리티 필드를 만듭니다. 예를 들어, 쿼리에 대해 일반적으로 필터링하는 두 개의 필드인 경우 우편번호 및 월이 포함된 필드를 병합할 수 있습니다. 복합 인덱스 문서의 활성화: Elasticsearch는 결과를 반환하기 위해 모든 샤드에 쿼리를 브로드캐스트합니다. 사용자 지정 라우팅을 사용하면 데이터가 어느 샤드에 있는지 확인하여 쿼리 실행 속도를 높일 수 있습니다. 즉, 사용자 지정 라우팅을 채택할 때 핫스팟을 주의 깊게 살펴보고 싶을 것입니다. 사용자 정의 라우팅 구조화된 검색을 위해 사용: ID, 우편번호 등 콘텐츠를 기준으로 필터링하려는 경우 더 빠른 검색을 위해 정수 유형이나 기타 숫자 필드 유형보다는 키워드 필드 유형을 사용하는 것이 좋습니다. 키워드 필드 유형 에서 벗어나기: 상위-하위 관계는 Elasticsearch의 부족에 대한 좋은 해결 방법이며 수집 속도를 높이고 재인덱싱을 제한하는 데 도움이 되었습니다. 결국 조직은 이 접근 방식으로 인해 메모리 제한에 도달하게 됩니다. 이러한 경우 데이터 비정규화를 수행하여 쿼리 성능을 가속화할 수 있습니다. 상위-하위 및 중첩 개체 조인 지원 규모에 맞게 Elasticsearch 샤드와 인덱스의 크기를 어떻게 조정해야 합니까? Elasticsearch의 많은 확장 문제는 결국 샤딩 및 인덱싱 전략으로 귀결됩니다. 보유해야 하는 샤드 수 또는 샤드의 크기에 대한 모든 전략에 맞는 하나의 크기는 없습니다. 전략을 결정하는 가장 좋은 방법은 균일한 프로덕션 워크로드에서 테스트와 벤치마크를 실행하는 것입니다. 고려해야 할 몇 가지 추가 조언은 다음과 같습니다. 사용: 강제 병합 API를 사용하여 각 샤드의 세그먼트 수를 줄입니다. 세그먼트 병합은 백그라운드에서 자동으로 이루어지며 삭제된 문서는 모두 제거됩니다. 강제 병합을 사용하면 오래된 문서를 수동으로 제거하고 성능을 높일 수 있습니다. 이는 리소스 집약적일 수 있으므로 사용량이 가장 많은 동안에는 발생하지 않아야 합니다. 강제 병합 API 주의: Elasticsearch에는 샤드별 리소스 활용도를 이해하고 샤드 배치를 결정할 때 이를 고려하는 좋은 방법이 없습니다. 결과적으로 핫 샤드가 발생할 수 있습니다. 이러한 상황을 방지하려면 데이터 노트보다 더 많은 샤드를 갖고 데이터 노드보다 작은 샤드를 갖는 것을 고려할 수 있습니다. 로드 불균형 사용: 시간 기반 인덱스는 보존 기간에 따라 클러스터의 인덱스 및 샤드 수를 줄일 수 있습니다. Elasticsearch는 또한 롤오버 인덱스 API를 제공하므로 연령이나 문서 크기에 따라 새 인덱스로 롤오버하여 리소스를 확보할 수 있습니다. 시간 기반 인덱스 멀티 테넌시를 어떻게 설계해야 합니까? 다중 테넌트에 대한 가장 일반적인 전략은 고객 또는 테넌트당 하나의 인덱스를 보유하거나 사용자 지정 라우팅을 사용하는 것입니다. 워크로드에 대한 전략을 평가하는 방법은 다음과 같습니다. 고객 또는 테넌트별 인덱스: 고객별로 별도의 인덱스를 구성하는 것은 사용자 기반이 수백에서 수천 명에 이르는 소규모 회사 및 고객이 데이터를 공유하지 않는 경우에 적합합니다. 각 고객이 자신만의 스키마를 갖고 있고 더 큰 유연성이 필요한 경우 고객별로 인덱스를 갖는 것도 도움이 됩니다. 사용자 정의 라우팅: 사용자 정의 라우팅을 사용하면 문서가 상주하는 샤드(예: 고객 ID 또는 테넌트 ID)를 지정하여 문서를 인덱싱할 때 라우팅을 지정할 수 있습니다. 특정 고객을 기반으로 쿼리하는 경우 더 빠른 응답 시간을 위해 쿼리가 고객 데이터가 포함된 샤드로 직접 이동됩니다. 사용자 지정 라우팅은 고객 전체에 일관된 스키마가 있고 고객이 많을 때 좋은 접근 방식입니다. 이는 부분 유료화 모델을 제공할 때 일반적입니다. Elasticsearch를 확장하거나 확장하지 않으려면! Elasticsearch는 로그 분석 및 텍스트 검색 사용 사례를 위해 설계되었습니다. 대규모 실시간 분석을 위해 Elasticsearch를 사용하는 많은 조직은 쿼리 복잡성 및 데이터 수집 대기 시간 제한을 포함하여 성능 또는 비용 효율성을 유지하기 위해 절충을 해야 합니다. 사용 패턴을 제한하기 시작하거나 새로 고침 간격이 SLA를 초과하거나 함께 결합해야 하는 데이터 세트를 더 추가하는 경우 Elasticsearch에 대한 대안을 찾는 것이 합리적일 수 있습니다. Rockset은 대안 중 하나이며 대규모 실시간 스트리밍 데이터 수집 및 대기 시간이 짧은 쿼리를 위해 특별히 제작되었습니다. 방법을 알아보고 두 시스템 간의 살펴보세요. Elasticsearch에서 마이그레이션하는 아키텍처 차이점을
