Wikidata/Notizen/Verbreitung der Änderungen

From Meta, a Wikimedia project coordination wiki

This page is a translated version of the page Wikidata/Notes/Change propagation and the translation is 100% complete.

Diese Seite beschreibt, wie Wikidata Änderungen an Client-Wikis verbreitet.

• Jede Änderung an den Datenbanken wird in den letzte Änderungen des jeweils betroffenen Client-Wiki (z.B. die Wikipedias) vermerkt.
• Dispatcher-Skripte überprügen periodisch die letzten Änderungen.
• Jedes Client-Wiki wird über Veränderungen in der Wikidata-Datenbank durch einen Eintag in der Job queue informiert. Die eingetragenen Jobs werden zum Invalidieren und Re-Rendering der betroffenen Seiten genutzt.
• Jede Veränderung wird außerdem auf der Spezialseite Letzte Änderungen des betroffenen Client-Wikis sichtbar.
• Zum entlasten der Server können mehrere, aufeinanderfolgende Bearbeitungen des gleichen Benutzers am gleichen Wikidata-Datenobjekt können zu einem einzigen Edit zusammengefasst werden.

Die vom Wikibase-Repository verwalteten Daten sind in (Daten-) Entitäten strukturiert. Jede Entität wird als Wiki-Seite mit strukturierten Daten gepflegt. Es gibt verschiedene Arten von Entitäten, aber in diesem Zusammenhang ist jedoch eines besonders wichtig: Gegenstände. Gegenstände sind insofern besonders, da sie mit Artikelseiten in jedem Client-Wiki verknüpft sind (z. B. jeder Wikipediavariante). Weitere Informationen finden Sie in der Datenmodell-Primer.

Der Weitergabemechanismus basiert auf der Annahme, dass jedes Datenelement das im Wikidata Repository enthalten ist, höchstens eine Verknüpfung zu jedem Client-Wiki hat und nur ein Element im Repository kann auf eine bestimmte Seite in einem bestimmten Client-Wiki verweisen. Das heißt, jede Seite in jedem Client-Wiki kann höchstens einem Datenelement im Repository zugeordnet sein.

(Siehe Kommentar auf der Diskussionsseite zu den Konsequenzen der Beschränkung der Weitergabe von Änderungen auf Fälle, in denen Wikipediaseite und Wikidataelement eine 1:1 Beziehung haben.)

Dieser Mechanismus setzt auch voraus, dass alle Wikis, das Repository und die Clients (d. H. Wikidata und Wikipedias) untereinander direkt eine Verbindung zu den anderen Datenbanken herstellen können. In der Regel bedeutet dies, dass sie sich im selben lokalen Netzwerk befinden. Die Wikis können jedoch separate Datenbankserver verwenden: Wikis sind in Abschnitte unterteilt, in denen jeder Abschnitt eine Master-Datenbank und möglicherweise viele Slave-Datenbanken enthält (die zusammen einen Datenbankcluster bilden).

Die Kommunikation zwischen dem Repository (Wikidata) und den Clients (Wikipedias) erfolgt über ein Update-Feed. Derzeit ist dies als Datenbanktabelle (die Änderungstabelle) implementiert. Auf die Dispatcher-Skripte wird direkt über den Mechanismus "Fremddatenbank" zugegriffen.

Unterstützung für Drittanbieter Clients, d.h. Client-Wikis und andere Konsumenten außerhalb von Wikimedia, ist derzeit nicht unbedingt erforderlich und wird vorerst nicht implementiert. Es sollte jedoch in allen Designentscheidungen bedacht werden.

Jede am Repository vorgenommene Änderung wird in einer Tabelle protokolliert (nämlich der Änderungstabelle wb_changes) in der Repodatenbank. Die Änderungstabelle verhält sich ähnlich wie die recentchanges MediaWiki Tabelle, da sie Änderungen nur für eine bestimmte Zeit (z. B. einen Tag oder eine Woche) enthält. Ältere Einträge werden regelmäßig gelöscht. Im Gegensatz zur Tabelle "Recentchanges" enthält wb_changes jedoch alle Informationen, die erforderlich sind, um die Änderung an ein Client-Wiki zu melden und zu wiederholen. Außer Information wann die Änderung vorgenommen wurde und von wem, enthält es einen strukturellen Vergleich gegenüber der vorhergehenden Entität.

Tatsächlich fungiert die Änderungstabelle als Update-Feed. Es ist darauf zu achten, dass die Datenbank Tabelle als Implementierungsdetail isoliert wird, sodass sie später durch einen alternativen Mechanismus wie PubSub oder einen EventBus ersetzt werden kann. Beachten Sie jedoch, dass ein Protokoll mit Warteschlangensemantik nicht angemessen ist. Dies würde für eine Warteschlange pro Client erfordern.

Änderungen am Repository (z. B. wikidata.org) werden an Client-Wikis (z. B. Wikipedias) per Dispatcher-Skript gesendet. Dieses Skript fragt die Repository Tabelle wb_changes nach Änderungen ab und sendet sie an die Client-Wikis weiter, indem die entsprechenden Jobs in die Jobwarteschlange des Client gestellt werden.

Das Dispatcher-Skript ist so konzipiert, dass beliebig viele Instanzen ohne Last ausgeführt und gemeinsam genutzt werden können ohne Vorkenntnisse voneinander zu haben. Sie werden über die Datenbank des Repository mit der wb_changes_dispatch Tabelle abgeglichen:

• chd_client: Der Datenbankname des Clients (Primärschlüssel).
• chd_latest_change: Die ID der letzten Änderung, die an den Client gesendet wurde.
• chd_touched: Ein Zeitstempel, der angibt, wann Aktualisierungen zuletzt an den Client gesendet wurden.
• chd_lock_name: Der Name der globalen Sperre, die vom Dispatcher verwendet wird, der gerade diesen Client aktualisiert (oder NULL).

