Grundlegendes zu Blockgrößen


11

Meine Frage richtet sich an Postgres, aber die Antworten sind möglicherweise aus jedem Datenbankhintergrund gut genug.

Sind meine Annahmen richtig:

  • Festplatten haben eine feste Blockgröße?
  • RAID-Controller kann eine andere Blockgröße haben? Wird ein RAID-Block auf mehrere echte Festplattenblöcke aufgeteilt?
  • Das Dateisystem hat auch eine unabhängige Blockgröße, die wiederum auf die RAID-Blockgröße aufgeteilt wird.
  • Postgres arbeitet mit festen 8k-Blöcken. Wie erfolgt hier die Zuordnung zur Blockgröße des Dateisystems? Werden Postgres 8k-Blöcke vom Dateisystem gestapelt?

Ist es beim Einrichten eines Systems am besten, alle Blöcke auf 8k zu haben? Oder sind die Einstellungen nicht wirklich wichtig? Ich habe mich auch gefragt, ob einige "falsche" Einstellungen für die Blockgröße die Datenintegrität im Falle eines Absturzes gefährden könnten. Vielleicht, wenn ein Postgres 8k-Block auf mehrere Plattenblöcke aufgeteilt werden muss?

Oder wird nichts zusammen gestapelt und ich verliere daher bei jeder Nichtübereinstimmung zwischen definierten Blockgrößen Speicherplatz?

Antworten:


16

Plattensektoren

Eine Festplatte hat eine feste Sektorgröße, normalerweise 512 Byte oder 4096 Byte auf einigen modernen Festplatten. Diese Festplatten haben auch einen Modus, in dem sie 512-Byte-Sektoren emulieren. Die Festplatte enthält Spuren mit unterschiedlicher Anzahl von Sektoren. Spuren, die näher an der Außenseite der Platte liegen, haben mehr Sektoren, da sie mehr Platz für eine bestimmte Bitdichte bieten. Dies ermöglicht eine effizientere Nutzung des Speicherplatzes. Normalerweise hat eine Spur ungefähr 1.000 512-Byte-Sektoren auf einer modernen Festplatte.

Einige Formatierungsstrukturen können auch Fehlerkorrekturinformationen in den Sekunden enthalten, was sich darin manifestiert, dass die Festplatten auf niedriger Ebene mit 520- oder 528-Byte-Sektoren formatiert sind. In diesem Fall verfügt der Sektor noch über 512 Byte Benutzerdaten. Weder Windows noch Linux unterstützen dies direkt, obwohl i5OS (IBM iSeries) und verschiedene SAN-Controller dies tun.

Normalerweise wird der Sektor / Kopf / Spur in eine logische Blockadresse übersetzt; Aufgrund historischer Probleme mit der Abwärtskompatibilität hat die Geometrie (Köpfe x Sektoren x Spuren), die das Betriebssystem (insbesondere auf IDE- und SATA-Festplatten) sieht, normalerweise wenig mit seiner physischen Struktur zu tun.

RAID-Streifengröße

Ein RAID-Controller kann mithilfe von Striping eine Stripe-Größe für ein Array haben (z. B. RAID-5 oder RAID-10). Wenn das Array (zum Beispiel) einen 128k-Streifen hat, hat jede Festplatte 128k zusammenhängende Daten, und dann befindet sich der nächste Datensatz auf der nächsten Festplatte. Normalerweise können Sie damit rechnen, ungefähr einen Streifen pro Umdrehung der Festplatte zu erhalten, sodass die Streifengröße die Leistung bei bestimmten Workloads beeinträchtigen kann.

Partitionsausrichtung

Eine Festplattenpartition kann genau auf einen RAID-Streifen ausgerichtet sein oder nicht und kann aufgrund von geteilten Lesevorgängen zu Leistungseinbußen führen, wenn sie nicht ausgerichtet ist. Einige Systeme (z. B. Windows 2008-Server) konfigurieren Partitionen automatisch so, dass sie mit den Streifengrößen des Datenträgervolumens übereinstimmen. Einige (z. B. Windows 2003-Server) werden dies nicht tun, und Sie müssen ein Partitionsdienstprogramm verwenden, das die Streifenausrichtung unterstützt, um dies sicherzustellen.

Dateisystemblockgröße

