변경 데이터 캡처는 로컬 지식 인덱스를 어떻게 업데이트하나요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How Does Change Data Capture Update a Local Knowledge Index? - Zima Store Online

변경 데이터 캡처(CDC)는 커밋된 소스 변경 사항을 다운스트림 인덱싱 작업자가 증분 방식으로 처리할 수 있는 이벤트로 변환하여 로컬 지식 인덱스를 업데이트합니다.

이는 홈 지식 기반이 단순한 폴더 감시가 아니라 구조화된 애플리케이션 데이터베이스를 기반으로 할 때 중요합니다. 노트, 재고 기록, 미디어 메타데이터, 북마크, 홈 오토메이션 기록 또는 문서 카탈로그 행은 계속해서 변경될 수 있습니다. 편집된 레코드 하나를 찾기 위해 전체 데이터베이스를 다시 읽는 것은 I/O를 낭비하고 최신 상태를 반영하는 데 큰 지연을 만듭니다. 반면 CDC는 데이터베이스 자체의 변경 스트림을 따라가며 인덱서에 구체적인 변경 작업의 순서를 제공합니다.

CDC는 모든 행을 다시 검색하는 대신 소스 변경 스트림을 읽습니다

많은 데이터베이스는 이미 트랜잭션 로그, 복제 스트림 또는 이와 유사한 순서가 지정된 변경 기록에 커밋된 변경 사항을 기록합니다. CDC 시스템은 이러한 스트림을 구독하고 낮은 수준의 로그 정보를 삽입, 업데이트, 삭제 이벤트로 변환하여 사용할 수 있도록 합니다.

로그 기반 CDC는 행 수준 데이터베이스 변경 사항을 소스 변경 스트림에서 직접 캡처하므로, 적은 수의 변경 사항을 찾기 위해 반복적으로 전체 테이블을 폴링할 필요가 없습니다.

이는 파일 시스템 감시자와 다릅니다. 감시자는 운영 체제의 경로 수준 이벤트를 관찰하지만, CDC는 데이터베이스 내부의 논리적 소스 변경을 관찰하며 트랜잭션 순서와 레코드 식별자를 유지할 수 있습니다.

지식 인덱스가 처리해야 하는 작업 큐는 훨씬 작아집니다. “레코드 184가 변경됨”에 대응하는 것이 “90만 개의 행을 검색하고 모두 다시 비교”하는 것보다 훨씬 저렴합니다.

각 이벤트에는 파생 인덱스 레코드를 찾는 데 필요한 식별자가 포함됩니다

업데이트 이벤트는 인덱서가 변경된 소스 행을 그 행에서 이전에 파생된 청크, 텍스트 필드, 메타데이터 레코드 또는 벡터와 연결할 수 있을 때만 유용합니다.

복제본 식별자는 복제된 업데이트와 삭제에 사용할 수 있는 행 식별 정보를 결정하여, 다운스트림 소비자가 파생된 인덱스 레코드를 안정적으로 대상으로 지정할 수 있도록 합니다.

로컬 인덱싱 파이프라인은 모든 파생 레코드에 이와 유사한 안정적인 소스 키를 유지해야 합니다. 그러면 `UPDATE`가 발생했을 때 영향을 받은 문서 그룹만 가져와 다시 구축할 수 있고, `DELETE`가 발생했을 때는 비활성화해야 하는 모든 벡터를 찾을 수 있습니다. 안정적인 식별자가 없으면 이벤트 스트림이 무언가 변경되었다는 사실은 알려 주더라도, 해당 소스에 속한 인덱싱 아티팩트를 찾기 위해 여전히 비용이 많이 드는 검색을 수행해야 할 수 있습니다.

인덱서는 데이터베이스 변경 사항을 검색 계층 작업으로 변환합니다

CDC 이벤트에는 임베딩이 포함되어 있지 않으며 청킹 정책도 알지 못합니다. 이는 즉시 사용할 수 있는 벡터 작업이 아니라, 권위 있는 소스 계층에서 보내는 알림입니다.

구조화된 변경 이벤트 레코드는 소스 변경과 다운스트림 인덱싱 로직을 분리하므로, 소비자가 삽입, 업데이트 또는 삭제에 파싱, 임베딩 또는 폐기가 필요한지 결정할 수 있습니다.

