přejít na obsah přejít na navigaci

Linux E X P R E S, Jaký byl P2D2 2017, paralelizace dotazů v PostgreSQL 9.6 a 10

Jaký byl P2D2 2017, paralelizace dotazů v PostgreSQL 9.6 a 10

P2D2

Prague PostgreSQL Developers Day 2017 je za námi, jaký byl? Jak je na tom současná a připravovaná verze PostgreSQL s paralelizací dotazů? 


P2D2 podesáté

Prague PostgreSQL Developers Day (P2D2) se v letošním roce konal už podesáté. Co na účastníky čekalo, kam se konference během let posunula? V posledních letech je jejím dějištěm Fakulta informačních technologií ČVUT v Praze, stejně tak platí, že konferenčnímu dni předchází den, kdy se konají školení. Nejinak tomu bylo i letos, kdy se však z kvůli nemoci lektora jedno plánované školení nekonalo, bylo však nahrazeno jiným.

Vlastní konferenční den začal jako obvykle registrací účastníků – kromě obvyklého balíčku materiálů od sponzorů a rovněž dost obvyklého hrnku (tentokrát výročního) každý dostal také konferenční tričko. Již od začátku byl k dispozici dostatek občerstvení; ostatně organizátoři již předem vybízeli, ať účastníci přijdou dostatečně brzy (aby se všechno stihlo), že se mohou nasnídat až přímo na P2D2. V poledne pak byl k dispozici oběd (dvě jídla na výběr).

Stánky na P2D2 2017 Stánky na P2D2 2017

Kromě přednášek byla možnost navštívit také stánky, kde se daly zjistit informace o technologiích spjatých s databází PostgreSQL nebo zakoupit například trička, knihy či modré slony. Po organizační stránce všechno probíhalo naprosto hladce, jako ostatně vždy.

Z hlediska programového bylo vše v zásadě jako v předchozích letech. Přednášky byly zhruba 30 nebo 45 minut dlouhé, tři z nich byly vedeny zahraničními řečníky a součástí byl blok lightning talks (krátkých, pětiminutových přednášek – tentokrát byly jen dvě). Také v programové oblasti si konference drží svůj vysoký standard.

Co bylo oproti minulosti jiné, byla absence přednášky o novinkách nové verze PostgreSQL. Tomáš Vondra vysvětlil, že místo velkých převratných novinek se v poslední době objevují hlavně drobnější specializované věci. Jedné z nich se věnoval ve své přednášce o paralelizaci dotazů.

Paralelizace dotazů v PostgreSQL

Standardní architektura databázového systému PostgreSQL je založena na relaci připojení na databázi k procesům 1:1. Tedy každého připojeného klienta obsluhuje jeden proces. Takové řešení je jednoduché a robustní, má ale nevýhodu, že veškerá práce s daty probíhá jen sekvenčně, na jednom procesorovém jádře.

Sekvenční přístup je výhodnější u práce typu OLTP. „V OLTP aplikacích jsou ty dotazy typicky tak jednoduché, že kdybyste je chtěli paralelizovat, tak ten overhead, ta dodatečná práce, je tak náročná, že se to zpomalí,“ říká Tomáš Vondra. U OLTP se navíc předpokládá, že se prostředky saturují tím, že poběží současně více procesů (pro více připojení), které současně pracují.

Některé databáze mají sdílený pool procesů, z něhož se přidělují procesy jednotlivým připojením. PostgreSQL toto nedělá, v případě potřeby je to realizovatelné například nástrojem PgBouncer.

Pro OLAP je naopak typické, že připojení na databázi je malý počet, ale pracuje se nad velkým množstvím dat delší dobu. Zdroje se tak nesaturují. „Máte v serveru třeba 32 jader, ale v noci pracují tři. Ale běží na sto procent – při tom mapování 1:1.“ Vylepšení v PostgreSQL 9.6 cílí právě na aplikace typu OLAP.

Tomáš Vondra, jeden z organizátorů konference a přednášejících (foto: Martin Swiech) Tomáš Vondra, jeden z organizátorů konference a přednášejících (foto: Martin Swiech)

PostgreSQL 9.6 a 10

