Manual:Database access/cs

Tento článek poskytuje přehled přístupu k databázi a obecných problémů s databází na MediaWiki.

Při kódování v MediaWiki budete obvykle přistupovat k databázi pouze prostřednictvím funkcí MediaWiki pro tento účel.

Rozložení databáze
Informace o rozvržení databáze MediaWiki, například popis tabulek a jejich obsah, naleznete v rozložení. Historicky to bylo v MediaWiki zdokumentováno také na, ale počínaje MediaWiki 1.35 dochází v rámci iniciativy Abstract Schema, k postupnému přesunu na. To znamená, že  se změní na   o, což usnadňuje generování souborů schématu pro podporu různých databázových strojů.

Použití sql.php
MediaWiki poskytuje skript údržby pro přístup k databázi z maintenance adresáře údržby:

Poté můžete zapisovat databázové dotazy. Alternativně můžete zadat název souboru a MediaWiki jej spustí, přičemž podle potřeby nahradí všechny speciální proměnné MW. Více informací najdete na stránce

To bude fungovat pro všechny databázové backendy. Výzva však není tak plnohodnotná jako klienti příkazového řádku dodávaní s vaší databází.

Použití klienta příkazového řádku mysql
V LocalSettings.php najdete heslo a uživatelské jméno vaší wiki pro MySQL, například:

Do SSH se přihlaste zadáním následujícího:

Nahraďte  a   informacemi. Poté budete vyzváni k zadání hesla, po kterém se zobrazí výzva.

Vrstva abstrakce databáze
MediaWiki poskytuje abstrakční vrstvu databáze. Pokud nepracujete na abstrakční vrstvě, nikdy byste neměli přímo volat funkce databáze PHP (například  nebo  ).

K abstrakční vrstvě se přistupuje prostřednictvím třídy. Příklad této třídy lze získat voláním  (přednostně) nebo pomocí   vložením. Funkce  se postupně vyřazuje a neměla by se používat v novém kódu. Buď se obvykle volá s jediným parametrem, kterým může být konstantní  (pro dotazy na čtení) nebo   (pro dotazy na psaní a čtení, které potřebují absolutně nejnovější informace). Rozdíl mezi základním a opakovaným je důležitý v prostředí více databází, jako je například Wikimedia. V části Balíčky funkcí (wrapper functions) níže najdete informace o tom, co můžete udělat s vráceným objektem.

Obálky výsledků výběrových dotazů jsou pole, jejichž klíče jsou celá čísla začínající na 1. K vytvoření dotazu pro čtení obvykle stačí něco takovéhoto:

""

Chcete-li napsat dotaz, použijte něco jako:

""

Používáme konvenci pro čtení a  pro zápis, abychom vám pomohli sledovat, zda je databázový objekt replikou (pouze pro čtení) nebo primárním (čtení/zápis). Pokud napíšete do repliky, svět exploduje. Nebo abychom byli přesní, následný zápisový dotaz, který uspěl na primárním serveru, může selhat při replikaci do repliky kvůli jedinečné kolizi klíče. Replikace na replice se zastaví a oprava databáze a její opětovné zprovoznění může trvat hodiny. Nastavením read_only v my.cnf na replice se tomuto scénáři vyhnete, ale vzhledem k hrozným následkům dáváme přednost co největšímu počtu kontrol.

SelectQueryBuilder
The class is the preferred way to write read queries, replacing the   family of  methods (see below). Usually, it is used in a "fluent" style, where you directly call methods on the query builder without assigning it to a variable, for example:

Tento příklad odpovídá dotazu:

JOINs jsou také možné. Například:

Tento příklad odpovídá dotazu:

You can access individual rows of the result using a foreach loop. Once you have a row object, you can use the operator to access a specific field. A full example might be:

There are also convenience functions to fetch a single row, a single field from several rows, or a single fields from a single row:

In this example, will be a row object like in the  example above,  will be an array of page ID values, and  will be a single page ID value.

