RankSQL Query Algebra and Optimization for Relational Top-k Queries Václav Nádraský Jan Kašpar

Obsah Motivace Úvod Ranking query model Rank-relational algebra Execution model Optimalizace plánů Experimenty

Motivace Co je RankSQL? Framework pro efektivní vyhodnocování top-k dotazů Přináší rank-aware relační algebru a nové metody pro optimalizaci top-k dotazů

Úvod Využití top-k dotazů Podobnost v multimediálních DB Prohledávání webových DB Middlewares Dobývání znalostí (Data Mining) spousty dalších...

Úvod Charakterisika top-k dotazů Uživatele nezajímá celkové pořadí – chce vědet jen prvních (k) záznamů Ohodnocovací funkce (použitá k řazení) často uživatelsky definovatelná (drahá na výpočet) Vstupní data bývají často velmi rozsáhlá (spojení je drahé)

Úvod Dnešní podpora velmi omezená Mimo jádro dotazovacích strojů RankSQL přináší možnost implementace jako first-class construct Přímo v jádře plánovače a optimalizátoru

Příklad SELECT TOP k * FROM Hotel h, Restaurant r, Museum m WHERE c1 AND c2 AND c3 ORDER BY p1 + p2 + p3 c1: r.Cusine = Italská c2: h.Price + r.Price < 100 c3: r.Area = m.Area p1: Cheap(h.Price) p2: Close(h.Addr, r.Addr) p3: Related(m.Collection, „dinosaur“)

Úvod Dnešní DB Načíst záznamy ze všech vstupů Vytvořit spojení Vypočítat predikáty p1, p2, p3 pro každý výsledek spojení Seřadit podle p1+p2+p3 Vrátit prvních k z výsledku uživateli Dnešní DBS optimalizují Mimo jádro – hůře optimalizovatelné

Úvod Součásti RankSQL Nová vlastnost relační algebry ranking jako first-class contruct Nový pipeline and incremental execution model Rank-aware optimalizace

Ranking Query Model

Kanonická forma dotazu Q =  * k  F(p1,...,pn)  B(c1,...,cm) (R 1 x... x R h ) Dvě operace Filtrování – booleovská funkce  B (selekce) Řazení – monotónní ohodnocovací fce  F

Kanonická forma dotazu

Klasický relační model

Klasický relační model Optimalizace řazení pomocí rozdělení a prokládání není možná Operátor řazení monolitický Vyhodnocován jako celek Schema materialize-then-sort Nevhodné pro optimalizace Cílem je Splitting Vyhodnocovat predikáty postupně Interleaving Prokládat s jinými operátory

Rozšíření relační algebry Řazení jako first-class contruct Nutno rozšířit relační algebru Rank-relation algebra Nová relace s řazením (rank-relation) Nová vlastnost ranking Vedle booleovského membership Rozšířeny booleovské operátory o podporu ranking Nový operátor rank

Rozšíření relační algebry Relace s řazením Vznikne seřazením obyčejné relace nějakou ohodnocovací funkcí F( p1,...,pn ) Zpočátku pořadí dáno pořadím na disku Průběžne aplikovány operátory rank Nutné definovat částečné pořadí (parial-ranking) pomocí tzv. upper-bound (maximální možné) skóre Jako hodnota zatím nespočítaného predikátu se bere aplikací určená maximální hodnota

Princip řazení

Rank-aware Operátory

Rank-aware Operátory

Algebraické zákony Sada pravidel pro převádění kanonické formy dotazu do jiné ekvivalentní formy Je na nich postavena optimalizace Nutno dodefinovat pro nový rank operátor

Algebraické zákony pro rank

Algebraické zákony pro rank

Execution model

Plán pro vyhodnocování dotazů Většinou implementovány jako strom operátorů – tzv. iterátorů Všechny iterátory implementuje společné rozhraní Metody Open, GetNext, Close Rekuzovní průběh dotazu Rekurzivní volání metody GetNext od kořene stromu až k listům Dovoluje proudové (pipeline) a inkrementální zpracování Jeden záznam výsledku odpovídá jednomu průchodu stromem Např. iterátor selekce může po provedení své operace (zjištění pravdivosti podmínky) ihned vrátit záznam na výstup – narozdíl od operátoru sort, který vždy, než něco vrátí, musí počkat na kompletní výsledek z podřízeného iterátoru

Execution model klasické relační algebry Pipelining může být narušen blokujícím operátorem Například operátor sort pracující na principu materialize-then-sort Blokující operátory chceme nahradit za neblokující Časovou náročnost chceme mít proporcionálník k parametru k

