Dit document is een concept. Er moet niet aangenomen worden dat hier de uiteindelijke architectuur wordt beschreven.
In dit document wordt beschreven hoe Wikibase wijzigingen in de repository doorgeeft aan alle client wiki's.
Overzicht
- Elke wijziging in de repository wordt opgenomen in de tabel die als een updatefeed voor alle cliëntwicks (zoals de wikipedia's) fungeert.
- De scripts van de dispatcher controleren periodiek deze tabel.
- Elke cliënt wiki wordt op de hoogte gebracht van wijzigingen in de veranderingen in de repository via een vermelding in de wachtrij voor werkzaamheden. Deze functies worden gebruikt om de relevante pagina(s) op de cliënt wiki te ongeldig maken en opnieuw te geven
- Kennisgevingen over de wijzigingen worden in de tabel recentchanges van de cliënt gezet om ze zichtbaar te maken op wachtlijsten, enz.
- Volgende bewerkingen door dezelfde gebruiker van hetzelfde gegevensitem kunnen worden gecombineerd tot één, om het wat overzichtelijker te maken.
Aannames en terminologie
De data die door de Wikibase repository wordt beheerd, is gestructureerd in (data)entiteiten. Elke entiteit wordt onderhouden als een wiki-pagina met gestructureerde gegevens. Er zijn verschillende soorten entiteiten, Maar één ding is in dit verband bijzonder belangrijk: items. Items zijn bijzonder omdat ze gekoppeld aan artikelpagina's op elke klantwiki (bijv. elke Wikipedia). Voor meer informatie, zie de datamodel primer.
Het verspreidingsmechanisme is gebaseerd op de veronderstelling dat elk gegevensitem in de Wikidata-repository maximaal één site-link naar elke cliënt wiki heeft en dat slechts één item in het repository een link kan maken naar een bepaalde pagina op een bepaalde cliënt wiki. Dat wil zeggen, elke pagina op een cliënt wiki kan worden geassocieerd met maximaal één gegevensitem in de repository.
- (Zie commentaar op de overlegpagina over de gevolgen van het beperken van de verspreiding van veranderingen tot gevallen waarin Wikipedia-pagina en Wikidata-item een verhouding hebben van 1:1)
Dit mechanisme veronderstelt ook dat alle wiki's, de repository en de cliënten (dat wil zeggen Wikidata en de Wikipedia's), rechtstreeks kunnen verbinden met de databases van elkaar. Dit betekent meestal dat ze in hetzelfde lokaal netwerk zitten. De wiki's kunnen echter afzonderlijke database-servers gebruiken: wiki's worden in secties gegroepeerd, waarbij elke sectie één master database en mogelijk vele slavendatabases heeft (tezamen een databasecluster vormt).
De communicatie tussen de repository (Wikidata) en de cliënten (Wikipedia's) vindt plaats via een up-to-date feed. Vooralsnog wordt dit geïmplementeerd als een databasetabel (de veranderingstabel) die direct wordt benaderd door de dispatcher-scripts, met behulp van het mechanisme "foreign database".
Ondersteuning voor 3rd partij cliënten, dat wil zeggen cliënt wiki's en andere consumenten buiten Wikimedia, is nu niet essentieel en zal voorlopig niet worden uitgevoerd. Het moet echter in alle ontwerpbeslissingen worden meegenomen.
Logboeken
Elke wijziging die op de repository wordt uitgevoerd, wordt in een tabel (de "veranderingstabel", namelijk wb_changes) in de database van de repo aangemeld. De tabel gedraagt zich op een vergelijkbare manier als de recentchangestabel van MediaWiki, omdat deze alleen wijzigingen voor een bepaalde tijd (bijvoorbeeld een dag of een week) bevat. In tegenstelling tot de recentchanges tabel bevat wb_changes echter alle informatie die nodig is om de wijziging op een cliënt wiki te melden en te reproduceren: naast informatie over wanneer en door wie de wijziging is gemaakt, bevat het een structurele verschil ten opzichte van de vorige revisie van de entiteit.
De tabel fungeert effectief als een actualisatiefeed. Er wordt zorgvuldig voor gezorgd dat de databasetabel als implementatie-detail wordt geïsoleerd van de updatefeed, zodat deze later kan worden vervangen door een alternatief mechanisme, zoals PubHub of een 'event bus'. Merk echter op dat een protocol met wachtrij-semantiek niet geschikt is (het zou per klant een wachtrij vereisen).
Wijzigingen doorvoeren
Veranderingen in de repository (bijv. wikidata.org) worden door een dispatcher script naar cliënt wikki's (bijv . Wikipedia's) verzonden. Dit script beoordeelt de tabel wb_changes van de repository voor wijzigingen en stuurt ze naar de cliënt wiki's door de juiste banen in de wachtrij van de cliënt te plaatsen.
Het dispatcher script is zo ontworpen dat een aantal instanties de inhoud kunnen uitvoeren en delen zonder dat ze elkaar vooraf kennen. Deze worden gecoördineerd via de database van de repo-instelling met behulp van de tabel wb_changes_dispatch:
- chd_client: de naam van de database van de cliënt (primaire sleutel).
- chd_latest_change: de ID van de laatste wijziging die aan de cliënt is verzonden.
- chd_touched: een tijdstempel die aangeeft wanneer de updates voor het laatst aan de cliënt zijn verzonden.
- chd_lock_name: de naam van het globale slot dat wordt gebruikt door de dispatcher die de cliënt momenteel bijwerkt (of NULL).
De dispatcher werkt door de volgende stappen te volgen:
- Lock en initialiseren
- Kies een klant om bij te werken uit de lijst met bekende klanten.
- Start DB-transactie op de master database van de repo.
- Lees de gegeven rij van de klant uit wb_changes_dispatch (als deze ontbreekt, ga dan uit van chd_latest_change = 0).
- Als chd_lock_name niet null is, roep dan IS_FREE_LOCK(chd_lock_name) aan op de client's master database.
- Als dat 0 retourneert, houdt een andere coördinator het slot vast. Sluit af (of probeer een andere client).
- Bepaal een slotnaam (dbname.wb_changes_dispatch. client of iets dergelijks) en gebruik GET_LOCK() om dat slot op de master database van de client te pakken.
- Werk de rij van de klant bij in wb_changes_dispatch met de nieuwe slotnaam in chd_lock_name.
- DB-transactie vastleggen op de master database van de repo.
- Voer de dispatch uit
- Haal N wijzigingen op met ID's > chd_latest_change van wb_changes in de database van de repo. N is de geconfigureerde batchgrootte.
- Filter wijzigingen voor die welke relevant zijn voor deze clientwiki (optioneel, en kan lastig zijn in complexe gevallen, bijv. cached queries).
- Plaats de corresponderende notificatie jobs ijzigingen in de taakwachtrij van de client wiki.
- Start DB transactie op repo's master database.
- Update de rij van de cliënt in wb_changes_dispatch met chd_lock_name=NULL en updated chd_last_change en chd_touched.
- Roep RELEASE_LOCK aan om het globale slot te vrij te geven.
- Geef de DB-transacties op de repo-database vrij (commit).
Dit kan meerdere malen worden herhaald door één proces, met een instelbare vertraging na elke lus.
Notificatie jobs wijzigingen
De dispatcher plaatst wijzigingsmeldingstaken in de taakwachtrij van de clientwiki. Deze jobs bevatten een lijst van Wikidata-wijzigingen. Bij het verwerken van zo'n job voert de client wiki de volgende stappen uit:
- Als de client een lokale cache met entiteitsgegevens bijhoudt, werk deze dan bij.
- Zoek welke pagina's opnieuw moeten worden weergegeven na de wijziging. Maak ze ongeldig en verwijder ze uit de webcaches. U kunt desgewenst taken voor het opnieuw opbouwen (of bijwerken van koppelingen) plannen, of zelfs de pagina rechtstreeks opnieuw opbouwen.
- Zoek uit welke pagina's wijzigingen hebben die niet opnieuw hoeven te worden weergegeven, maar die de pagina-uitvoer beïnvloeden en dus moeten worden opgeschoond van het web in de cache (dit kan op een gegeven moment het geval zijn voor wijzigingen in taallinks).
- Voeg meldingen over relevante wijzigingen toe in de tabel met recente wijzigingen van de klant. Hiervoor kunnen opeenvolgende bewerkingen door dezelfde gebruiker op hetzelfde item worden samengevoegd.
- Eventueel ook een "null-entry" toevoegen aan de geschiedenis van de respectievelijke pagina's, d.w.z. de revisietabel.
- (Zie commentaar op de overlegpagina over recente veranderingen versus geschiedenis tabel)
Samenvoegen gebeurtenissen
Het hierboven beschreven systeem betekent dat voor elke wijziging in verschillende databases wordt geschreven - en mogelijk veel worden gelezen, afhankelijk van wat er nodig is om de pagina op te bouwen. En dit gebeurt op elke cliënt wiki (potentieel honderden) voor elke wijziging in het repository. Aangezien bewerkingen in het Wikibase-repository vaak heel fijn zijn (zoals het plaatsen van een label of het toevoegen van een site-link), kan dit snel problematisch worden. Samenvoegen van updates kan helpen bij dit probleem:
Zoals uitgelegd in de sectie Wijzigingen doorvoeren, worden de records op de wijzigingsfeed in batches verwerkt (per standaard, niet meer dan 100 tegelijk).
Als er meerdere wijzigingen van hetzelfde item in dezelfde batch worden verwerkt, kunnen deze wijzigingen worden samengevoegd indien ze allemaal door dezelfde gebruiker in een opeenvolgende periode zijn uitgevoerd. Dit zou het aantal keren dat pagina's ongeldig wordt gemaakt (en dus uiteindelijk opnieuw moet worden weergegeven) verminderen. Dit proces kan worden aangepast door de batchgrootte en de vertraging tussen de batches aan te passen.