HPI – BD19/20 – RDBMS Internals

Als Teil der Lecture Series des HPI hier Teil 3 der Big Data-Vorlesung mit „RDBMS Internals„.

Zuletzt – Teil 2: HPI – BD19/20 – Database Systems Recab

Hier geht es nochmal darum, wie Datenbanken im intern funktionieren.

Memory Hierarchy – klassisch gibt es verschiedene Abstufungen von schnell, teuer und klein (Register, Cache – in Kilobyte) zu langsam, günstig und damit typischerweise umfangreich (Bandlaufwerke – in Terabyte). Hauptspeicher und Festplatte liegt hier dazwischen. Flash ist ein modernerer Baustein dazwischen.

Von Hauptspeicher zu Festplatte gibt es ein Access Time Gap.

Das Potential von Festplatten ist ausgereizt durch physikalische Grenzen.

Datenbank-Layerarchitektur – Man kann die folgenden 5 Layer unterscheiden:

  • Datenmodell – SQL, Tabellen
  • Logischer Zugriff – Wie wird der Zugriff gehandhabt
  • Memory – Indexstrukturen usw.
  • Pufferverwaltung – Optimierung von Zugriffen
  • Betriebssystem – Zugriff auf Festplatte, typischerweise für kleine Dateien optimiert -> Ansatz für Datenmanagement!

-> Nicht jede Datenbank hat zwingend alle Layer!

Access Methods – von der Festplatte wird nicht der einzelne Datensatz, sondern immer der gesamte Block gelesen. Indizes erleichtern das Auffinden. Ein wichtiger Index ist der B- und B*-Baum Index. Diese Indizes sind sehr flach und benötigen dadurch wenig Zugriffe. Für schnelle, zufällige Zugriffe eignet sich bspw. Hashing besser. Caching ermöglicht über verschiedene Strategien den Zugriff auf die Festplatte zu umgehen.

Query Processing – Eine Query (SQL) generiert einen Query Execution Plan, welcher die Verarbeitung der Daten bestimmt. Um den optimalen Plan zu finden gibt es entweder einen Rule-Based Optimizer oder Cost-Based Optimizer.

SAP Analytix-Fazit

Nun, SAP HANA zeigt es, schnelle Zugriffe durch die Haltung der Daten im Arbeitsspeicher sind heute State-of-the-Art. Große Caches helfen dabei natürlich auch, neben weiteren Techniken, Abfragen zu beschleunigen. So kann der Flaschenhals bzgl. des Zugriffs auf eine Festplatte umgangen werden.

Auch von der ABAP-Seite ist die Diskussion bekannt, wie interne Tabellen gehandhabt werden sollen. Hab ich eine sortierte Tabelle und frage diese dann per BINARY SEARCH ab. Oder definiere ich gleich eine Hash-Tabelle, welche für jedes lesen eine konstante, i. d. R. kurze Zeit benötigt.

Der BW-Berater kennt sich mit B-Bäumen aus. Wird dieser doch, soweit dies die Datenbank überhaupt unterstützt durch das Flag „Hohe Kardinalität“ in der Definition der Dimension eines InfoCubes generiert. Somit können schnelle selektive Zugriffe auf große Dimensionstabellen ermöglicht werden. Dem BW-Admin wird auch die Funkion, eine Statistik für die Daten aufzubauen gut gekannt sein. Damit kann der Cost-Based Optimizer einen optimalen Ausführungsplan ermitteln.

Alles in allem damit auch für den SAP-Kontext gute Grundlagen, dass Verständnis zu vertiefen.

 

Nächste Lecture: Big Data Stack

 

 

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s