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í a.

Použití sql.php
MediaWiki poskytuje skript údržby pro přístup k databázi ze spouštěcího adresáře údržby:

Potom můžete napsat dotazy na databázi. Případně můžete zadat název souboru a MediaWiki jej provede, přičemž podle potřeby nahradí jakékoli speciální proměnné MW. Pro více informací viz

Toto bude fungovat pro všechny backendy databáze. Příkaz však není tak účinný jako klienti příkazového řádku, kteří jsou součástí vaší databáze.

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ázə
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  na vkládané , nebo pomocí funkce. 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 masterem a slave 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.

Výsledné obaly vybraných dotazů jsou pole, jejichž klíče jsou celá čísla začínající na 1. Chcete-li vytvořit dotaz pro čtení, obvykle stačí něco takového:

""

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 slave (pouze pro čtení) nebo master (čtení nebo psaní). Pokud píšete otrokovi, svět exploduje. Nebo přesněji, následný zápisový dotaz, který uspěl na masteru, může selhat, když je replikován na slave kvůli jedinečné kolizi klíčů. Replikace na slave se zastaví a může trvat několik hodin, než se databáze opraví a vrátí se zpět online. Nastavením read_only v my.cnf na slave se tomuto scénáři vyhnete, ale vzhledem k hrozným důsledkům dáváme přednost co největšímu počtu kontrol.

Wrapper functions
Poskytujeme funkci query pro surový SQL, ale funkce wrapper jako select a insert jsou obvykle výhodně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. MediaWiki má experimentální podporu pro Oracle a MSSQL.

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

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

Tento příklad odpovídá dotazu

JOINs jsou také možné; například:

Tento příklad odpovídá dotazu

provides an example of how to use table aliases in queries.

Argumenty jsou buď jednoduché hodnoty (například 'category' a 'cat_pages > 0') nebo pole, pokud je pro pozici argumentu předána více než jedna hodnota (například matice ('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, když 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:

Který vloží abecední seznam kategorií s počtem položek, které má každá kategorie v proměnné $output. Pokud vystupujete jako HTML, ujistěte se, že chcete uniknout hodnotám z databáze 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ř. affectedRows, numRows atd., viz Manual:Database.php.

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.

Replikace
Velké instalace MediaWiki, jako je Wikipedia, používají velkou sadu podřízených serverů MySQL replikujících zápisy na hlavní server MySQL. 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 replikace používá. 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 je replikace při použití.

Lag
K Lag dochází primárně, když jsou velké požadavky na zápis odesílány do masteru. Zápisy na masteru jsou prováděny paralelně, ale jsou replikovány do série, když jsou replikovány na slaves. Master píše dotaz do binlogu, když je transakce potvrzena. WSlaves dotazují 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 bude dotaz na psaní spuštěn po dlouhou dobu, budou slave zaostávat za masterem po dobu potřebnou k dokončení dotazu na zápis.

Lag může být zvýšen vysokým čtením. Vyrovnávač zatížení MediaWiki zastaví odesílání čtení slave, pokud je zpožděn o více než 30 sekund. Pokud jsou poměry zatížení nastaveny nesprávně nebo pokud je obecně příliš velké zatížení, může to vést k tomu, že se slave trvale vznáší kolem 30 sekund.

Pokud jsou všechny otroky 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á slaves šanci vše dohnat. Než jsme získali tento mechanismus, slaves se pravidelně zpožďovali o několik minut, což ztěžovalo revizi posledních úprav.

In addition to this, MediaWiki attempts to ensure that the user sees events occurring on the wiki in chronological order. A few seconds of lag can be tolerated, as long as the user sees a consistent picture from subsequent requests. This is done by saving the master binlog position in the session, and then at the start of each request, waiting for the slave to catch up to that position before doing any reads from it. If this wait times out, reads are allowed anyway, but the request is considered to be in "lagged slave mode". Lagged slave mode can be checked by calling. The only practical consequence at present is a warning displayed in the page footer.

Shell users can check replication lag with ; the other users with the API.

Databases often have their own monitoring systems in place as well, see for instance MariaDB (Wikimedia) and wikitech:Help:Toolforge/Database (Wikimedia Cloud VPS).

Lag avoidance
To avoid excessive lag, queries that write large numbers of rows should be split up, generally to write one row at a time. Multi-row INSERT ... SELECT queries are the worst offenders and should be avoided altogether. Instead do the select first and then the insert.

Working with lag
Despite our best efforts, it's not practical to guarantee a low-lag environment. Replication lag will usually be less than one second, but may occasionally be up to 30 seconds. For scalability, it's very important to keep load on the master low, so simply sending all your queries to the master is not the answer. So when you have a genuine need for up-to-date data, the following approach is advised:


 * 1) Do a quick query to the master for a sequence number or timestamp
 * 2) Run the full query on the slave and check if it matches the data you got from the master
 * 3) If it doesn't, run the full query on the master

To avoid swamping the master every time the slaves lag, use of this approach should be kept to a minimum. In most cases you should just read from the slave and let the user deal with the delay.

Lock contention
Due to the high write rate on Wikipedia (and some other wikis), MediaWiki developers need to be very careful to structure their writes to avoid long-lasting locks. By default, MediaWiki opens a transaction at the first query, and commits it before the output is sent. Locks will be held from the time when the query is done until the commit. So you can reduce lock time by doing as much processing as possible before you do your write queries. Update operations which do not require database access can be delayed until after the commit by adding an object to.

Often this approach is not good enough, and it becomes necessary to enclose small groups of queries in their own transaction. Use the following syntax:

Use of locking reads (e.g. the FOR UPDATE clause) is not advised. They are poorly implemented in InnoDB and will cause regular deadlock errors. It's also surprisingly easy to cripple the wiki with lock contention.

Instead of locking reads, combine your existence checks into your write queries, by using an appropriate condition in the WHERE clause of an UPDATE, or by using unique indexes in combination with INSERT IGNORE. Then use the affected row count to see if the query succeeded.

Database schema
Don't forget about indexes when designing databases, things may work smoothly on your test wiki with a dozen of pages, but will bring a real wiki to a halt. See above for details.

For naming conventions, see Manual:Coding conventions/Database.

SQLite compatibility
When writing MySQL table definitions or upgrade patches, it is important to remember that SQLite shares MySQL's schema, but that works only if definitions are written in a specific way:


 * Primary keys must be declared within main table declaration, but normal keys should be added separately with CREATE INDEX:

However, primary keys spanning over more than one field should be included in the main table definition:


 * Don't add more than one column per statement:


 * Set explicit defaults when adding NOT NULL columns:

You can run basic compatibility checks with:

Or, if you need to test an update patch, both:
 * (with the new tables.sql)
 * Since DB patches update the tables.sql file as well, for this one you should pass in the pre-commit version of tables.sql (the file with the full DB definition). Otherwise, you can get an error if you e.g. drop an index (since it already doesn't exist in tables.sql because you just removed it).
 * Since DB patches update the tables.sql file as well, for this one you should pass in the pre-commit version of tables.sql (the file with the full DB definition). Otherwise, you can get an error if you e.g. drop an index (since it already doesn't exist in tables.sql because you just removed it).

The above assumes you're in $IP/maintenance/, otherwise, pass the full path of the file. For extension patches, use the extension's equivalent of these files.