분산 검색 엔진으로서 ES는 확장 기능 및 검색 기능 측면에서 타의 추종을 불허합니다. 그러나 실시간에 가까운 스토리지 시스템으로서 샤딩 및 복제 설계 원칙으로 인해 OLTP와 경쟁할 수 없습니다. (온라인 트랜잭션 처리) 시스템은 데이터 대기 시간 및 일관성 측면에서 볼 수 있습니다.
이로 인해 해당 데이터는 일반적으로 2차 필터링 및 분석을 위해 다른 스토리지 시스템에서 동기화됩니다. 이것은 핵심 노드, 즉 ES 데이터의 동기 쓰기 방법을 소개합니다. 이 기사에서는 MySQL 동기 ES 방법을 소개합니다.
MySQL 데이터를 ES에 쓸 때 가장 먼저 염두에 두어야 할 것은 Binlog를 사용하여 ES에 직접 쓰는 것입니다. 그러나 더 많은 차원을 고려하면 이 방법의 몇 가지 단점을 발견할 수 있습니다. 따라서 또 다른 방법, 즉
[RocketMQ
+ Flink Consumer + ES Bulk] 통합 생태학이 있습니다. 동기화 지연, 소비 특성, ES 쓰기 성능 및 시스템 재해 허용성이라는 네 가지 측면에서 이 두 가지 액세스 방법을 평가할 것입니다. 모두에게 영감을 주고 귀하의 비즈니스에 적합한 동기화 방법을 선택하세요.
ES 기본 작문 원리
ES 쓰기는 먼저 특정 크기의 세그먼트를 형성한 후 주기적으로 작은 데이터 세그먼트를 큰 데이터 세그먼트로 병합하여 메모리 조각화를 줄이고 쿼리 효율성을 높이는 추가형 쓰기 프로세스입니다. 인덱스는 동일한 유형의 문서를 저장하며, 각 샤드는 N개의 세그먼트로 구성되며, 이는 가장 작은 것입니다. ES의 처리 단위 Segment는 ES의 가장 작은 데이터 처리 단위이며 각 Segment는 독립적인 역 인덱스입니다.
ES 쓰기는 실제로 동일한 세그먼트(메모리)에 데이터를 지속적으로 쓴 다음 새로 고침을 트리거하여 세그먼트를 OS 캐시(기본값 1초)로 새로 고칩니다. 이때 데이터를 쿼리할 수 있으며 OS 캐시는 운영 체제에 의해 Flush를 트리거합니다. . 작업은 디스크에 유지됩니다.
생각하게 됩니다: ES는 데이터가 손실되지 않도록 어떻게 보장합니까? 추가 쓰기의 장점과 단점은 무엇입니까? 추가 쓰기는 데이터 업데이트 문제를 어떻게 처리합니까? MySQL은 어떤 작성 방법에 속합니까? 이 글의 초점은 여기에 있지 않고, 글을 따로 읽어보실 수 있습니다.
ES 기본 개념
ES 직접 쓰기
ES 직접 연결 쓰기의 장점은 경로가 짧고 종속 구성 요소가 거의 없다는 점입니다. 또한 Dsyncer(이기종 스토리지 변환 시스템)는 일반적으로 완전한 전류 제한 재시도 메커니즘을 제공하므로 소비 지연과 소비 데이터 무결성이 모두 보장됩니다. 보장됩니다.
결점:
-
현재 ES 재해복구 전산실은 모두 독립적으로 구축되어 독립적인 읽기 및 쓰기 모드로 접근하기가 쉽지 않습니다. 여러 전산실을 동시에 사용하면 재해 복구 효과를 얻을 수 없습니다. Binlog-->Dsyncer 일반적으로 하나의 MySQL 테이블은 하나의 변환 작업에 해당합니다. 여러 개의 컴퓨터실을 작성하기 위해 여러 개의 변환 작업을 반복적으로 시작하면 다소 어리석은 것처럼 보입니다.
-
자신의 비즈니스 시나리오에 동일한 레코드의 동시 쓰기가 포함되지만 쓰기가 모두 Binlog에서 발생하지 않을 수 있는 경우 순서가 지정된 대기열이 보장되지 않기 때문에 전역적으로 ES에 직접 쓰기를 고려하면 쓰기 충돌이 발생할 가능성이 더 높습니다.
Flink를 통한 ES 통합 시스템 구축
Flink는 ES 통합 시스템을 구축합니다. 즉, Flink는 RocketMQ 실시간 데이터 스트림을 모니터링하여 데이터 파티션의 질서를 보장할 뿐만 아니라 ES의 일괄 쓰기 기능을 최대한 활용합니다. 일괄 쓰기 성능은 단일 쓰기 성능보다 몇 배 더 높습니다. 동시에 Flink 자체의 내결함성 덕분에 비정상적인 시나리오에서도 데이터의 궁극적인 일관성이 보장될 수 있습니다.
이점
:
-
MQ를 사용하면 다중 머신룸 ES 클러스터에 더 빠르게 액세스할 수 있으며 쓰기가 분리됩니다. 세 컴퓨터실의 소비자는 단일 컴퓨터실에 장애가 발생하면 사용 가능한 컴퓨터실이 있는 한 서로 독립적으로 데이터를 씁니다. 예, 재해 복구 계획은 간단하고 명확합니다 .
-
네트워크 지터와 같은 문제로 인해 ES가 일시적으로 쓰기에 실패하는 경우 RocketMQ는 다른 클러스터의 쓰기에 영향을 주지 않고 일시적으로 메시지를 저장하며 Flink는 소비 스냅샷을 저장하고 성공할 때까지 계속 재시도하므로 데이터의 최종 일관성이 더 잘 보장됩니다. .섹스 ;
-
여러 데이터 원본에서 작성하면 전역 파티션 일관성이 보장됩니다.
단점
:
-
더 많은 구성 요소를 사용하면 전체 링크의 데이터 동기화 지연이 증가하고 ES의 기본 새로 고침 빈도는 초당 한 번입니다. 테스트 후 정상적인 상황에서 링크의 데이터 지연은 완전히 허용되지 않는 수준입니다.
-
더 많은 구성 요소에 의존하며 기본 구성 요소의 안정성에 대한 요구 사항이 더 높습니다. RocketMQ 예외 또는 Flink 작업 예외는 동기화 링크 문제를 일으키고 비즈니스 예외의 위험을 증가시킵니다.
여기서 주의가 필요한 한 가지 문제는 일부 사람들이 다중 기계실 ES 클러스터에 연결하는 것을 고려할 수 있다는 것입니다. 여러 컴퓨터실이 동시에 성공하는지 확인하는 방법과 성공적인 쓰기 후 데이터를 쿼리할 수 있는지 확인하는 방법은 무엇입니까? 현재로서는 여러 컴퓨터실이 서로 영향을 주지 않고 독립적으로 쓰기 때문에 이 두 가지 사항을 달성할 수 없으며 ES 클러스터는 데이터 일관성이 약한 클러스터이므로 성공적인 쓰기를 즉시 찾을 수 있다는 보장이 없습니다.
ES Flink 소비자 프로그램 구축 및 실행을 위한 전제 조건 :
-
Flink 실행 환경 : 우선 Flink 작업을 위한 실행 환경이 필요합니다. 일반적으로 기업 수준의 Flink 작업은 분산 시스템에서 YARN 작업으로 예약되고 실행을 위해 리소스를 할당하지만 동시에 Flink는 독립형 프로세스로 사용하거나 독립적인 클러스터 작업을 구축할 수도 있습니다.
-
ES 메시지 형식 : ES 메시지 전송 형식 및 직렬화 방법에 대한 합의가 필요합니다. 일련의 패러다임이 모든 동기화 시나리오를 해결할 수 있습니다. 현재 널리 사용되는 직렬화 방법은 pb 형식 또는 json 형식의 사용을 권장합니다. . 데이터 형식 스키마 정의:
|
분야 명
|
값 유형
|
필수/선택
|
설명하다
|
|
_색인
|
끈
|
필수의
|
색인화할 문서의 이름 또는 별칭
|
|
_유형
|
끈
|
필수/선택
|
문서 유형
|
|
_on_type
|
끈
|
필수의
|
문서 쓰기 작업 유형
, 값 범위:
index, create, update,
upsert
, delete
|
|
_ID
|
끈
|
선택 과목
|
문서 ID를 지정하지 않으면 ES에 쓸 때
자동으로 생성
됩니다 . 그러나 동일한 데이터를 반복적으로 사용하여 ES에 쓸 경우 여러 문서가 생성됩니다.
|
|
_라우팅
|
끈
|
선택 과목
|
문서
라우팅
. 지정하지 않으면 기본적으로 _id 필드 값 라우팅이 사용됩니다.
|
|
_버전
|
정수64
|
선택 과목
|
문서 버전이
지정되면 0보다 크며
색인/삭제 작업에만 유효합니다 . 기본적으로
external_gte
버전 유형이 사용됩니다.
|
|
_원천
|
물체
|
필수/선택
|
문서 내용은
작업 유형이 삭제인 경우 지정할 필요가 없습니다.
|
|
_스크립트
|
물체
|
선택 과목
|
문서 스크립트
, 작업 유형이 업데이트/업서트인 경우 유효하지만 _source와 동시에 존재할 수는 없습니다.
|
syntax = "proto3";
message ESIndexInfo {
string Name = 1; // 文档要写入索引的名称或别名
}
enum ESOPType { // 文档写入操作类型
DELETE = 0; // 删除文档
INDEX = 1; // 创建新文档或更新老文档，只能全量更新 (替换老文档)
UPDATE = 2; // 更新老文档，支持部分更新 (合并老文档)
UPSERT = 3; // 创建新文档或更新老文档，支持部分更新 (合并老文档)
CREATE = 4; // 创建新文档，存在时报错丢弃
}
message ESDocAction {
ESIndexInfo IndexInfo = 1; // 索引信息 (必需)
ESOPType OPType = 2; // 操作类型 (必需)
string ID = 3; // 文档 ID (可选)
string Doc = 4; // 文档内容 (JSON 格式, 删除操作时不需要)
int64 Version = 5; // 文档版本 (可选, 大于 0 且操作为 index/create/delete 有效)
string Routing = 6; // 文档路由 (可选, 非空有效)
string Script = 7; // 文档脚本 (JSON 格式, 操作类型为 update/upsert 有效，但和 Doc 不能同时存在)
}-
Flink 작업 에 필요한 구성 : RocketMQ Topic 정보 모니터링, ES 클러스터 정보 작성;
-
Flink 실행 기능 : Flink는 스트리밍 SQL과 사용자 지정 애플리케이션의 두 가지 방식으로 스트리밍 메시지를 처리합니다. 스트리밍 SQL에는 동일한 MQ에서 여러 인덱스 메시지를 지원하지 않는 등 자체적인 몇 가지 제한 사항이 적용되지만 사용자 지정 프로그래밍은 더 유연합니다. 다양한 관리, 로그, 오류코드 처리 등을 추가할 수 있으므로 이 방법을 권장합니다.
-
Flink 리소스 구성 : JobManager 리소스 구성, TaskManager 리소스 구성 등
-
Flink 사용자 정의 매개변수 구성 : 다음과 같이 Flink 소비 기능의 동적 조정을 용이하게 하기 위해 애플리케이션과 밀접하게 관련된 일부 동적 구성을 사용자 정의할 수 있습니다.
|
매개변수 이름
|
사용
|
기본값
|
|
job.writer.connector.bulk-flush.max-actions
|
단일 벌크의 최대 문서 수, 그 수를 초과하는 경우 플러시가 수행됩니다(즉, ES의 대량 요청이 실행됩니다).
|
기본 300
|
|
job.writer.connector.bulk-flush.max-size
|
단일 벌크의 최대 바이트 수, 이를 초과하는 경우 플러시가 수행됩니다(즉, ES의 대량 요청이 실행됩니다).
|
기본10MB
|
|
job.writer.connector.bulk-flush.interval
|
둘 이상의 플러시(예: ES 대량 요청 실행)인 경우 두 벌크 사이의 최대 간격
|
기본 1000ms
|
|
job.writer.connector.global-rate-limit
|
전역 쓰기 속도 제한 값
|
기본값 -1, 속도 제한 없음
|
|
job.writer.connector.failure-핸들러
|
4xx 오류 처리, 다양한 방법으로 5xx 오류 처리, 429 항상 무한 재시도 등과 같은 사용자 정의 실패 처리기를 지정합니다.
|
|
|
global_parallelism_num
|
flink 작업 전역 동시성
|
rmq는 대기열/4이고, bmq/kafka는 파티션/3입니다.
|
|
최대_병렬_수
|
플링크 작업의 최대 동시성
|
mq의 큐/파티션 수
|
|
체크포인트_간격
|
Checkpoint 생성 간격, 단위 ms (5min=300000)
|
기본 15분
|
|
checkpoint_timeout
|
체크포인트 생성 시간 초과, 단위 ms(5min=300000)
|
기본 10분
|
|
재조정_활성화
|
비순차적 소비 활성화
|
기본값은 거짓
|
비교 제안
|
작성방법
|
동기화 지연
|
속성 쓰기
|
ES 쓰기 성능
|
소비자
|
재해 내성
|
|
직접 연결
|
종속 구성 요소 수가 적고 대기 시간이 짧습니다.
|
Binlog 단일 키 주문됨
|
대량 쓰기
|
FaaS
|
가난한
|
|
로켓MQ+플링크+ES
|
종속 구성 요소가 많고 지연이 높거나 두 번째 수준입니다.
|
전역 단일 키 순서
|
대량 쓰기
|
많은
|
좋은
|
위의 소개 이후, 비즈니스가 2차 지연을 수용할 수 있다면 RocketMQ+Flink를 사용하면 질서정연함과 재해 복구 기능을 더 잘 달성할 수 있습니다. Flink는 스트리밍 작업 처리 기능 측면에서도 FaaS보다 훨씬 우수하지만 직접적인 연결 방법은 분명히 있습니다. 더 간단한 링크, 더 가벼운 아키텍처, 더 낮은 시스템 통합 및 유지 관리 비용을 고려하여 비즈니스 특성에 따라 가장 적합한 것을 선택하는 것이 여전히 필요합니다.
소스팀｜ByteDance 전자상거래 비즈니스 플랫폼
{{o.name}}
{{m.name}}