Po naplánování dotazu se databázový systém rozhodne, kterou část plánu může udělat paralelně. Řídí se při tom různými omezeními ohledně toho, co lze paralelizovat. Klíčovou operací je zde „gather“, která nastartuje potřebný počet procesů (workerů), které provedou paralelizovanou část plánu. Takovou částí může být třeba sekvenční sken (například hledání vzorů v textu). Každý worker prohledává svoji část dat.

Omezení na paralelizovatelnost jsou dvojího druhu: trvalá, která neumožní paralelizaci nikdy, a dočasná, která ji omezují jen v aktuální implementaci (PostgreSQL 9.6). Aktuálně například nelze paralelizovat při úrovni izolace transakcí SERIALIZABLE – to ale málokdy vadí, protože tato izolace se používá obvykle jen u OLTP. Naopak nikdy nepůjde paralizovat funkce označené jako PARALLEL UNSAFE (což je logické).

Současná implementace nepodporuje ani paralelizaci při práci se zámky (protože je workery sdílejí), nelze tedy v tomto režimu provádět manipulační operace. Běžné manipulační operace nebudou podporovány ani v chystané verzi 10. Dočkáme se ale zřejmě možnosti paralelizovat operace typu CREATE INDEX.

Paralelizovat nejdou (a ani v dohledné době nepůjdou) také suspendovatelné dotazy. Paralelizace není reentrantní, čili v rámci již paralelizovaného dotazu nelze dále paralelizovat (například subselecty). „Jinak by to bylo trochu jako s králíky,“ použil Tomáš Vondra přirovnání. „Na začátku máte jednoho králíka, nebo dva. A na konci roku jich máte milion, protože se vám rekurzivně pomnoží.“

Pro paralelizaci se v PostgreSQL používá partitioning. Ten funguje tak, že se data rozdělí na menší části a ty se přidělí jednotlivým workerům. Umožňuje to lepší využití prostředků než při pipeliningu, kdy se paralelizují podle fází zpracování.

Účastníci konference sledují přednášku (foto: Martin Swiech) Účastníci konference sledují přednášku (foto: Martin Swiech)

Zatím paralelizace funguje jen pro sekvenční sken – ten je totiž to nejjednodušší a zároveň tam paralelizace dává velký smysl. Ve verzi 10 by měla fungovat i pro bitmap index sken. Dále jsou již paralelizovány některé typy spojení tabulek – konkrétně nested loop a hash join (kde je ale zatím implementace dost naivní, protože si hešovou tabulku vytváří pro každý worker samostatně). Ve verzi 10 by měl být paralelizován i merge join.

Nejzajímavější z hlediska paralelizace jsou však agregační funkce. Agregace je rozdělena na dva kroky – první část (příprava mezivýsledků) se provede paralelně ve workerech, ve druhé se pak mezivýsledky zpracují dohromady (už neparalelizovaně). Většina agregačních funkcí je ve verzi 9.6 již paralelizována.

U vlastních funkcí je potřeba nastavit, zda je lze paralelizovat (PARALLEL SAFE, PARALLEL UNSAFE, PARALLEL RESTRICTED).

Dopady na výkon

Dopady paralelizace na výkon lze testovat například pomocí benchmarku TPC-H. Výsledky ukazují, že paralelizace velmi výrazně urychluje zpracování – i když se reálná rychlost s počtem workerů vzdaluje od rychlosti ideální a od jistého počtu už další dělení práce nemá smysl.

Bez podpory sponzorů by se konference nemohla uskutečnit Bez podpory sponzorů by se konference nemohla uskutečnit

Nahoru

Přidat téma diskuse

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Top články z OpenOffice.cz

Lukáš Jelínek

Lukáš Jelínek

Dlouholetý člen autorského týmu LinuxEXPRESu a OpenOffice.cz. Vystudoval FEL ČVUT v oboru Výpočetní technika. Žije v Kutné Hoře, podniká v oblasti IT a zároveň pracuje v týmu projektu Turris. Ve volném čase rád fotografuje, natáčí a stříhá video, občas se věnuje powerkitingu a na prahu čtyřicítky začal hrát tenis.


  • Distribuce: Debian, Kubuntu, Linux Mint
  • Grafické prostředí: KDE

| proč linux | blog