Datenbanksysteme II: Implementation of Database Systems Overview and General Architecture

Transkript

1 Datenbanksysteme II: Implementation of Database Systems Overview and General Architecture Material von Prof. Johann Christoph Freytag Prof. Kai-Uwe Sattler Prof. Alfons Kemper, Dr. Eickler

2 Speicherhierarchie Register (L1/L2/L3) Cache Hauptspeicher Plattenspeicher Archivspeicher Ulf Leser: Datenbanksysteme II, Sommersemester

3 Überblick: Speicherhierarchie Register Cache Hauptspeicher Plattenspeicher Archivspeicher 1 8 Byte Compiler Byte Cache-Controller 4 64 KB Betriebssystem Benutzer / Roboter Ulf Leser: Datenbanksysteme II, Sommersemester

4 Überblick: Speicherhierarchie 1-10ns Register ns Cache ns Hauptspeicher ms Plattenspeicher Zugriffslücke 10 5 sec - min Archivspeicher Ulf Leser: Datenbanksysteme II, Sommersemester

5 Ebenen Konzeptionelle Ebene Relationen, Tuple Attributwerte Variable Länge und Typ Logische Ebene Dateien Sätze Felder Physikalische Ebene Laufwerke Blöcke Zylinder und Sektoren Ulf Leser: Datenbanksysteme II, Sommersemester

6 5 Schichten Architektur Mengenorientierter Zugriff Satzorientierter Zugriff Interne Satzschnittstelle Systempufferschnittstelle Dateischnittstelle Datenmodellebene Logischer Zugriff Speicherstrukturen Pufferverwaltung Betriebssystem Anfrageübersetzung, Zugriffspfadwahl, Zugriffskontrolle, Integritätskontrolle Sortierung, Transaktionsverwaltung, Cursorverwaltung, Data Dictionary Physical Record Manager, Index Manager, Sperrverwaltung, Log / Recovery Seitenverwatung, Puffermanagement, Caching Externspeicherverwaltung Geräteschnittstelle Ulf Leser: Datenbanksysteme II, Sommersemester

7 Objekte und Operationen Mengenorientierter Zugriff Satzorientierter Zugriff Interne Satzschnittstelle Systempufferschnittstelle Dateischnittstelle Geräteschnittstelle Datenmodellebene Logischer Zugriff Speicherstrukturen Pufferverwaltung Betriebssystem SQL: select... from... Where Grant access to... Create index on... OPEN FETCH CLOSE (Tab o. Ind) STORE Record STORE: RECORD auf Seiten Aktualisierung aller Zugriffspfade, Implementierung B*-Baum READ page WRITE page Disc driver MOVE head... Ulf Leser: Datenbanksysteme II, Sommersemester

8 Schnittstellen Mengenorientierte Schnittstelle Zugriff auf Tupelmengen über deklarative Sprache SELECT... FROM... WHERE... Überwachung Datenintegrität und Autorisierung Satzorientierte Schnittstelle Zugriff auf typisierte Tupel Zugriff auf logischer Zugriffspfade (Indexe, Scans) Verwaltung Partitionen Interne Satzschnittstelle Zugriff auf uniforme, ungetypte Tupel Sperrverwaltung Verwaltung Abbildung Tupel (alle logischen Objekte) auf Seiten Implementierung und Aktualisierung der Zugriffspfade Ulf Leser: Datenbanksysteme II, Sommersemester

9 Systempufferschnittstelle Schnittstellen Zugriff auf Blöcke in virtuellem Adressraum Abbildung virtuelle auf physikalische Blockadressen Sperren und Freigeben von Blöcken Dateischnittstelle Zugriff auf physikalische Blöcke Verwaltung Block zu Segmenten, Tablespaces, Dateien Software-RAID Geräteschnittstelle Zugriff auf Daten der Festplatte Adressierung der Platten Platte, Spur, Sektor Cache des Controllers, Prefetching Hardware Raid Ulf Leser: Datenbanksysteme II, Sommersemester

10 5-Schichten Architekur Idealisierte Darstellung Muss nicht so implementiert werden Vielfältige Querverbindungen durch Synchronisierung, Recovery,... Schichten können zusammengefasst werden Z.B. Schicht satzorientierte und interne Satzschnittstelle Schichten müssen oftmals durch mehrere andere Schichten hindurch greifen können Caching benötigt für Prefetching Informationen über aktuelle Workload, nicht nur über das aktuelle Tupel Von Schicht 4 zu Schicht 1/2 Eventuell sogar von Schicht 5 zu Schicht 1/2 Optimierer benötigt Informationen über physische Verteilung von Blöcken auf Disc Von Schicht 1 zu Schicht 4/5 Verletzung des Information Hiding Prinzips Ulf Leser: Datenbanksysteme II, Sommersemester

