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

Prezentace na téma: "RankSQL Query Algebra and Optimization for Relational Top-k Queries Václav Nádraský Jan Kašpar."— Transkript prezentace:

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

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

3 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ů

4 Ú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...

5 Ú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é)

6 Ú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

7 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“)

8 Ú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é

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

10 Ranking Query Model

11 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

12 Kanonická forma dotazu

13 Klasický relační model

14 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

15 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

16 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

17 Princip řazení

18 Rank-aware Operátory

19 Rank-aware Operátory

20 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

21 Algebraické zákony pro rank

22 Algebraické zákony pro rank

23 Execution model

24 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

25 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

26 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

27 Princip inkrementálního vyhodnocování

28 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

29 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

30 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

31 Optimalizátor dotazů

32 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

33 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

34 Reprezentace plánů

35 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

36 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í

37 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

38 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

39 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

40 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í

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

42 Exerimenty

43 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

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

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

46 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.

47 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ě.

48 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

49 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, http://eagle.cs.uiuc.edu/pubs/2005/ranksql-sigmod05-lcis-mar05.pdf