elasticsearch 실천편: 크로스 테이블join 조회

업무 발전에 따라 크로스 테이블join 조회 수요가 갈수록 많아지고 시스템의 느린 조회가 끊임없이 보고됨에 따라 ElasticSearch를 도입하여 집합 조회를 실현하는 것이 필수적이다.ES는 Lucene 기반의 검색 엔진으로 업무 메인 테이블과 보조 테이블의 색인 필드와 like 필드를 ES에 동기화하여 각 테이블의 색인 필드를 최종적으로 하나의 연합 색인으로 합쳐서 여러 테이블의 크로스 테이블 검색을 실현한다.
성능 요구 사항
검색 요구 응답 시간 평균 20ms 이내, 적중 캐시에 대한 2ms 이내 반환
단일 유형 및 다중 유형(다중 색인)
ES에서 하나의 Index는 하나의 라이브러리, 하나의 Type은 하나의 테이블로 이해할 수 있지만 6.0.0 버전부터 폐기되었습니다. 하나의 Index는 여러 Type(1 대 1 전용)에 대해 사용되지만 일부 업무는 5를 사용하고 있습니다.x 버전.
 
단일 유형
다중 유형(다중 색인)
이점
한 번의 요청으로 목표 정보를 전부 되돌려줍니다.냉열 격리 유지 보수 비용을 분리하여 제어할 수 있다.
색인 필드와 표 구조가 일일이 대응할 수 있다(직관적이고 간단하다).데이터 동기화 격리 단일;
결점
데이터 동기화 비용이 좀 높다.데이터 집합 시 일치성 문제가 있음;
데이터를 얻을 때 데이터 집합을 해야 한다. 예를 들어 한 번에 다섯 개의 테이블 인덱스를 연결하고 먼저 다섯 개의 테이블의 데이터를 추출한 다음에 교차해야 한다.성능에 영향을 미친다.데이터가 냉열 격리를 하면 데이터 분할을 할 때 다중 Type의 분할과 유지 보수 비용이 오히려 높다.
소결, 만약에 업무 장면이 성능을 위해 가능한 한 단일 Type 방안을 채택하는 것을 만족시켜야 한다!
색인 필드 수
비즈니스 마스터 테이블과 확장 정보 필드가 많기 때문에 이러한 정보를 ES에 모두 동기화하면 많은 문제가 발생합니다.

색인 필드가 너무 많으면 색인 파일도 커지고 검색 효율에 영향을 받는다

인덱스가 필요 없는 필드가 너무 많으면 새로운 io 문제를 초래할 수 있습니다

so, 가능한 한 사용자 정의 맵핑은 검색과 무관한 데이터를 저장하지 마십시오. 아래 이transRoute AndProducts 노드(json은 매우 크다)는 단어도 색인도 하지 않고 저장만 하는 것도 바람직하지 않습니다.

{
  "mappings": {
    "static_line": {
      "properties": {
        "productId": {
          "type":  "keyword"
        },
        "productType": {
          "type":  "keyword"
        },
		"startStationCode": {
          "type":  "integer"
        },
		"endStationCode": {
          "type":  "integer"
        },
		"status": {
          "type":  "keyword"
        },
		"startHubId": {
          "type":  "keyword"
        },
        "transRouteAndProducts": { 
          "enabled": false
        }
      }
    }
  }
}

그러면 상세한 정보를 얻을 수 있습니다. 예를 들어 얻은 주문 번호 목록을 mysql 각 확장표에 가서 구체적인 정보를 얻을 수 있습니다. 데이터 조립 효율이 낮으면 어떻게 합니까?
한 번의 완전한 주문 목록 추출 시간 = 데이터 검색 시간 + 데이터 조립 시간, 데이터 조립은 대량으로 가져와도 N (N 장의 주문 확장표가 있다면) 번, 병행해서 가져도 효율적이지 않습니다!
존관표는 괜찮은 방안인데, 얼마나 넓어야 할지 고민하는 것도 매우 중요하다!
건의: 넓은 시계 유지 보수 업무 메인 시계의 기본 정보와 강한 의존의 확장 정보.
Hbase를 도입하여 상세한 데이터를 조립하는 Hbase는 높은 신뢰성, 고성능, 열을 향한 신축 가능한 분포식 저장 시스템이다.HBase의 대용량 데이터를 MapReduce를 통해 처리할 수 있습니다.
이때 우리는 넓은 테이블을 Hbase에 저장할 수 있으며, 역사 데이터는 BulkLoad로 가져오고, 증량 데이터는 메시지로 동기화하며, 주문 번호는rowKey를 주문 번호로 한다.
그러면 어떻게 ES와 Hbase의 실시간성과 일치성을 보장합니까?
Change Data Capture Solution 방안을 사용하여 binlog를 감청한 후 메시지 대기열에 동기화하고 업무 소비 처리는 Es와 Hbase에 동기화할 수 있습니다.경보 감시 지표에 주목하고 실패 보상을 다시 시도하면 된다.
실시간 모니터링 지표 구축(차치)
메시지 처리 시간: binlogTime->reviceMqTime->bunsProcessTime->addEsorHbaseTime
만약 업무 소비의 幂等성을 보장하지 못한다면 소식의 난서, 데이터의 재방송 모니터링 보상 등은 매우 수동적일 것이다.여기에는 몇 가지 멱등 사고방식이 있다. 나의 다른 문장 멱등을 참고하여 의문을 풀 수 있다
elasticsearch는 크로스 테이블join 조회를 해결하는 좋은 수단입니다.