Este documento é um rascunho, e não deve ser assumido para representar a arquitetura final.
Este documento descreve como Wikibase propaga mudanças no repositório para qualquer cliente wikis.
Visão geral
- Cada mudança no repositório é gravado na tabela de alterações que funciona como um feed de atualização para todos os wikis do cliente (como a Wikipédia).
- Os scripts Dispatcher verificam periodicamente a tabela de alterações.
- Cada wiki cliente é notificado de qualquer alteração nas alterações do repositório através de uma entrada na fila de trabalho. Estas filas de trabalho são usadas para invalidar e re-renderizar página(s) relevante na wiki cliente
- Notificações sobre as mudanças são injetadas na tabela recentchanges do cliente, para torná-los visíveis em listas de vigilância, etc
- Edições consecutivas pelo mesmo usuário para o mesmo item de dados podem ser combinadas em uma só, para evitar a desordem.
Suposições e Terminologia
Os dados gerenciados pelo repositório Wikibase estão estruturados em (dados) entidades. Cada entidade é mantida como uma página wiki que contém dados estruturados. Existem vários tipos de entidades, mas é particularmente importante neste contexto: itens. Itens são especiais na medida em que são ligados com páginas de artigos sobre cada wiki cliente (por exemplo, cada Wikipedia). Para mais informações, consulte o data model primer.
O mecanismo de propagação é baseado no pressuposto de que cada dados de item sobre o repositório Wikidata possui a maioria dos link de um site para cada cliente wiki, e somente um item no repositório pode ligar para qualquer determinada página na wiki de determinado cliente. Ou seja, qualquer página na wiki de qualquer cliente pode ser associado com no máximo um item de dados no repositório.
- (Ver comentário na página de discussão sobre as consequências de limitar a propagação de modificação para casos onde a página da Wikipedia e item Wikidata tem uma relação 1:1)
Esse mecanismo também pressupõe que todas as wikis, o repositório e os clientes (ou seja, Wikidata e o Wikipédias), pode se conectar diretamente a uns dos outros bancos de dados. Normalmente, isso significa que eles residem na mesma rede local. No entanto, os wikis podem usar servidores de banco de dados separado: wikis são agrupados em seções, onde cada seção tem um banco de dados mestre, e potencialmente muitos bancos de dados escravos(juntos formando um cluster de banco de dados).
A comunicação entre o repositório (Wikidata) e os clientes (wikipedia) é feita através de uma atualização de alimentação. Por enquanto, isso é implementado como uma tabela de banco de dados (tabela de alterações) que é acessada pelos scripts do dispatcher diretamente, usando o mecanismo de "banco de dados externo".
Suporte para clientes terceiro partido, ou seja, wikis cliente e outros consumidores fora da Wikimedia, momento não é essencial e não será implementado por enquanto. Deve, contudo, ser mantido em mente para todas as decisões de design.
Trocando o Registro de Log
Todas as alterações realizadas no repositório é registrada em uma tabela (a "tabela de mudanças", ou seja wb_changes) no banco de dados do repositório. A tabela de alterações se comporta de forma similar na tabela RecentChanges do MediaWiki, em que apenas mantém as alterações durante um certo tempo (por exemplo, um dia ou uma semana), as entradas mais velhas serão expurgadas periodicamente. Em oposição a tabela recentchanges entretanto, wb_changes contém todas as informações necessárias para relatar e repetir a mudança em um wiki do cliente: além de informações sobre quando a alteração foi feita e por quem, ele contém uma comparação estrutural contra a entidade de revisão anterior.
Efetivamente, a tabela de mudanças funciona como um feed de atualizações. Devem ser tomadas precauções para isolar a tabela de base de dados como um detalhe de implementação a partir da alimentação de atualização, de modo que depois pode ser substituído por um mecanismo alternativo, como PubHub ou um event bus. Note, porém, que um protocolo com a semântica da fila não é apropriado (porque exigiria: em fila por cliente).
Enviar alterações
As alterações no repositório (por exemplo, wikidata.org) são expedidas para wikis de cliente (por exemplo, Wikipédias) por um script de dispatcher. Este script de enquetes tem o repositório da tabela de wb_changes para as mudanças e as expedições para os clientes wikis, colocando os postos de trabalho adequados para a fila de trabalhos do cliente.
O script de despachante é projetado de forma que permite que qualquer número de instâncias de executar e compartilhar a carga sem qualquer conhecimento prévio do outro. Eles são coordenados através do repoysitory do banco de dados, usando a tabela wb_changes_dispatch:
- Chd_client: Nome do banco de dados do cliente (chave primária).
- Chd_latest_change: o ID da última alteração que foi enviada para o cliente.
- Chd_touched: um timestamp indicando quando as atualizações mais recentes foram encaminhados para o cliente.
- Chd_lock_name: o nome do bloqueio global utilizado pelo despachante atualizando esse cliente (ou NULL).
O despachante opera, passando por os seguintes passos:
- Bloqueio e Initialização
- Escolha um cliente para atualizar a lista de clientes conhecidos.
- Inicie transação DB banco de dados mestre do repositório.
- Ler linha do cliente determinado de wb_changes_dispatch (se faltar, assumir chd_latest_change = 0).
- Se chd_lock_name não for null, chame IS_FREE_LOCK(chd_lock_name) no banco de dados mestre do "cliente".
- Se que retorna 0, outro despachante está segurando o bloqueio. Sair (ou tentar outro cliente).
- Decidir sobre um nome de bloqueio ("dbname".wb_changes_dispatch."cliente" ou algo assim) e use GET_LOCK para pegar o cadeado no banco de dados mestre do cliente.
- Atualize a linha do cliente em wb_changes_dispatch com o novo nome de bloqueio em chd_lock_name.
- Comete DB transação no banco de dados mestre do repositório.
- Realizar o despacho
- Se n alterações com IDs > chd_latest_change de wb_changes no banco de dados do repositório, n é o tamanho do lote configurado.
- Filtrar alterações para aqueles relevantes para este cliente wiki (opcional e pode revelar-se complicado em casos complexos, por exemplo, cache de consultas).
- Poste os correspondente change notificação notificação empregos para a fila de trabalho no wiki cliente.
- Log e desbloquear
- Inicie transação DB banco de dados mestre do repositório.
- Atualizar a linha do cliente em wb_changes_dispatch com chd_lock_name = NULL e atualizado chd_latest_change e chd_touched.
- Chame RELEASE_LOCK para liberar o bloqueio global que estávamos fazendo.
- Comete DB transação no banco de dados mestre do repositório.
Isto pode ser repetido várias vezes por um processo, com um atraso configurável entre execuções.
Alterações Notificação Jobs
Os postos expedidor muda o emprego de notificação para a fila de trabalho do wiki cliente. Estes trabalhos contêm uma lista de alterações wikidata. Ao processar um trabalho, o wiki cliente executa as seguintes etapas:
- Se o cliente mantém um cache local de dados da entidade, atualizá-lo.
- Encontre as páginas que precisam ser re-renderizadas após a mudança. Invalidá-las e eliminá-las dos caches web. Opcionalmente, a programação re-render (ou atualização de link) postos de trabalho, ou até mesmo re-processar a página diretamente.
- Encontre as páginas que têm alterações que não precisam de re-renderização do conteúdo, mas influenciam a saída da página, e, portanto, precisam ser expurgados do cache web (pode em algum momento ser o caso de mudanças para ligações de linguagem).
- Injetar notificações sobre alterações relevantes na tabela de alterações recentes do cliente. Para isso, as edições consecutivas feitas pelo mesmo usuário, para o mesmo item, podem ser fundidas.
- Possivelmente também injetar um "entrada-nula" para a história das respectivas páginas, ou seja, a tabela de revisão.
- (Veja comentário na página de discussão sobre recentchanges contra tabela de histórico)
Coalescente Eventos
O sistema descrito acima significa vários banco de dados, escreve para todas as mudanças - e potencialmente muitos lê, dependendo do que é necessário para renderizar a página. E isso acontece em cada wiki cliente (potencialmente centenas) para cada mudança no repositório. Desde edições no repositório Wikibase que tendem a ser muito bem granulada (como a criação de um rótulo ou a adição de um link de site), este pode ser rapidamente problemático. Coalescente atualizações poderia ajudar com este problema:
Como explicado na Despacho seção, entradas na alimentação mudanças são processados em lotes (por padrão, não mais de 100 entradas de uma só vez).
Se várias alterações para o mesmo item são processadas no mesmo lote, estas mudanças podem ser unidas juntas se elas foram realizadas consecutivamente pelo mesmo usuário. Isto reduziria o número de vezes de páginas invalidadas (e, portanto, eventualmente re-processadas). Todas as entradas necessárias na tabela RecentChanges (e, possivelmente, a tabela de revisão) podem ser inseridos usando um único banco de dados pedido. Esse processo pode ser bem sintonizado, ajustando o tamanho do lote e atraso entre lotes.