Wikidata/Notes/Change propagation/es: Difference between revisions

Revision as of 09:45, 24 September 2022

Latest revision as of 20:34, 1 October 2022

(One intermediate revision by one other user not shown)

Line 9:

== Resumen ==

<div lang="en" dir="ltr" class="mw-content-ltr">

* Cada cambio en el repositorio se registra en la tabla de cambios que actúa como una fuente de actualización para cualquier wikis cliente (como las Wikipedias).

* Each change on the repository is recorded in the changes table which acts as an update feed to any client wikis (like the Wikipedias).

* Los scripts del despachador comprueban periódicamente la tabla de cambios.

* Dispatcher scripts periodically checks the changes table.

* Cada wiki cliente es notificado de cualquier cambio en los cambios del repositorio a través de una entrada en su cola de trabajos. Estos trabajos se utilizan para invalidar y volver a renderizar la(s) página(s) relevante(s) en el wiki cliente

* Each client wiki is notified of any changes on the repository changes via an entry in its job queue. These jobs are used to invalidate and re-render the relevant page(s) on the client wiki

* Las notificaciones sobre los cambios se inyectan en la tabla de cambios recientes del cliente, para hacerlos visibles en las listas de seguimiento, etc.

* Notifications about the changes are injected into the client's recentchanges table, to make them visible on watchlists, etc.

* Las ediciones consecutivas realizadas por el mismo usuario en el mismo elemento de datos pueden combinarse en una sola, para evitar el desorden.

* Consecutive edits by the same user to the same data item can be combined into one, to avoid clutter.

</div>

<span id="Assumptions_and_Terminology"></span>

== Suposiciones y Terminología ==

<div lang="en" dir="ltr" class="mw-content-ltr">

Los datos gestionados por el repositorio Wikibase están estructurados en entidades (de datos). Cada entidad se

The data managed by the Wikibase repository is structured into (data) entities. Every entity is

mantenida como una página wiki que contiene datos estructurados. Hay varios tipos de entidades,

maintained as a wiki page containing structured data. There are several types of entities,

pero una es particularmente importante en este contexto: los ítems. Los artículos son especiales porque están

but one is particularly important in this context: items. Items are special in that they are

vinculados con páginas de artículos en cada wiki cliente (por ejemplo, cada Wikipedia). Para más información, consulta la página

linked with article pages on each client wiki (e.g., each Wikipedia). For more information, see the

[[Wikidata/Notes/Data_model_primer|imagen del modelo de datos]].

[[Wikidata/Notes/Data_model_primer|data model primer]].

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

El mecanismo de propagación se basa en la suposición de que cada elemento de datos en el repositorio de Wikidata

The propagation mechanism is based on the assumption that each data item on the Wikidata

tiene como máximo un enlace con cada wiki cliente, y que sólo un elemento del repositorio

repository has at most one site link to each client wiki, and that only one item on the repository

puede enlazar con cualquier página de un wiki cliente determinado. Es decir, cualquier página de cualquier wiki cliente puede estar

can link to any given page on a given client wiki. That is, any page on any client wiki can be

asociada a un solo elemento de datos en el repositorio.

associated with at most one data item on the repository.

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

(Véase el comentario en la página de discusión sobre las consecuencias de limitar la propagación de los cambios a los casos en que la página de Wikipedia y el elemento de Wikidata tienen una relación 1:1)

: (See comment on discussion page about consequences of limiting change propagation to cases where Wikipedia page and Wikidata item have a 1:1 relation)

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

Este mecanismo también supone que todos los wikis, el repositorio y los clientes (es decir, Wikidata y las Wikipedias), pueden conectarse directamente a las bases de datos de los demás. Normalmente, esto significa que residen en la misma red local. Sin embargo, los wikis pueden utilizar servidores de bases de datos separados: los wikis se agrupan en secciones, donde cada sección tiene una base de datos maestra y potencialmente muchas bases de datos esclavas (formando juntas un clúster de bases de datos).

This mechanism also assumes that all wikis, the repository and the clients (i.e. Wikidata and the Wikipedias), can connect directly to each other's databases. Typically, this means that they reside in the same local network. However, the wikis may use separate database servers: wikis are grouped into sections, where each section has one master database and potentially many slave databases (together forming a database cluster).

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