Funkce obálky
Poskytujeme funkci query pro nezpracovaný SQL, ale funkce wrapperu jako select a insert jsou obvykle pohodlnější. Mohou se za určitých okolností postarat například o předvolby tabulek a escaping. Pokud opravdu potřebujete vytvořit svůj vlastní SQL, přečtěte si dokumentaci k tableName a addQuotes. Ob̟ě budete potřebovat. Nezapomeňte, že pokud nebudete správně používat addQuotes, můžete do své wiki vložit závažné bezpečnostní díry.

Dalším důležitým důvodem pro použití metod na vysoké úrovni, namísto vytváření vlastních dotazů, je zajištění správného fungování kódu bez ohledu na typ databáze. V současné době je nejlepší podpora pro MySQL/MariaDB. Existuje také dobrá podpora pro SQLite, je však mnohem pomalejší než MySQL nebo MariaDB. Existuje podpora pro PostgreSQL, ale není tak stabilní jako MySQL.

V následující části jsou uvedeny dostupné funkce obálky. Podrobný popis parametrů funkcí obálky (wrapper) najdete v dokumentech třídy 's. Zejména viz  pro vysvětlení ,  ,  ,  ,   a   parametrů, které používá mnoho dalších funkcí wrapperu.

Funkce wrapperu: select
Funkce select poskytuje rozhraní MediaWiki pro příkaz SELECT. Komponenty příkazu SELECT jsou kódovány jako parametry funkce select. Zde je příklad:

Tento příklad odpovídá dotazu

JOINs jsou také možné. Například:

Tento příklad odpovídá dotazu

poskytuje příklad jak používat tabulku aliasů v dotazech.

Argumenty jsou buď jednotlivé hodnoty (jako je 'category' a 'cat_pages > 0') nebo pole, pokud je pro pozici argumentu předána více než jedna hodnota (například ['cat_pages > 0', $myNextCond]). Pokud předáte řetězec třetím nebo pátým argumentům, musíte při vytváření řetězce ručně použít databázi Database::addQuotes, pokud sestavujete řetězec, protože to za vás wrapper neudělá. Hodnoty pro názvy tabulek (1. argument) nebo názvy polí (2. argument) nesmějí být kontrolovány uživatelem. Konstrukce pole pro $conds je poněkud omezená. Může provádět pouze vztahy rovnosti a  (tj. WHERE key = 'value').

K jednotlivým řádkům výsledku můžete přistupovat pomocí smyčky foreach. Jakmile máte řádkový objekt, můžete použít operátor  pro přístup ke konkrétnímu poli. Úplným příkladem může být:

Což vloží do proměnné $output abecední seznam kategorií s počtem položek, které má každá kategorie. Pokud vytváříte výstup jako HTML, ujistěte se, že jste hodnoty z databáze opustili pomocí

Pohodlné funkce
Pro kompatibilitu s PostgreSQL jsou idy vložení získány pomocí nextSequenceValue a insertId. Parametr pro nextSequenceValue lze získat z příkazu  v   a vždy odpovídá formátu x_y_seq, kde x je název tabulky (např. page) a y je primární klíč (např. page_id), např. page_page_id_seq. Například:

Pro některé další užitečné funkce, např. , atd., viz Příručka:Database.php#Functions.

Základní optimalizace dotazu
Vývojáři MediaWiki, kteří potřebují psát dotazy na DB, by měli mít určité znalosti o databázích a s nimi spojenými problémy s výkonem. Opravy obsahující nepřijatelně pomalé funkce nebudou přijaty. Neindexované dotazy nejsou na MediaWiki obecně vítány, s výjimkou zvláštních stránek odvozených z QueryPage. Pro nové vývojáře je obvyklé předkládat kód obsahující dotazy SQL, které zkoumají obrovské množství řádků. Pamatujte, že COUNT(*) je O(N), počítání řádků v tabulce je jako počítání fazolí v kbelíku.

Zpětná kompatibilita
Kvůli změnám návrhu DB jsou často nutné různé přístupy k DB pro zajištění zpětné kompatibility. To lze zpracovat například pomocí globálních proměnných a :

