Umgehen von Moodle
| Back to OverviewAnfragebearbeitung
Könnte hilfreich sein um ein Moodle Desaster zu vermeiden.
Eine Anfrage wird wie folgt bearbeitet:
Dabei gibt es 3 Arten von Optimierungen:
- Regelbasierte Optimierung
- Führe Selektionen so früh wie möglich aus (vor Joins)
- Elimination von leeren Teilbäumen und gemeinsame Teilbäume erkennen
- Regeln:
- Selektionen können aufgebrochen werden
- Selektionen sind kommutativ
- Geschachtelte Projektionen können entfernt werden wenn gilt
- Selektionen können mit Projektionen vertauscht werden
- Kreuzprodukte und Joins sind kommutativ
- Selektionen und Join können vertauscht werden, falls die Selektion nur auf einem der beiden Join-Argumente operiert
- Vereinigungen und Schnitte sind kommutativ
- Join, Vereinigung und Schnitt sind assoziativ
- Selektion kann mit Vereinigung und Schnitt vertauscht werden
- Projektion kann nur mit Vereinigung vertauscht werden
- Selektion und Kreuzprodukt können zu einem Join zusammengefasst werden, wenns passt 12-15. Irrelevanter Kram / Selbstverständlich
- Kostenbasierte Optimierung
- Reihenfolge von Selektionen und Projektionen sind regelbasiert
- Reihenfolge von Joins und Kreuzprodukten sind kostenbasiert
- Schätzung von Zwischenergebnisgrößen (Selektivität heißt die Anzahl der Tupel die bei Auswertung eine Rolle spielen werden relativ zur Gesamtzahl)
- Selektion mit Bedingung :
- Join von :
- Schätzung:
- Parametrische Verteilung
- Histogramme
- Stichproben
- => Algorithmus
- Zerlege Selektionen
- Verschiebe Selektionen so weit wie möglich nach unten
- Vermeide Kreuzprodukte
- Kombiniere Selektionen und Kreuzprodukte zu Joins
- Verschiebe und teile Projektionen um nur benötigte Attribute zu erhalten
- Identifiziere Teilbäume die ausgewertet werden können
- Physische Optimierung
- Optimierung von Speicherhierarchien (Ausnutzen von Caches und RAM)
- Join Algorithmen
- Nested Loops: Bildung von Kartesischem Produkt und anschließende Selektion. Performance: scheiße
- Nested-Loop-Join: Bildung von Kartesischem Produkt und anschließende Selektion, aber nur für einen Speicherblock der SSD danach nächster. Performance: immernoch scheiße
- Sort-Merge: (Sortiere beide Relationen nach Join-Attribut) und führe dann einen Merge-Join aus. Performance: bei keinen Duplikaten gut, bei vielen scheiße
- Hash-Join: Statt sequenzieller Suche wird hash-suche verwendet. Performance: gut
Weitere Optimierungen:
- Indexstrukturen
- Daten sind nach Schlüssel sortiert
- Sekundäre Indizes sind weitere Indizes über andere Attribute.
- => B-Bäume google it wenn ihrs vergessen habt
- Sekundäre Indizes sind listen, die auf die Speicheradressen der Tupel verweisen (bzw. auf den Schlüssel). Optimierungen unter anderem R-Bäume