La comunicación entre el repositorio (Wikidata) y los clientes (Wikipedias) se realiza mediante

Communication between the repository (Wikidata) and the clients (Wikipedias) is done via

un feed de actualización. Por ahora, esto se implementa como una tabla de base de datos (la tabla de cambios)

an update feed. For now, this is implemented as a database table (the changes table)

a la que acceden los scripts de envío directamente, utilizando el mecanismo de "base de datos extranjera".

which is accessed by the dispatcher scripts directly, using the "foreign database" mechanism.

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

El soporte para clientes de terceros, es decir, wikis clientes y otros consumidores fuera de Wikimedia,

Support for 3rd party clients, that is, client wikis and other consumers outside of Wikimedia,

actualmente no es esencial y no se implementará por ahora. Sin embargo, se tendrá en

is currently not essential and will not be implemented for now. It shall however be kept in

en cuenta para todas las decisiones de diseño.

mind for all design decisions.

</div>

<span id="Change_Logging"></span>

== Registro de cambios ==

<div lang="en" dir="ltr" class="mw-content-ltr">

Cada cambio realizado en el repositorio se registra en una tabla (la "tabla de cambios", a saber

Every change performed on the repository is logged into a table (the "changes table", namely

wb_changes) en la base de datos del repositorio. La tabla de cambios se comporta de forma similar a la tabla

wb_changes) in the repo's database. The changes table behaves similarly to MediaWiki's

de MediaWiki, en el sentido de que sólo mantiene los cambios durante un cierto tiempo (por ejemplo, un día o una semana), las entradas más antiguas se purgan periódicamente.

recentchanges table, in that it only holds changes for a certain time (e.g. a day or a week), older

Las entradas más antiguas se purgan periódicamente. Sin embargo, a diferencia de la tabla recentchanges, wb_changes contiene

entries get purged periodically. As opposed to the recentchanges table however, wb_changes contains

toda la información necesaria para informar y reproducir el cambio en un wiki cliente: además de la información

all information necessary to report and replay the change on a client wiki: besides information

información sobre cuándo se hizo el cambio y por quién, contiene una diferencia estructural con la revisión anterior de la entidad.

about when the change was made and by whom, it contains a structural diff against the entity's

revisión anterior de la entidad.

previous revision.

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

Efectivamente, la tabla de cambios actúa como una fuente de actualización. Se debe tener cuidado de aislar la tabla de la base de datos

Effectively, the changes table acts as an update feed. Care shall be taken to isolate the database

de la base de datos como un detalle de la implementación del feed de actualización, para que pueda ser reemplazado más tarde por un mecanismo alternativo, como PubHub o un bus de eventos.

table as an implementation detail from the update feed, so it can later be replaced by an

mecanismo alternativo, como PubHub o un bus de eventos. Sin embargo, hay que tener en cuenta que un protocolo

alternative mechanism, such as PubHub or an event bus. Note however that a protocol

con semántica de cola no es apropiado (requeriría una cola por cliente).

with queue semantics is not appropriate (it would require on queue per client).

</div>

<span id="Dispatching_Changes"></span>

== Distribución de cambios ==

<div lang="en" dir="ltr" class="mw-content-ltr">

Los cambios en el repositorio (por ejemplo, wikidata.org) se envían a los wikis clientes (por ejemplo, Wikipedias) mediante

Changes on the repository (e.g. wikidata.org) are dispatched to client wikis (e.g. Wikipedias) by

un script de envío. Este script consulta la tabla wb_changes del repositorio en busca de cambios, y los envía

a dispatcher script. This script polls the repository's wb_changes table for changes, and dispatches

y los envía a los wikis clientes enviando los trabajos apropiados a la cola de trabajos del cliente.

them to the client wikis by posting the appropriate jobs to the client's job queue.

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

El script del despachador está diseñado de manera que permite que cualquier número de instancias se ejecute y comparta la carga sin

The dispatcher script is designed in a way that allows any number of instances to run and share load without

ningún conocimiento previo de los demás. Se coordinan a través de la base de datos del repoysitorio utilizando la tabla

any prior knowledge of each other. They are coordinated via the repoysitory's database using the

wb_changes_dispatch:

wb_changes_dispatch table:

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

