Datenbanksysteme II: Storage, Discs, and Raid. Ulf Leser

Transkript

1 Datenbanksysteme II: Storage, Discs, and Raid Ulf Leser

2 Content of this Lecture Storage hierarchy Seek times and throughput RAID level Some guidelines Ulf Leser: Implementation of Database Systems, Winter Semester 2012/2013 2

3 Differences Really expensive Register Very expensive Cache ~ 15 / GB Main Memory Difference ~10 4 ~ 0,04 / GB Disk Tape Ulf Leser: Implementation of Database Systems, Winter Semester 2012/2013 3

4 Storage Area Networks (SAN) Dedicated subsystem providing storage (and only storage) Virtualization of resources Facilitates management, storage assignment, backup etc. Ulf Leser: Implementation of Database Systems, Winter Semester 2012/2013 4

5 5 Schichten Architektur Mengenorientierter Zugriff Satzorientierter Zugriff Interne Satzschnittstelle Systempufferschnittstelle Datenmodellebene Logischer Zugriff Speicherstrukturen Dateischnittstelle Pufferverwaltung Betriebssystem Anfrageübersetzung, Zugriffspfadwahl, Zugriffskontrolle, Integritätskontrolle Sortierung, Transaktionsverwaltung, Cursorverwaltung Record Manager, Sperrverwaltung, Log / Recovery Speichermanagement, Puffermanagement, Caching-Strategien Externspeicherverwaltung Geräteschnittstelle Ulf Leser: Implementation of Database Systems, Winter Semester 2012/2013 5

6 Magnet- bzw. Festplattenspeicher Ulf Leser: Implementation of Database Systems, Winter Semester 2012/2013 6

7 Lesen von Daten von der Platte Seek Time: t s Arm positionieren Latenzzeit: t r Warten, bis gewünschter Sektor unter Lesekopf rotiert Im Durchschnitt ½ Plattenumdrehung Rotationsgeschwindigkeit: ~10000 Umdrehungen/Minute Disc Controller cachen oft komplette Tracks Dadurch reduziert sich Latenzzeit im Schnitt Wann genau? Transferrate: u Durchsatz der Schnittstelle von der Platte zum Hauptspeicher Ulf Leser: Implementation of Database Systems, Winter Semester 2012/2013 7

8 Entwicklung Quelle: Wikipedia Ulf Leser: Implementation of Database Systems, Winter Semester 2012/2013 8

9 Random versus Sequential IO Aufgabe: 1000 Blöcke à 4KB (=4MB) lesen T s = 5ms, T r = 3ms, U = 15 MB/s Random I/O Jedes mal Arm positionieren, jedes mal Latenzzeit 1000 * (5 ms + 3 ms) + Transferzeit von 4 MB > 8000 ms + 300ms ~ 8s Sequential IO Einmal positionieren, dann nur noch sequentiell lesen 5 ms + 3ms + Transferzeit von 4 MB 8ms ms ~ 1/3 s Unterschied: ein bis zwei Größenordnungen Index bei >5% Anfrageselektivität nicht mehr benutzen Ulf Leser: Implementation of Database Systems, Winter Semester 2012/2013 9

10 Was kann man besser machen? Zugriff parallelisieren Blöcke auf verschiedenen Platten lagern Diese können parallel positionieren und parallel lesen Blöcke redundant auf einer Platte speichern Seek-zeit verkürzen bei geschickter Anordnung RAID: Redundant Array of Independent Discs Unabhängig (voneinander) und billig Commodity Hardware zu schnellen und fehlertoleranten Systemen zusammenbauen RAID-Software im Diskcontroller oder im Betriebssystem Auch: Redundant array of inexpensive discs Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

11 Architektur Software-Raid Hardware-Raid Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

12 Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

13 Eigenschaften Beschleunigung beim Lesen einer Daten beim Schreiben einer Datei beim parallelen Lesen/Schreiben einer Datei durch verschiedene Prozesse Ausfallsicherheit Erkennen von Fehlern Fähigkeit zum Recovery Verringerung Ausfallwahrscheinlichkeit Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

14 RAID 0: Striping A B C D Datei A C B D Doppelte Bandbreite beim sequentiellen Lesen/Schreiben Zyklische Verteilung, wenn Blöcke gleich häufig gelesen werden Sonst Verteilung nach Zugriffshäufigkeit (Optimierungsproblem) Zugriffshäufigkeit aber i.d.r. nicht bekannt Keine Beschleunigung für Lesen eines einzelnen Blocks Konflikte beim Lesen mehrerer Dateien Datenverlust je wahrscheinlicher je mehr Platten Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

15 RAID 1: Spiegelung (mirroring) A B A B C D C D Doppelter Speicherbedarf Verdoppelte Lesegeschwindigkeit (wie RAID0) Außerdem konkurrierendes Lesen einer 1-Block Datei möglich der schnellere Kopf gewinnt Keine Beschleunigung beim Schreiben Erhöhte Ausfallsicherheit durch Redundanz Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

16 RAID0 versus RAID1 MTTF = Durchschnittliche Zeit bis zu einem Crash MTTR = Zeit benötigt für Reparatur MTTDL = Durchschnittliche Zeit bis zu einem Zustand, bei dem Daten nicht zugreifbar sind Also z.b. von Band wiederhergestellt werden müssen Annahme: MTTF = 3650 Tage, MTTR = 2 Tage RAID0 mit 2 Platten im laufenden Betrieb MTTDL 1 = 3650/2 = 1825 Tage RAID1 mit 2 Platten im laufenden Betrieb MTTDL = MTTDL 1 /2*MTTDL 1 /2 ~ Jahre Bei Unabhängigkeit der Ereignisse Plattenfehler sind i.d.r. aber nicht unabhängig: Spannungsspitzen, Wasserschaden, gleichzeitiges Altern,... Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

