이 문서는 초안이며 궁극적인 아키텍처를 나타내는 것으로 간주해서는 안됩니다.
이 문서는 위키베이스가 저장소의 변경 사항을 클라이언트 위키로 전파하는 방법을 설명합니다.
개요
- 저장소의 각 변경 사항은 클라이언트 위키 (예를 들어, 위키백과)에 대한 업데이트 피드 역할을하는 변경 테이블에 기록됩니다.
- 디스패처(Dispatcher) 스크립트는 주기적으로 변경 테이블을 확인합니다.
- 각 클라이언트 위키는 작업 대기열의 항목을 통해 저장소 변경 사항에 대한 알림을 받습니다. 이 작업은 클라이언트 위키에서 관련 페이지를 무효화하고 다시 렌더링하는 데 사용됩니다.
- 변경 사항에 대한 알림이 클라이언트의 최근 변경 테이블에 삽입되어 감시 목록 등에 표시됩니다.
- 동일한 사용자가 동일한 데이터 항목에 대한 연속 편집을 하나로 결합하여 혼란을 방지할 수 있습니다.
추정 및 용어
위키베이스 저장소에서 관리하는 데이터는 (데이터) 개체로 구성됩니다. 모든 개체는 구조화된 데이터를 포함하는 위키 페이지로 유지됩니다. 여러 유형의 개체가 있지만 이 컨텍스트에서 특히 중요한 것은 항목입니다. 항목은 각 클라이언트 위키(예를 들어, 각 위키백과)의 문서 페이지와 연결된다는 점에서 특별합니다. 자세한 내용은 데이터 모델 입문서를 참조하세요.
전파 메커니즘은 위키데이터 저장소의 각 데이터 항목에 각 클라이언트 위키에 대한 사이트 링크가 하나만 있고 저장소에있는 하나의 항목만 주어진 클라이언트 위키의 지정된 페이지에 링크 될 수 있다는 가정을 기반으로합니다. 즉, 클라이언트 위키의 모든 페이지는 저장소에 있는 최대 하나의 데이터 항목과 연관 될 수 있습니다.
- (위키백과 페이지와 위키데이터 항목이 1:1 관계인 경우 변경 전파를 제한한 결과에 대한 토론 페이지의 의견을 참조하세요)
이 메커니즘은 또한 모든 위키와 저장소 및 클라이언트(즉, 위키데이터 및 위키백과)가 서로의 데이터베이스에 직접 연결할 수 있다고 가정합니다. 일반적으로 이는 동일한 로컬 네트워크에 있음을 의미합니다. 그러나 위키는 별도의 데이터베이스 서버를 사용할 수 있습니다. 위키는 섹션으로 그룹화되어 각 섹션에는 하나의 마스터 데이터베이스와 잠재적으로 많은 슬레이브 데이터베이스가 있습니다 (함께 데이터베이스 클러스터를 형성함).
저장소(위키데이터)와 클라이언트(각 위키백과) 사이의 통신은 업데이트 피드를 통해 이루어집니다. 지금은 "외부 데이터베이스" 메커니즘을 사용하여 디스패처 스크립트에서 직접 접근하는 데이터베이스 테이블(변경 테이블)로 구현됩니다.
제3자 클라이언트, 즉 클라이언트 위키 및 위키미디어 외부의 기타 소비자에 대한 지원은 현재 필수적이지 않으며 현재 구현되지 않을 것입니다. 그러나 모든 설계 결정에 대해 염두에 두어야합니다.
변경 로깅
저장소에서 수행 된 모든 변경 사항은 저장소 데이터베이스의 테이블 ( "변경 테이블", 즉 wb_changes)에 기록됩니다. 변경 테이블은 특정 시간 (예를 들어, 하루 또는 일주일) 동안 만 변경 사항을 유지하고 오래된 항목은 주기적으로 제거된다는 점에서 미디어위키의 최근 바뀜 테이블과 유사하게 작동합니다. 그러나 최근 바뀜 테이블과는 반대로 wb_changes에는 클라이언트 위키에서 변경 사항을 보고하고 재생하는 데 필요한 모든 정보가 포함되어 있습니다. 변경 사항이 언제 누구에 의해 이루어 졌는지에 대한 정보 외에 개체의 이전 개정과의 구조적 차이가 포함되어 있습니다.
실제로 변경 테이블은 업데이트 피드 역할을 합니다. 나중에 PubHub 또는 이벤트 버스와 같은 대체 메커니즘으로 대체 될 수 있도록 데이터베이스 테이블을 업데이트 피드에서 구현 세부 사항으로 분리하도록 주의해야합니다. 그러나 큐 의미 체계을 갖는 프로토콜은 적절하지 않습니다 (클라이언트 당 큐에 필요함).
변경 사항 전달
저장소(예를 들어, 위키데이터)의 변경 사항은 디스패처 스크립트를 통해 클라이언트 위키(예를 들어, 위키백과)로 전달됩니다. 이 스크립트는 변경 사항에 대해 저장소의 wb_changes 테이블을 폴링하고 클라이언트의 작업 대기열에 적절한 작업을 게시하여 클라이언트 위키로 전달합니다.
디스패처 스크립트는 여러 인스턴스가 서로에 대한 사전 지식없이 실행하고 로드를 공유 할 수 있도록 설계되었습니다. wb_changes_dispatch 테이블을 사용하여 저장소의 데이터베이스를 통해 조정됩니다:
- chd_client: 클라이언트의 데이터베이스 이름 (기본 키).
- chd_latest_change: 클라이언트에 발송 된 마지막 변경의 ID.
- chd_touched: 업데이트가 클라이언트에 마지막으로 발송 된시기를 나타내는 타임 스탬프.
- chd_lock_name: 현재 해당 클라이언트 (또는 NULL)를 업데이트하는 디스패처가 사용하는 전역 잠금의 이름.
디스패처는 다음 단계를 통해 작동합니다:
- 잠금 및 초기화
- 알려진 클라이언트 목록에서 업데이트 할 클라이언트를 선택합니다.
- 저장소의 마스터 데이터베이스에서 DB 트랜잭션을 시작합니다.
- wb_changes_dispatch에서 주어진 클라이언트의 라인을 읽습니다 (누락 된 경우 chd_latest_change = 0이라고 가정).
- chd_lock_name이 null이 아니면 "클라이언트"의 마스터 데이터베이스에서 IS_FREE_LOCK (chd_lock_name)을 호출합니다.
- 0을 반환하면 다른 디스패처가 잠금을 보유하고있는 것입니다. 종료 (또는 다른 클라이언트 시도).
- 잠금 이름 (``dbname . wb_changes_dispatch. client 등)을 결정하고 GET_LOCK ()을 사용하여 클라이언트의 마스터 데이터베이스에서 해당 잠금을 가져옵니다.
- wb_changes_dispatch의 클라이언트 행을 chd_lock_name의 새 잠금 이름으로 업데이트합니다.
- repo의 마스터 데이터베이스에서 DB 트랜잭션을 수행합니다.
- 디스패치 수행
- 저장소 데이터베이스의 wb_changes에서 ID> chd_latest_change로 n개의 변경 사항을 가져옵니다. n은 구성된 배치 크기입니다.
- 이 클라이언트 위키와 관련된 변경 사항을 필터링합니다 (선택 사항이며 캐시 된 쿼리와 같은 복잡한 경우에는 까다로울 수 있음).
- 해당 변경 알림 작업을 클라이언트 위키의 작업 대기열에 게시합니다.
- 로그인 및 잠금 해제
- 저장소의 마스터 데이터베이스에서 DB 트랜잭션을 시작합니다.
- wb_changes_dispatch에서 chd_lock_name=NULL로 클라이언트 행을 업데이트하고 chd_latest_change 및 chd_touched를 업데이트했습니다.
- RELEASE_LOCK()을 호출하여 보유하고 있던 전역 잠금을 해제합니다.
- repo의 master 데이터베이스에서 DB 트랜잭션을 커밋합니다.
이는 실행 사이에 구성 가능한 지연을 사용하여 한 프로세스에서 여러 번 반복 할 수 있습니다.
변경 알림 작업
디스패처는 변경 알림 작업을 클라이언트 위키의 작업 대기열에 게시합니다. 이 작업에는 목록이 포함되어 있습니다. 위키 데이터 변경 이러한 작업을 처리 할 때 클라이언트 위키는 다음 단계를 수행합니다:
- 클라이언트가 개체 데이터의 로컬 캐시를 유지하는 경우 업데이트합니다.
- 변경 후 다시 렌더링해야하는 페이지를 찾습니다. 이를 무효화하고 웹 캐시에서 제거하세요. 선택적으로 다시 렌더링 (또는 링크 업데이트) 작업을 예약하거나 페이지를 직접 다시 렌더링 할 수도 있습니다.
- 콘텐츠를 다시 렌더링 할 필요는 없지만 페이지 출력에 영향을 미치므로 캐시 된 웹을 제거해야하는 변경 사항이있는 페이지를 찾습니다(언젠가는 언어 링크가 변경 될 수 있음).
- 관련 변경 사항에 대한 알림을 클라이언트의 최근 바뀜 테이블에 삽입합니다. 이를 위해 동일한 사용자가 동일한 항목에 대한 연속 편집을 통합할 수 있습니다.
- 각 페이지의 히스토리, 즉 개정 테이블에 "null-entry"를 삽입할 수도 있습니다.
- (최근 바뀜과 기록 테이블에 대한 토론 페이지의 의견을 참조하세요.)
이벤트 병합
위에서 설명한 시스템은 모든 변경에 대해 여러 데이터베이스 쓰기를 의미하며 페이지를 렌더링하는 데 필요한 항목에 따라 잠재적으로 많은 읽기를 의미합니다. 그리고 이것은 저장소의 모든 변경에 대해 모든 클라이언트 위키(잠재적으로 수백 개)에서 발생합니다. 위키베이스 저장소에 대한 편집은 매우 세밀한 경향이 있으므로 (예를 들어, 레이블 설정 또는 사이트 링크 추가) 문제가 빠르게 발생할 수 있습니다. 통합 업데이트는 이 문제에 도움이 될 수 있습니다.
발송 섹션에 설명 된대로 변경 피드의 항목은 일괄 처리됩니다(기본적으로 한 번에 100개 이하의 항목).
동일한 항목에 대한 여러 변경 사항이 동일한 일괄 처리에서 처리되는 경우 이러한 변경 사항은 모두 동일한 사용자가 연속적으로 수행 한 경우 함께 통합 될 수 있습니다. 이렇게하면 페이지가 무효화되고 결국 다시 렌더링되는 횟수가 줄어 듭니다. 최근 바뀜 테이블(그리고 가능하면 개정 테이블)에 필요한 모든 항목을 단일 데이터베이스 요청을 사용하여 삽입 할 수 있습니다. 이 프로세스는 배치 크기 및 배치 간 지연을 조정하여 미세 조정할 수 있습니다.