인덱싱 작업자는 삽입을 파싱 및 추가로, 업데이트를 비교 및 재구축으로, 삭제를 소스 키에서 파생된 모든 검색 레코드의 삭제 표시 또는 제거로 매핑할 수 있습니다.

콘텐츠 해싱은 이 업데이트 경로에 포함할 수 있습니다. CDC는 어떤 소스 레코드가 변경되었는지 알려 주고, 해시 검사는 임베딩 모델에 입력되는 텍스트 자체가 실제로 변경되었는지 결정할 수 있습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

오프셋과 체크포인트를 사용하면 재시작 후 소비를 재개할 수 있습니다

홈 서버는 재부팅될 수 있고 컨테이너는 업그레이드되며 인덱싱 작업자는 때때로 오류가 발생합니다. 소비자가 자신의 위치를 잃으면 변경 사항을 놓치거나 많은 작업을 다시 처리해야 할 수 있습니다.

저장된 소스 오프셋을 사용하면 캡처 프로세스가 변경 사항을 조용히 건너뛰거나 처음부터 다시 시작하는 대신 재시작 후 알려진 위치에서 재개할 수 있습니다.

지식 인덱스 소비자는 관련 인덱스 변경 사항이 영구 상태에 도달한 후에만 자체 체크포인트를 커밋해야 합니다. 그렇지 않으면 벡터나 메타데이터가 실제로 기록되기 전에 이벤트가 확인될 수 있습니다. 이벤트를 다시 재생해도 안전해야 합니다. 안정적인 ID를 사용한 업서트, 버전 검사 및 멱등적인 삭제 처리를 적용하면 중복 전달로 인해 중복 청크가 생성되는 것을 방지할 수 있습니다.

CDC는 최신 상태 반영 지연을 줄이지만 조정을 대체하지는 않습니다

로그 기반 스트리밍은 순서가 지정된 데이터베이스 변경에 강력하지만, 구성 오류, 보존 기간 제한, 커넥터 중단, 스키마 변경 또는 소비자 버그로 인해 소스와 인덱스 사이에 여전히 누락이 발생할 수 있습니다.

변경 이벤트 누락 위험은 빠른 증분 스트림도 권위 있는 소스 상태와 느리게 대조하는 조정 과정으로 보완해야 하는 이유를 보여 줍니다.

주기적인 조정은 소스 행 수, 버전, 콘텐츠 해시, 삭제 표시 및 인덱싱된 ID를 비교하여 실시간 스트림이 놓친 항목을 복구할 수 있습니다.

이를 통해 시스템은 두 가지 시간 단위를 갖게 됩니다. CDC는 일반적인 변경 사항을 수초 또는 수분 내에 최신 상태로 유지하고, 조정 과정은 더 느리지만 완전성을 보장합니다.

높은 업데이트 속도는 소스와 인덱스 사이에 백프레셔를 만듭니다

데이터베이스는 OCR, 청킹, 임베딩 또는 벡터 인덱스 유지 관리가 처리할 수 있는 속도보다 빠르게 변경 사항을 커밋할 수 있습니다. 그러면 CDC 큐는 소스 활동과 검색 최신 상태 사이의 버퍼가 됩니다.

데이터 변경 이벤트의 바이너리 로그는 일시적인 중단 이후 느린 다운스트림 인덱서가 소비할 수 있는 순서가 지정된 기록을 제공합니다. 단, 이는 소스 시스템의 보존 기간에 따라 달라집니다.

동일한 소스 ID에 대한 인접한 업데이트를 일괄 처리하고, 삭제와 권한 변경의 우선순위를 높이며, 큐 길이만이 아니라 지연 시간도 모니터링해야 합니다. 이벤트 1,000개가 서로 독립적인 문서 1,000개를 의미할 수도 있고, 한 레코드에 대한 반복적인 편집을 의미할 수도 있습니다. 인덱스가 최신 상태라는 것은 소비자가 알려진 소스 위치까지의 이벤트를 적용했고 해당 레코드에 필요한 다운스트림 임베딩 또는 압축 작업도 완료했다는 뜻입니다.