* chd_client: el nombre de la base de datos del cliente (clave primaria).

* chd_client: the client's database name (primary key).

* chd_latest_change: el ID del último cambio que se envió al cliente.

* chd_latest_change: the ID of the last change that was dispatched to the client.

* chd_touched: una marca de tiempo que indica cuándo se enviaron las últimas actualizaciones al cliente.

* chd_touched: a timestamp indicating when updates have last been dispatched to the client.

* chd_lock_name: el nombre del bloqueo global utilizado por el despachador que está actualizando ese cliente (o NULL).

* chd_lock_name: the name of the global lock used by the dispatcher currently updating that client (or NULL).

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

El despachador funciona siguiendo los siguientes pasos:

The dispatcher operates by going through the following steps:

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

# Bloquear e inicializar

# Lock and initialize

## Elija un cliente para actualizar de la lista de clientes conocidos.

## Choose a client to update from the list of known clients.

## Iniciar la transacción en la base de datos maestra del repositorio.

## Start DB transaction on repo's master database.

## Leer la fila del cliente dado desde wb_changes_dispatch (si falta, asumir chd_latest_change = 0).

## Read the given client's row from wb_changes_dispatch (if missing, assume chd_latest_change = 0).

## Si chd_lock_name no es null, llama a IS_FREE_LOCK(chd_lock_name) en la base de datos maestra del ''cliente''.

## If chd_lock_name is not null, call IS_FREE_LOCK(chd_lock_name) on the ''client's'' master database.

## Si eso devuelve 0, otro despachador está manteniendo el bloqueo. Salir (o intentar con otro cliente).

## If that returns 0, another dispatcher is holding the lock. Exit (or try another client).

## Decide un nombre de bloqueo (''dbname''.wb_changes_dispatch.''client'' o algo así) y usa GET_LOCK() para coger ese bloqueo en la base de datos maestra del cliente.

## ActualizarDecide laon filaa dellock cliente enname (''dbname''.wb_changes_dispatch.''client'' or some such) and use GET_LOCK() to congrab elthat nuevolock nombreon delthe bloqueoclient's enmaster chd_lock_namedatabase.

## Update the client's row in wb_changes_dispatch with the new lock name in chd_lock_name.

## Confirmar la transacción en la base de datos maestra del repositorio.

## Commit DB transaction on repo's master database.

# Realizar el envío

</div>

## Obtener n cambios con IDs > chd_latest_change de wb_changes en la base de datos del repo. n es el tamaño de lote configurado.

<div lang="en" dir="ltr" class="mw-content-ltr">

## Filtrar los cambios para aquellos que son relevantes para este wiki cliente (opcional, y puede resultar complicado en casos complejos, por ejemplo, consultas en caché).

# Perform the dispatch

## Colocar los correspondientes [[#Trabajos de notificación de cambios|trabajos de notificación de cambios]] en la cola de trabajos del wiki cliente.

## Get n changes with IDs > chd_latest_change from wb_changes in the repo's database. n is the configured batch size.

# Log y desbloqueo

## Filter changes for those relevant to this client wiki (optional, and may prove tricky in complex cases, e.g. cached queries).

## Iniciar la transacción DB en la base de datos maestra del repo.

## Post the corresponding [[#Changes Notification Jobs|change notification jobs]] to the client wiki's job queue.

## Actualizar la fila del cliente en wb_changes_dispatch con chd_lock_name=NULL y actualizar chd_latest_change y chd_touched.

</div>

## Llamar a RELEASE_LOCK() para liberar el bloqueo global que teníamos.

<div lang="en" dir="ltr" class="mw-content-ltr">

## Confirmar la transacción en la base de datos maestra del repositorio.

# Log and unlock

## Start DB transaction on repo's master database.

## Update the client's row in wb_changes_dispatch with chd_lock_name=NULL and updated chd_latest_change and chd_touched.

## Call RELEASE_LOCK() to release the global lock we were holding.

## Commit DB transaction on repo's master database.

</div>

Esto se puede repetir varias veces por un proceso, con un retraso configurable entre ejecuciones.

Line 99 ⟶ 131:

== Procesos para la notificación de cambios ==

<div lang="en" dir="ltr" class="mw-content-ltr">