11 Von unten nach oben Aber: Viele Themen kann man nicht so schön zuordnen Sperrverwaltung Recovery Anfragoptimierung... Datenmodellebene Logischer Zugriff Speicherstrukturen Pufferverwaltung Betriebssystem Ulf Leser: Datenbanksysteme II, Sommersemester

12 Magnet- bzw. Festplattenspeicher Ulf Leser: Datenbanksysteme II, Sommersemester

13 RAID 1: Spiegelung (mirroring) A B A B C D C D Datensicherheit: durch Redundanz aller Daten (Engl. mirror) Aber so keine Hilfe bei Bitfehlern wer hat recht? Doppelter Speicherbedarf Lastbalancierung beim Lesen: z.b. kann Block A von der linken oder der rechten Platte gelesen werden Aber beim Schreiben müssen beide Kopien geschrieben werden Kann aber parallel geschehen Dauert also nicht doppelt so lange wie das Schreiben nur eines Blocks Ulf Leser: Datenbanksysteme II, Sommersemester

14 Von unten nach oben Datenmodellebene Logischer Zugriff Speicherstrukturen Pufferverwaltung Betriebssystem In ca. 1 Woche: Abbildung Records und Blöcke auf Dateien Ulf Leser: Datenbanksysteme II, Sommersemester

15 Introduction to Access Methods Sequential File Access to records by record/tuple identifier (RID or TID) Operations: INSERT(Record): SEEK( TID): 1522 Bond Mason Miller... FIRST ( File): O(1) NEXT( File): O(1) EOF ( File): O(1) Move to end of file and add, O(1) Sequential scan, O(n) DELETE( TID): Seek TID; flag as deleted REPLACE( TID, Record): Seek TID; write record What happens if records have variable size? Ulf Leser: Datenbanksysteme II, Sommersemester

16 Index File Intro to Access Methods 2 Root Internal Node Leaves Operations: SEEK( TID): Use order in TIDs; O(log(n)) Only if tree is perfectly balanced INSERT( TID): Seek TID and insert; might require restructuring DELETE( TID): Seek TID and remove; might require restructuring REPLACE( TID): Seek TID and write Variable size TIDs? Ulf Leser: Datenbanksysteme II, Sommersemester

17 Storage in Oracle Database Tablespace Data file Logical Segment Extent Physical OracleBlock OS Block Data files are assigned to tablespaces Tablespaces may consist of multiple files All data from one object (table, index) are in one tablespace Unit of backup, offline, moveable tablespaces, quotas, access rights, Extents are continuous sequences of blocks on disc Space is allocated in extents (min, next, max, ) Segments logically group all extents of an object Ulf Leser: Datenbanksysteme II, Sommersemester

18 Managing space in Oracle Ulf Leser: Datenbanksysteme II, Sommersemester

19 Von unten nach oben Datenmodellebene Logischer Zugriff Speicherstrukturen Pufferverwaltung Logische zu physischen Blöcken Betriebssystem Ulf Leser: Datenbanksysteme II, Sommersemester

20 Caching = Buffer Management Page 1, P100) Buffer Manager MM Buffer Page 1 Page 2 P0 P1 P2 Disc Ulf Leser: Datenbanksysteme II, Sommersemester

21 Von unten nach oben Datenmodellebene Logischer Zugriff Speicherstrukturen In ca. 2 Wochen: Von Records zu virtuellen Blöcken; Indexstrukturen Pufferverwaltung Betriebssystem Ulf Leser: Datenbanksysteme II, Sommersemester

22 Record Addressing Mapping alternatives absolute addressing: TID = <PageId, Offset> Page Id Offset absolute addressing + search: TID = <PageId> Page Id -- Search -- Ulf Leser: Datenbanksysteme II, Sommersemester

23 Life is complex Oracle procedure for finding free space Free space is administered at the level of segments Logical database objects Explanation TFL: transaction free list PFL: process free list MFL: master free list HWM: High water mark Ulf Leser: Datenbanksysteme II, Sommersemester

24 Hashing Hash file consists of Set of buckets (one or more pages) B 0, B 1,..., B m-1, m>1 ; A hash function h(k) = {0,...m-1 } on a set K of keys; A hash table (bucket directory) as array of size m with pointers to buckets Hash files are structured according to one attribute value only Hash table Buckets with overflow pages Ulf Leser: Datenbanksysteme II, Sommersemester