Das Dateisystem weist Speicherblöcke in Blöcken einer bestimmten Größe zu. Im Allgemeinen ist dies konfigurierbar - beispielsweise unterstützt NTFS Zuordnungseinheiten von (IIRC) 4K bis 64K. Eine Fehlausrichtung von Partitionen und Dateisystemblöcken zu RAID-Streifen kann dazu führen, dass ein einzelner gelesener Dateisystemblock mehrere Festplattenzugriffe generiert, von denen nur einer erforderlich wäre, wenn die Dateisystemblöcke korrekt an den RAID-Streifen ausgerichtet wären.

Datenbankblockgröße

Die Datenbank weist Speicherplatz in einer Tabelle oder einem Index in einer bestimmten Blockgröße zu. Im Fall von SQL Server sind dies 8 KB, und auf vielen Systemen ist 8 KB die Standardeinstellung. Auf einigen Systemen wie Oracle ist dies konfigurierbar und auf PostgreSQL ist es eine Option zur Erstellung. Auf den meisten Systemen erfolgt die Zuweisung von Speicherplatz zu Tabellen normalerweise in größeren Blöcken, wobei Blöcke in diesen Blöcken zugewiesen werden.

Eine Fehlausrichtung von Dateisystem- und Datenzuordnungsblöcken kann mehrere E / A für einen einzelnen Blockschreibvorgang erzeugen, was zu Leistungseinbußen führen kann.

I / O Chunking

Normalerweise führt ein DBMS seine E / A in Blöcken von mehr als einem Block aus. Unter SQL Server werden beispielsweise alle E / A in Blöcken von 8 Blöcken (insgesamt 64 KB) ausgeführt. Unter Oracle ist dies konfigurierbar. Eine gelegentliche Überprüfung der PostgreSQL-Dokumente zeigt keine spezifische Beschreibung, ob PostgreSQL dies tut, daher bin ich mir nicht sicher, wie es auf dieser Plattform funktioniert.

Wenn der E / A-Block größer als die Dateisystemblockgröße ist oder nicht an den RAID-Streifengrenzen ausgerichtet ist, kann ein Festplattenschreibvorgang aus der Datenbank mehrere Festplattenschreibvorgänge verursachen, was zu einer Leistungsbeeinträchtigung führt.

Speicherplatznutzung

Es wird kein Speicherplatz verschwendet - die Datenbank-E / A verwendet einen oder mehrere physische E / A-Vorgänge auf der Festplatte - aber falsch eingestellte E / A können zu Ineffizienzen führen, die die Datenbank verlangsamen. Die wichtigsten Dinge, die in Einklang gebracht werden müssen, sind:

  • RAID-Streifen und -Partitionen - Die Partition sollte an einer RAID-Streifengrenze beginnen.

  • Dateisystem-E / A-Zuordnung und RAID-Stripe- / Partitionsgrenzen - Eine RAID-Stripe-Grenze muss an einer Dateisystem-Zuordnungseinheit ausgerichtet sein und sollte ein Vielfaches der Größe der Dateisystem-Zuordnungseinheit betragen.

  • Festplattenschreibgröße und Größe der Dateisystemzuordnungseinheit. Es sollte eine 1: 1-Beziehung zwischen Datenbank-E / A-Vorgängen und Dateisystem-E / A-Vorgängen bestehen.

Eine Fehlausrichtung führt nicht zu einem größeren Problem der Datenintegrität, als dies sonst der Fall wäre. Die Datenbank und das Dateisystem verfügen über Mechanismen, um sicherzustellen, dass die Dateisystemoperationen atomar sind. Im Allgemeinen führt ein Festplattenabsturz zu Datenverlust, jedoch nicht zu Datenintegritätsproblemen.


Sehr schöne Antwort. Ich fühle mich schlecht, wenn ich Ihnen nur eine Gegenstimme geben kann ...
Franz Kafka

Nur noch eine Frage: Was genau meinst du, wenn du über das Ausrichten sprichst? Ist das ein Vielfaches der kleineren Blockgröße? ZB sind 32k auf 8k ausgerichtet? Oder gibt es andere Faktoren?
Franz Kafka

@FranzKafka - Nein, dies bedeutet, dass etwas (normalerweise eine Festplattenpartition) an einem Ort beginnt, der kein ganzzahliges Vielfaches dessen ist, woran es ausgerichtet werden muss. Wenn ich beispielsweise eine RAK-Stripe-Größe von 128 KB habe und die Partition nicht mit einem Vielfachen von 128 KB ab 'Block 0' startet, kann ich logische Lesevorgänge durchführen, die auf zwei physische Zuordnungseinheiten aufgeteilt sind, was zwei Lesevorgänge erfordert und a verursacht Leistungsstrafe.
ConcernedOfTunbridgeWells
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.