El despachador envía trabajos de notificación de cambios a la cola de trabajos del wiki cliente. Estos trabajos contienen una lista

The dispatcher posts changes notification jobs to the client wiki's job queue. These jobs contain a list

de cambios en los wikidatos. Cuando se procesa un trabajo de este tipo, el wiki cleint realiza los siguientes pasos:

of wikidata changes. When processing such a job, the cleint wiki performs the following steps:

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

# Si el cliente mantiene una caché local de datos de entidades, actualícela.

# If the client maintains a local cache of entity data, update it.

# Encuentra las páginas que necesitan ser re-renderizadas después del cambio. Invalidarlas y purgarlas de las cachés web. Opcionalmente, programar trabajos de re-renderización (o actualización de enlaces), o incluso re-renderizar la página directamente.

# Find which pages need to be re-rendered after the change. Invalidate them and purge them from the web caches. Optionally, schedule re-render (or link update) jobs, or even re-render the page directly.

# Encontrar qué páginas tienen cambios que no necesitan volver a renderizar el contenido, pero influyen en la salida de la página, y por lo tanto necesitan ser purgados de la caché web (esto puede ser en algún momento el caso de los cambios en los enlaces de idioma).

# Find which pages have changes that do not need re-rendering of content, but influence the page output, and thus need purging of the web cached (this may at some point be the case for changes to language links).

# Inyectar notificaciones sobre cambios relevantes en la tabla recentchanges del cliente. Para ello, las ediciones consecutivas del mismo usuario en el mismo elemento pueden ser [[#Coalescing Events|coalesced]].

# Inject notifications about relevant changes into the client's recentchanges table. For this, consecutive edits by the same user to the same item can be [[#Coalescing Events|coalesced]].

# Posiblemente también inyectar una "entrada nula" en el historial de las páginas respectivas, es decir, en la tabla de revisiones.

# Possibly also inject a "null-entry" into the respective pages' history, i.e. the revision table.

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

(Véase el comentario en la página de discusión sobre la tabla de cambios recientes frente a la tabla histórica)

: (See comment on discussion page about recentchanges versus history table)

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

<span id="Coalescing_Events"></span>

== EventosCoalescing de coalescenciaEvents ==

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

El sistema descrito anteriormente significa varias escrituras en la base de datos por cada cambio - y potencialmente muchas lecturas, dependiendo de lo que se necesite para renderizar la página. Y esto sucede en cada wiki cliente (potencialmente cientos) por cada cambio en el repositorio. Dado que las ediciones en el repositorio de Wikibase tienden a ser de grano muy fino (como el establecimiento de una etiqueta o la adición de un enlace al sitio), esto puede ser rápidamente problemático. La coalescencia de las actualizaciones podría ayudar a resolver este problema:

The system described above means several database writes for every change - and potentially many reads, depending on what is needed for rendering the page. And this happens on every client wiki (potentially hundreds) for every change on the repository. Since edits on the Wikibase repository tend to be very fine grained (like setting a label or adding a site link), this can quickly get problematic. Coalescing updates could help with this problem:

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

Como se explica en la sección [[#Dispatching Changes|Dispatching]], las entradas en el feed de cambios se procesan por lotes (por defecto, no más de 100 entradas a la vez).

As explained in the [[#Dispatching Changes|Dispatching]] section, entries on the changes feed are processed in batches (per

default, no more than 100 entries at once).

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">

Si se procesan varios cambios en el mismo elemento en el mismo lote, estos cambios pueden unirse si fueron realizados consecutivamente por el mismo usuario. Esto reduciría el número de veces que las páginas son invalidadas (y por lo tanto, eventualmente re-renderizadas. Todas las entradas necesarias en la tabla recentchanges (y posiblemente en la tabla de revisiones) pueden ser insertadas usando una sola petición a la base de datos. Este proceso puede ser ajustado mediante el ajuste del tamaño del lote y el retraso entre lotes.

If multiple changes to the same item are processed in the same batch, these changes can be coalesced together if they were all performed consecutively by the same user. This would reduce the number of times pages get invalidated (and thus eventually re-rendered. All the necessary entries in the recentchanges table (and possibly the revision table) can be inserted using a single database request. This process can be fine tuned by adjusting the batch size and delay between batches.

</div>