Der Dispatcher führt die folgenden Schritte aus:

1. Sperrt und initialisiert
   1. Wählt aus der Liste der bekannten Clients den Client aus, der aktualisiert werden soll.
   2. Startet die DB-Transaktion in der Stammdatenbank des Repos.
   3. Liest den Datensatz des angegebenen Clients aus wb_changes_dispatch aus (falls nicht vorhanden, wird chd_latest_change = 0 angenommen).
   4. Wenn chd_lock_name nicht null ist, wird IS_FREE_LOCK (chd_lock_name) in der Master-Datenbank des Clients aufgerufen.
   5. Wenn dies 0 zurückgibt, hält ein anderer Dispatcher das Lock. Entweder beenden oder versuchen mit einem anderen Client versuchen.
   6. Entscheiden Sie sich für einen Namen des Locks ("Datenbankname".wb_changes_dispatch."Client" oder ähnliches) und verwendet GET_LOCK(), um dieses Lock in der Masterdatenbank des Clients zu setzen.
   7. Aktualisiert den Datensatz des Clients in wb_changes_dispatch mit dem neuen Locknamen in chd_lock_name.
   8. DB-Transaktion in der Stammdatenbank des Repos abschliessen.
2. Führt Sie den Dispatch durch
   1. Holt sich n Änderungen mit IDs> chd_latest_change aus wb_changes in der Datenbank des Repos. n ist die konfigurierte Batchgröße.
   2. Änderungen die für dieses Client-Wiki relevant sind (optional und es könnte sich in komplexen Fällen als schwierig erweisen, z. B. zwischengespeicherte Abfragen).
   3. Veröffentlichung der entsprechenden Änderung Jobs in der Jobwarteschlange des Client-Wikis.
3. Log und entsperren
   1. Startet die DB-Transaktion in der Stammdatenbank des Repos.
   2. Aktualisiert den Clientdatensatz in wb_changes_dispatch mit chd_lock_name = NULL und aktualisiert chd_latest_change und chd_touched.
   3. Ruft RELEASE_LOCK() auf, um das globale Lock aufzuheben, die gehalten wurde.
   4. DB-Transaktion in der Stammdatenbank des Repos abschliessen.

Dies kann von einem Prozess mit einer konfigurierbaren Verzögerung zwischen den Läufen mehrmals wiederholt werden.

Der Dispatcher sendet Änderungsjobsbenachrichtigungen an die Jobwarteschlange des Client-Wikis. Diese Jobs enthalten eine Liste von Wikidata-Änderungen. Bei der Bearbeitung eines solchen Jobs führt das Client-Wiki die folgenden Schritte aus:

1. Wenn der Client einen lokalen Cache mit Entitätsdaten verwaltet, wird der aktualisiert.
2. Findet heraus, welche Seiten nach der Änderung neu gerendert werden müssen. Markiert diese Seiten als ungültig und löscht sie aus den Web-Caches. Optional können Jobs zum erneuten Rendern (oder Aktualisieren von Links) geplant werden oder die Seite sogar direkt erneuert werden.
3. Findet heraus, auf welchen Seiten Änderungen vorgenommen wurden, bei denen der Inhalt nicht erneut gerendert werden muss, die jedoch die Seitenausgabe beeinflussen und daher das Webcache gelöscht werden muss (dies kann manchmal bei Änderungen an Sprachlinks der Fall sein).
4. Fügt die Benachrichtigungen über relevante Änderungen in die Tabelle recentchanges des Clients ein. Zu diesem Zweck können aufeinanderfolgende Änderungen desselben Benutzers an demselben Element verbunden sein.
5. Fügt möglicherweise auch einen "Null-Eintrag" in die Seitengeschichte ein, d. H. in die Revisionstabelle.

(Siehe Kommentar auf der Diskussionsseite ueber den Vergleich der recentchanges Tabelle mit der history Tabelle)

Die oben beschriebene Funktionsweise bewirkt bei jeder Änderung auf Wikidata zahlreiche Transaktionen an Datenbanken, sowie möglicherweise häufiges Auslesen selbiger, je nach dem, was zum Rendering der Seite benötigt wird. Und dies geschieht auf jedem Client-Wiki, also möglicherweise auf über hundert solcher. Seitdem Änderungen an den Wikibase-Datenbanken dazu neigen, einzeln von einander getrennt zu werden (so zum Beispiel das Angeben einer Objektbeschreibung oder eines Links), kann sich dies problematisch auf die Server auswirken. Das Zusammenfügen von Änderungen kann diesem Problem entgegenwirken:

Wie bereits im Abschnitt über die Versendung der Änderungen erklärt, werden Einträge auf der Liste der Aufträge per Batchverarbeitung verarbeitet, standarmäßig umfassen die Batches nicht mehr als 100 Einträge.

Wenn mehrere Änderungen, die das gleiche Wikidata-Objekt betreffen, im gleichen Batch verarbeitet werden sollen, können diese zusammengefügt werden, wenn sie vom gleichen Benutzer getätigt worden sind. Dies verringert die Anzahl an Datenbanktransaktionen, da die betroffenen Änderungen zusammengefügt nur eine einzige Transaktion auslösen. Die Feinabstimmung dieses Prozesses kann durch das Einstellen der Batch-Größe und der Verzögerungszeit zwischen den Verarbeitungen von einzelnen Batches erfolgen.

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Wikidata/Notes/Change_propagation/de&oldid=23882512"

Category:

• Wikidata/de