Replikace
Velké instalace MediaWiki, jako je Wikipedie, používají velkou sadu replik MySQL serverů replikujících zápisy provedené na primární MySQL server. Pokud chcete psát kód určený pro Wikipedii, je důležité porozumět problémům spojeným s tímto nastavením.

Často se stává, že nejlepší algoritmus pro daný úkol závisí na tom, zda se používá replikace. Kvůli našemu neustálému centrování na Wikipedii často používáme pouze verzi vhodnou pro replikaci. Ale pokud chcete, můžete použít a zkontrolovat, zda se replikace používá.

Prodleva
K nadměrnému zpoždění (lag) dochází především při odesílání velkých dotazů na zápis na primární server. Zápisy na primárním serveru jsou prováděny paralelně, ale jsou prováděny sériově, když jsou replikovány do replik. Primární server zapíše dotaz do binlogu, když je transakce potvrzena. Repliky se dotazují na binlog a začnou provádět dotaz, jakmile se objeví. Mohou číst služby, zatímco provádějí dotaz na zápis, ale nebudou číst nic víc z binlogu a nebudou tedy provádět žádné další zápisy. To znamená, že pokud dotaz na zápis běží dlouhou dobu, repliky budou za primárním serverem zaostávat po dobu, kterou trvá dokončení dotazu na zápis.

Zpoždění může být umocněno vysokou zátěží čtením. Nástroj pro vyrovnávání zátěže MediaWiki přestane odesílat čtení do repliky, když se zpozdí o více než 30 sekund. Pokud jsou poměry zatížení nastaveny nesprávně nebo pokud je zatížení obecně příliš velké, může to vést k tomu, že se replika trvale pohybuje se zpožděním 30 sekund.

Pokud jsou všechny repliky zpožděny o více než 30 sekund (podle ), MediaWiki přestane zapisovat do databáze. Všechny úpravy a další operace zápisu budou odmítnuty s chybou vrácenou uživateli. To dává replikám šanci vše dohnat. Než jsme měli tento mechanismus, repliky se pravidelně zpožďovaly o několik minut, což ztěžovalo kontrolu posledních úprav.

Kromě toho se MediaWiki snaží zajistit, aby uživatel viděl události na wiki v chronologickém pořadí. Několik sekund zpoždění může být tolerováno, pokud uživatel uvidí konzistentní obrázek z následných požadavků. To se provádí uložením pozice primárního binlogu v relaci a poté na začátku každého požadavku čekáním, až replika dožene tuto pozici, než z ní provedete jakékoli čtení. Pokud toto čekání vyprší, čtení je přesto povoleno, ale požadavek je považován, že je v „režimu zpožděné repliky“. Režim opožděné repliky lze zkontrolovat voláním. Jediným praktickým důsledkem v současné době je varování zobrazené v zápatí stránky.

Uživatelé prostředí Shell mohou kontrolovat zpoždění replikace pomocí. Ostatní uživatelé s rozhraním API.

Databáze mají často také své vlastní monitorovací systémy, viz například MariaDB (Wikimedie) a wikitech:Help:Toolforge/Database (Wikimedie Cloud VPS).

Vyhýbání se zpoždění
Chcete-li se vyhnout nadměrnému zpoždění, měly by se dotazy, které píší velké množství řádků, rozdělit. Obvykle psát vždy jeden řádek najednou. Víceřádkové VLOŽIT (INSERT) ... VYBRAT (SELECT) dotazy jsou nejhorší pachatelé a je třeba se jim úplně vyhnout. Místo toho proveďte nejprve výběr a poté vložení.

I malé zápisy mohou způsobit zpoždění, pokud jsou prováděny velmi vysokou rychlostí a replikace není schopna držet krok. Nejčastěji se to stává ve skriptech údržby. Abyste tomu zabránili, měli byste po každých několika stovkách zápisů volat. Většina skriptů umožňuje konfigurovat přesné číslo:

Práce se zpožděním
I přes naše nejlepší úsilí není praktické zaručit prostředí s malým zpožděním. Zpoždění replikace bude obvykle kratší než jedna sekunda, ale někdy může být až 30 sekund. Pro škálovatelnost je velmi důležité udržovat nízké zatížení primárního serveru, takže pouhé odesílání všech vašich dotazů na primární server není řešením. Pokud tedy skutečně potřebujete aktuální data, doporučuje se následující postup:


 * 1) Proveďte rychlý dotaz na primární server na pořadové číslo nebo časové razítko
 * 2) Spusťte celý dotaz na repliku a zkontrolujte, zda odpovídá datům, které jste získali z primárního serveru
 * 3) Pokud ne, spusťte celý dotaz na primárním serveru

Aby nedošlo k zaplavení primárního serveru pokaždé, když se repliky zpozdí, použití tohoto přístupu by mělo být omezeno na minimum. Ve většině případů byste měli pouze číst z repliky a nechat uživatele, aby se se zpožděním vypořádal.

Uzamčení sporu
Vzhledem k vysoké míře zápisu na Wikipedii (a některých dalších wiki) musí být vývojáři MediaWiki velmi opatrní při strukturování svých zápisů, aby se vyhnuli dlouhodobým uzamčením. Ve výchozím nastavení MediaWiki otevře transakci při prvním dotazu a potvrdí ji před odesláním výstupu. Zámky se budou držet od doby, kdy je dotaz proveden, až po potvrzení. Takže můžete zkrátit dobu uzamčení provedením co nejvíce zpracování, než začnete psát dotazy. Operace aktualizace, které nevyžadují přístup k databázi, mohou být zpožděny až po odevzdání přidáním objektu do.

Tento přístup často není dost dobrý a je nutné uzavřít malé skupiny dotazů do jejich vlastní transakce. Použijte následující syntaxi:

Použití blokovacích čtení (např. klauzule FOR UPDATE) se nedoporučuje. Jsou špatně implementovány v InnoDB a způsobí pravidelné chyby zablokování. Je také překvapivě snadné ochromit wiki s tvrzením o uzamčení.

Namísto zamykání čtení zkombinujte své existenční kontroly do svých písemných dotazů pomocí vhodné podmínky v klauzuli WHERE UPDATE nebo pomocí jedinečných indexů v kombinaci s INSERT IGNORE. Potom pomocí ovlivněného počtu řádků zjistěte, zda byl dotaz úspěšný.

Schéma databáze
Při vytváření databází nezapomeňte na indexy, na zkušební wiki s desítkami stránek může vše hladce fungovat, ale skutečná wiki se zastaví. Podrobnosti najdete výše.

Konvence pojmenování najdete na stránce.

SQLite kompatibilita
Při psaní definic tabulek MySQL nebo aktualizacích oprav je důležité si uvědomit, že SQLite sdílí MySQL schéma, ale funguje to pouze tehdy, pokud jsou definice psány specifickým způsobem:


 * Primární klíče musí být deklarovány v deklaraci hlavní tabulky, ale normální klíče by měly být přidány samostatně s CREATE INDEX:

Do definice hlavní tabulky by však měly být zahrnuty primární klíče zahrnující více než jedno pole:


 * Nepřidávejte do příkazu více než jeden sloupec:


 * Nastavte explicitní výchozí hodnoty při přidávání sloupců NOT NULL:

Základní kontroly kompatibility můžete spustit pomocí:


 * - MediaWiki 1.36+
 * - MediaWiki 1.35 and earlier

Nebo, pokud potřebujete testovat aktualizaci, postupujte takto:


 * - MediaWiki 1.36+
 * - MediaWiki 1.35 and earlier
 * Protože záplaty DB aktualizují také soubor tables.sql, pro tento by jste měli předat předběžnou verzi tables.sql (soubor s úplnou definicí DB). Jinak můžete získat chybu, pokud přetáhnete index (protože již neexistuje v tables.sql, protože jste jej právě odstranili).

Výše uvedené předpokládá, že jste v $IP/maintenance/, jinak zadejte úplnou cestu k souboru. Pro opravy rozšíření použijte ekvivalent těchto přípon.

Související stránky

 * &mdash; Pokud rozšíření vyžaduje změny v databázi při aktualizaci MediaWiki, lze to provést pomocí tohoto háčku. Uživatelé pak mohou aktualizovat svou wiki spuštěním.