Incremental Execution Model Odlišnosti rank-relation modelu od klasického Každý iterátor inkrementálně vrací záznamy v pořadí daném relací Vykonávání se zastaví po k nalezených výsledcích

Princip inkrementálního vyhodnocování

Execution model Kardinalita mezivýsledků a počet operacích závisí na kontextu Tj. umístění operátoru ve stromě vůči ostatním Prostor pro optimalizace Např. pomocí odhadování kardinality

Execution model Implementace fyzického operátoru „µ“ Pomáhá při načítání dat z indexů Dopad na celý optimalizátor Spojení tabulek HRJN – hash rank-join NRJN – nested-loop rank-join

Execution model – „µ“ Práce na fyzické vrstvě indexů B+stromy (rank-scan) Rozhodování na úrovni indexů databáze Existuje-li seřazený index nad predikátem, je použit Jinak se čte index sekvenčně a je aplikačně seřazen

Optimalizátor dotazů

Optimalizátor dotazů s hodnocením S rozšířením algebry je potřeba rozšířit optimalizátor (problém materialize-then-sort) Model náročnosti dotazů - hledání optimálního

Plány dotazu Velké množství plánů - náročné hledání Dělení (splitting) Prokládání (interleaving) Problém nalezení efektivního plánu spuštění Shora dolu, zdola nahoru

Reprezentace plánů

Optimalizátor dotazů Transformace a implementace Nové transformační pravidla pro RankSQL Transformace Převod mezi ekvivalentními algebraickými výrazy Implementace Převod logických operátorů na fyzickou reprezentaci stromu plánu

2-dimensionální vyčíslení Základem jsou 2 logické hodnoty Členství (R) a rádící hodnota (P) Vyčíslení logického výrazu a volba optimálního spojení tabulek Pro jeden výraz může být více plánů Optimalizátor vybere optimální

2-dimensionální vyčíslení Může být rozšířeno o další dimenze Selekce, sloučení,... Nesmí ovlivnit optimalizaci plánů bez hodnotícího operátoru

Náročnost plánů Odhady se provádějí na vzorku dat Z malého vzorku se vypočítá odhadovaná náročnost celého plánu Procentuální vyjádření vzroku – s% Card(P) = u / (s%) u – počet záznamů na výstupu

Náročnost plánů - graficky Tabulka o N záznamech s% s% – vybraný vzorek dat tabulky - procentuálně k’ – odhadnutý výsledek na vzorku k – odhadovaný počet řádků dotazu Na vzorek dat se aplikuje SQL dotaz k’k’ k Na základě procentuálního vyjádření vzorku dat systém vypočte odhadovaný výsledek

Ohodnocení plánu Ohodnocení plánu závisí na jeho kardinalitě a náročnosti plan’ je rozšířený původní plán o operator hodnocení

Náročnost plánů Závisí na odhadu kardinality Kardinalita není propagována skrze strom plánu Náročnější odhady

Exerimenty

Experimenty - plány Různé plány pro jeden SQL dotaz SELECT * FROM A, B, C WHERE A.jc1=B.jc1 AND B.jc2=C.jc2 AND A.b AND B.b ORDER BY f1(A.p1)+f2(A.p2)+ f3(B.p1)+f4(B.p2)+f5(C.p1) LIMIT k

Odhad kardinality Pro různé plány vznikají různé odhady kardinality výsledku

Testování výkonu Experimenty jsou závislé na mnoha faktorech k – počet výsledných řádků ( ) s – počet řádků v tabulce (10 – 100 tis.) j – join selectivity (0.001 – … resp – řádků) c – náročnost hodnotícího predikátu ( )

Testování výkonu Závislost výkonu na počtu řádků výsledku Zde je videt, že počet řádků výsledku nemá přílišný vliv na výkon. Naopak je vidět výkon jednotlivých plánů dotazu.

Testování výkonu Závislost výkonu na velikosti vstupní tabulky Pokud roste počet rádků vstupní tabulky, čas vykonání dotazu se zvětšuje exponenciálně.

Závěr Zavedení rank-relační algebry Hodnotící funkce Model rozdělení a prokládání Operátor hodnocení „µ“ Optimalizece plánů dotazu Odhad náročnosti plánů Výkon implementace

Zdroje C. Li, K. C.-C. Chang, I. F. Ilyas, and S. Song. Ranksql: Query algebra and optimization for relational top-k Queries. In SIGMOD, 2005,