17 RAID 0+1: Striping und Spiegelung A A B B C C D D Weiter erhöhte Lesegeschwindigkeit Lesen eines einzelnen Blocks kaum schneller als ohne RAID Doppelter Speicherbedarf Erhöhte Ausfallsicherheit Schreibgeschwindigkeit einer Datei verdoppelt sich Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

18 RAID 2: Striping auf Bit-Ebene Datei Höherer Durchsatz schon beim Lesen einzelner Blöcke Aber: Lesen 1 Sektor dauert i.d.r. genauso lange wie 1/8 Sektor Also Aufteilung von Blöcken auf Sektoren beachten Keine Beschleunigung für parallele Leseoperationen Jedes Lesen/Schreiben braucht alle Platten Verschlechterte Ausfallsicherheit Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

19 RAID 3: RAID2 + Paritätsinfo Datei Parität RAID2 plus eigene Platte für Parität Parität = bit-weise xor Ausfall einer Platte kann kompensiert werden Lesen/Schreiben Block erfordert Zugriff auf alle Platten Wenn Parity kontrolliert wird Weniger Platzbedarf als RAID1, trotzdem Ausfallsicherheit Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

20 RAID 3: Plattenausfall Datei Parität Reparatur Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

21 RAID 4: Striping von Blöcken + Parität A E B F C G D H P A-D P E-H Bessere Lastbalancierung als RAID 3 Verschiedene Prozesse können parallel von versch. Platten lesen Paritätsplatte ist Flaschenhals Bei jedem Schreiben muss darauf zugegriffen werden Bei Modifikation von Block A zu A : P A-D := P A-D A A Bei jedem Lesen muss darauf zugegriffen werden (Kontrolle) Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

22 RAID 5: RAID4, Verteilung der Paritity A E B F C G D P E-H P A-D H I M J P M-P P I-L N K O L P Parity immer auf der Platte, die keinen der Blöcke enthält Wesentlich bessere Lastbalancierung als RAID4 Paritätsplatte kein Flaschenhals mehr Schreiben erfordert X-1 Platten für die Daten und 1 weitere Platte für Parity Langsamer als RAID10, aber platzsparender Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

23 Übersicht Weitere RAID Level: 6, Kombination 1+5,... RAID 0 gut bei (nahezu) unveränderlichen Daten RAID 1 und vor allem 5 sind verbreitet RAID1: Einfach, schnell zu realisieren, erhöhte Ausfallsicherheit und Geschwindigkeit, aber verdoppelter Platzbedarf (billig) RAID5: Relativ komplex, erhöhte Ausfallsicherheit und Geschwindigkeit, erhöhter Platzbedarf; mindestens 3 Platten Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

24 Zusammenfassung Quelle: WikiPedia Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

25 Some Options without RAID Parallelization by distributing tablespaces System tablespace on separate disk Or: tablespace-managed data dict. Separate data and index tablesp. Separate disk for REDO Logs Parallelization by distributing one tablespace Parallelization by distributing a single table Distribution of segments Logical Database Tablespace Segment Extent Block Partitioning - semantic distribution of table data All sales prior to 2005 on one disk, all sales this year on another disk One disk for sales in 2005, 2004, 2003, Data file OS Block Physical Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

26 Interference Database Tablespace Data file Logical Segment Extent Physical Block OS Block Single-file tablespace might get stripped over multiple disks Multi-file distributed tablespace might not help if all files RAID-distributed over the same disks Parallel reads must be consumed somewhere parallel memory access, parallel processing units Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

27 Some guidelines Tsps should stripe over at least as many devices as CPUs You should stripe tablespaces for tables, indexes, rollback segments, and temporary tablespaces. You must also spread the devices over controllers, I/O channels, and internal buses Queries can run in parallel (inter-query parallelization) Single disk is bottleneck multiprocessors become useless Ideally, each disk becomes a feed for a one processor RAID1 (or above) or manually place files, segments, and extents Disadvantages No simple backup of tablespace by file copying Increased failure rate use redundant RAID levels Recovery of a disk might stop operations (all disks are involved) Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

28 Guidelines 2 In high-update OLTP systems, the redo logs are writeintensive. Moving the redo log files to disks that are separate from other disks and from archived redo log files has benefits Every transaction generates REDO information REDO is written in batches before Commit, data blocks are written sporadically by db-writer Both should not interfere (requires too much disk head moving) Hence: put REDO log files away from data files Redo data is extremely important (rollback, rollforward) Hence: spread REDO data redundantly over many disks (REDO groups) Also: Disk crash can only effect REDO or data files REDO disks are good places to invest in RAID10 Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

29 Typical Bottlenecks Temporary tablespace used especially for large SORTS And sorting is everywhere sort-merge join, group by, order by, distinct,... Sees many concurrent accesses from many processes Hot spot fast reads, fast writes, but failure is not critical System tablespace Holds data dictionary Required all the time logs, latches, system log data,... Especially logs can be a bottleneck REDO log files Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

30 Oracle flexible architecture (OFA) Ulf Leser: Implementation of Database Systems, Winter Semester 2012/

31 OFA - Quote The minimum configuration consists of seven data areas, either disks, striped sets, RAID sets,... The more heads you have moving at one time, the faster your database will be. AREA1: Oracle executables and user areas, a control file, the SYSTEM tablespace, redo logs AREA2: Data-data files, a control file, tool-data files, redo logs AREA3: Index-data files, a control file, redo logs AREA4: Rollback segment-data files AREA5: Archive log files AREA6: Export Files AREA7: Backup Staging Ulf Leser: Implementation of Database Systems, Winter Semester 2012/