25 R-Baum Beispiel Quelle: Geppert, Data Warehousing, VL SoSe 2002 Ulf Leser: Datenbanksysteme II, Sommersemester

26 Von unten nach oben Datenmodellebene Logischer Zugriff In ca. 4-5 Wochen: Anfrageoptimierung Speicherstrukturen Pufferverwaltung Betriebssystem Ulf Leser: Datenbanksysteme II, Sommersemester

27 Schichtenmodell Externes Schema Externes Schema Externes Schema Sichten Datenmodellebene Konzeptionelles Schema Logisches Modell (Tabellen, Attribute, Anfragen Herstellerabhängig Internes Schema Physisches Modell (Indexierung, Speicherung) Ulf Leser: Datenbanksysteme II, Sommersemester

28 Anfragen Externes Schema Externes Schema Externes Schema Konzeptionelles Schema Internes Schema Umschreiben der Anfragen; Viewexpansion Übersetzung der Anfrage Zugriffspfade, Indexwahl, Joinreihenfolge, Optimierung Ausführung des gewählten Plans Ulf Leser: Datenbanksysteme II, Sommersemester

29 Queries and Languages User Languages: SQL, QUEL, Embedded-SQL, 4GL Data Definition Language (DDL): Create, delete, change relations and other DB objects Tablespaces and partitions Indexes and views Users Authorization and authentication (Manage processes, system parameter, transaction isolation level, ) Data Manipulation Language (DML): Read, Delete, Create, Change Tuples Ulf Leser: Datenbanksysteme II, Sommersemester

30 Query Processing Declarative query SELECT Name, Address, Checking, Balance FROM customer C, account A WHERE Name = Bond and C.Account# = A.Account# Generate a Query Execution Plan FOR EACH c in CUSTOMER DO IF k.name = Bond THEN FOR EACH a IN ACCOUNT DO IF a.account# = c.account# THEN Output ( Bond, c.address, a.checking, a.balance) QEP Procedural Specification Semantically equivalent to query Ulf Leser: Datenbanksysteme II, Sommersemester

31 Query processing the interesting bit There are usually many, many possible QEPs for a query FOR EACH a in ACCOUNT DO FOR EACH c IN CUSTOMER DO IF a.account# = c.account# THEN IF c.name = BOND THEN Output ( Bond, c.address, a.checking, a. Balance) FOR EACH c in CUSTOMER WITH Name= Bond BY INDEX DO FOR EACH a IN ACCOUNT DO IF a.account# = c.account# THEN Output ( Bond, c.address, a.checking, a. Balance) Ulf Leser: Datenbanksysteme II, Sommersemester

32 Query Optimizer (cont.) QEP 1: Suppose index KName on Customer(Name) index Kno on Account(Account#) Search KNo Index using C,Account# Use Index KName for Bond Read CUSTOMER data file Read account info from ACCOUNT data file QEP 2: Account File is sorted Use Index KName for Bond Read CUSTOMER data file Sort CUSTOMERs on CUSTOMER.Account# ACCOUNT data file (sorted) Merge-Join Account# = Account# Ulf Leser: Datenbanksysteme II, Sommersemester

33 Query optimization Task: Find the (hopefully) fastest QEP Proof equivalence by rewriting algebra terms P1: σ Name=Bond (Account Customer) P2: Account σ Name=Bond (Customer) Enumerate and evaluate QEPs Usually can t be performed exhaustively General goal: Minimize size of intermediate results This is a local criteria Might mislead Expansive subplan with sorted result Cheap subplan with unsorted result Ulf Leser: Datenbanksysteme II, Sommersemester

34 Query optimization Method 1 Use heuristics to find better plans Push selections as far as possible Push projections as far as possible Does not use information about current state of relations and indexes Does not help much for join order Ulf Leser: Datenbanksysteme II, Sommersemester

35 Query optimization Method 2 Use statistics Use information on current state Size, value distribution, fragmentation, cluster factors, Let selectivity of σ Name=Bond be 5%, Customer =10.000, Account = FOR EACH a in ACCOUNT DO FOR EACH c IN CUSTOMER DO IF a.account# = c.account# THEN IF c.name = BOND THEN Output ( Bond, c.address, a.checking, a. Balance) * = 1.2E8 comparisons for join, then filter FOR EACH c in CUSTOMER WITH Name= Bond BY INDEX DO FOR EACH a IN ACCOUNT DO IF a.account# = c.account# THEN Output ( Bond, c.address, a.checking, a. Balance) Reduces Customer to 500 tuples, then 6E5 comparisons for join Ulf Leser: Datenbanksysteme II, Sommersemester

36 Join methods If query contains no selection Can t we do better than 1.2E8 comparisons for join, Nested loop join has complexity O(m*n) m,n: sizes of joined relations Other methods Sort-merge join First sort relations in O(n*log(n)+m*log(m)) Merge results in O(m+n) Might be better, but... external sorting is expensive Doesn t pay off if relations already in cache Hash join... Ulf Leser: Datenbanksysteme II, Sommersemester

37 Data Dictionary Statistics are useful but Need to be stored and accessed Need to be kept current Difficult problem! Query transformation and optimization needs data dictionary Semantic parsing of query: Which relations exist? Which indexes exists? Cardinality estimates of relations? Size of buffer for in-memory sorting?... Table_name Att_name Att_type size Avg_size Customer Name Varchar Customer account# Int 8 Customer... 8 Ulf Leser: Datenbanksysteme II, Sommersemester

38 Access Control Read and write access on objects GRANT, REVOKE Operations Example: GRANT ALL PRIVILIGES ON ACCOUNT TO Freytag WITH GRANT OPTION User Freytag has Read/Write access to the ACCOUNT relation it is possible for Freytag to grant this rights to others No complete protection: Granularity of access rights usually relation/attribute not tuple Access to data without DBMS Ask several questions to derive requested data In addition: File protection, encryption of data Ulf Leser: Datenbanksysteme II, Sommersemester

39 Von unten nach oben Datenmodellebene In ca. 8 Monaten: Transaktionen, Schedules, Recovery Logischer Zugriff Speicherstrukturen Pufferverwaltung Betriebssystem Ulf Leser: Datenbanksysteme II, Sommersemester

40 Transactions (TA) Transaction: Logical unit of work Begin_Transaction UPDATE ACCOUNT SET Savings = Savings + 1M SET Checking = Checking - 1M WHERE Account# = 007; INSERT JOURNAL <007, NNN, Transfer,...> End_Transaction ACID properties: A: Atomic Execution C: Consistent DB state after updates I: Isolation: No influence on result by concurrent executions D: Durability: Updates are reflected in the database Ulf Leser: Datenbanksysteme II, Sommersemester

41 Why Transactions? Lost Update Problem Deposit $ 1,000 Deposit $ 2,000 Read account value. 5,000 Add $1,000 6,000 Write back account value 5,000 6,000 Read account value 5,000 Add $ 2,000 7,000 7,000 Write back account value Ulf Leser: Datenbanksysteme II, Sommersemester

42 Synchronization and schedules? Ulf Leser: Datenbanksysteme II, Sommersemester

43 Synchronization and locks When are two schedules fine? When they are serializable I.e., when they are equivalent to a serial schedule Proof serializability of schedules Checking after execution is wasteful Synchronization protocols Guarantee only serializable schedules Require certain well-behavior of transactions Methods Two phase locking Multi-version synchronization Timestamp synchronization Ulf Leser: Datenbanksysteme II, Sommersemester

44 Deadlocks Locking is powerful, yet caution is necessary Runs into deadlock Deadlocks need to be discovered by database If not avoided by synchronization protocol Manage locks, lock-waits, lock-times, etc. Data dictionary Ulf Leser: Datenbanksysteme II, Sommersemester

45 Transaction Manager Synchronization is the I in ACID Transaction manager is responsible for Concurrency Control Concurrent access to data objects Synchronization & locking Correct access protocols Deadlock detection and deadlock resolution Recovery Compensating for system und transaction errors Based on log file Correct error recovery protocols undo; redo Close cooperation with Buffer Mgr. and CC Mgr. Ulf Leser: Datenbanksysteme II, Sommersemester

46 Recovery Broad Principle Transactions Concurrency Control Manager Secondary Main Memory (MM). Storage Recovery-Mgr. MM-Log Log S-Log Buffer-Mgr. MM-DB S-DB DB Store data redundantly Save old values Uses different file format, adapted to different access characteristics Sequential write, rare reads Ulf Leser: Datenbanksysteme II, Sommersemester

47 So many managers... Ulf Leser: Datenbanksysteme II, Sommersemester

48 Further topics Depend on time Parallel databases and parallel query execution Information integration and federated databases Data warehouses Database programming: PL/SQL, trigger, SQLJ Ulf Leser: Datenbanksysteme II, Sommersemester