RankSQL

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

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) (R1 x ... x Rh) • 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. 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

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ů • 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 Na vzorek dat se aplikuje SQL dotaz Tabulka o N záznamech s% k’ Na základě procentuálního vyjádření vzorku dat systém vypočte odhadovaný výsledek k s% – vybraný vzorek dat tabulky - procentuálně k’ – odhadnutý výsledek na vzorku k – odhadovaný počet řádků dotazu

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, CWHERE A.jc1=B.jc1 AND B.jc2=C.jc2 AND A.b AND B.bORDER 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