Blockgrößen verstehen

Question

Meine Frage zielt auf Postgres ab, aber Antworten sind möglicherweise gut genug aus einem Datenbankhintergrund.

Sind meine Annahmen korrekt:

• Festplatten haben eine feste Blockgröße?
• RAID -Controller kann eine unterschiedliche Blockgröße haben? Wird ein RAID -Block auf mehrere echte Festplattenblöcke aufgeteilt?
• Das Dateisystem hat auch eine unabhängige Blockgröße, die wieder auf die RAID -Blockgröße aufgeteilt wird?
• Postgres funktioniert mit festen 8K -Blöcken. Wie erfolgt hier die Zuordnung zur Dateisystemblockgröße? Werden Postgres 8K -Blöcke vom Dateisystem zusammengefügt?

Ist es am besten, wenn Sie bei der Einrichtung eines Systems alle Blöcke bei 8K haben? Oder sind die Einstellungen nicht echt? Ich habe mich auch gefragt, ob einige "falsche" Blockgrößeneinstellungen bei einem Absturz die Datenintegrität gefährden könnten? Vielleicht, wenn ein Postgres 8K -Block auf mehrere Festplattenblöcke aufgeteilt werden muss?

Oder

Answer 1

Scheibensektoren

Eine Festplatte hat eine feste Sektorgröße, normalerweise 512 Bytes oder 4096 Bytes auf einigen modernen Scheiben; Diese Festplatten haben auch einen Modus, in dem sie 512 Bytesektoren emulieren. Die Festplatte wird Spuren mit unterschiedlicher Sektoren haben. Tracks näher an der Außenseite der Festplatte haben mehr Sektoren, da sie mehr Platz für eine bestimmte Dichte haben. Dies ermöglicht eine effizientere Nutzung des Festplattenraums. In der Regel hat eine Spur auf einer modernen Festplatte etwa 1.000 512 Bytesektoren.

Einige Formatierungsstrukturen können auch Fehler bei der Korrektur von Informationen in den Secotrs enthalten, die sich in den Scheiben manifestieren, die mit 520 oder 528 Byte-Sektoren niedrig gestaltet sind. In diesem Fall hat der Sektor noch 512 Bytes Benutzerdaten. Weder Windows noch Linux unterstützen dies direkt, obwohl i5OS (IBM ISERIES) und verschiedene SAN -Controller dies tun.

Normalerweise wird der Sektor/der Kopf/die Spur in eine logische Blockadresse übersetzt. Aufgrund historischer Probleme mit Rückwärtskompatibilität hat die Geometrie (Heads X -Sektoren X Tracks), die vom Betriebssystem (insbesondere auf IDE- und SATA -Scheiben) normalerweise mit seiner physischen Struktur zu tun haben.

RAID -Streifengröße

Ein RAID-Controller kann eine Streifengröße für ein Array mit Striping (z. B. RAID-5 oder RAID-10) haben. Wenn das Array (für Exmaple) einen 128K -Streifen hat, verfügt jede Festplatte über 128.000 zusammenhängende Daten, und der nächste Datensatz befindet sich auf der nächsten Festplatte. Normalerweise können Sie erwarten, dass Sie ungefähr einen Streifen pro Revolution der Festplatte erhalten, sodass die Streifengröße die Leistung bei bestimmten Workloads beeinflussen kann.

Partitionsausrichtung

Eine Festplattenpartition kann genau mit einem RAID -Streifen übereinstimmen oder nicht und kann aufgrund von Split -Lesevorgängen die Leistungsverschlechterung verursachen, wenn sie nicht ausgerichtet ist. Einige Systeme (z. B. Windows 2008 Server) konfigurieren automatisch Partitionen so, dass sie an den Größen der Festplattenvolumenstreifen ausgerichtet sind. Einige (z. B. Windows 2003 Server), und Sie müssen ein Partitionsdienstprogramm verwenden, das die Streifenausrichtung unterstützt, um sicherzustellen, dass sie dies tun.

Dateisystemblockgröße

Das Dateisystem bereitstellt Speicherblöcke in Stücken einer bestimmten Größe. 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 zu einem einzigen Dateisystemblock gelesen werden, um mehrere Datenträgerzugriffe zu generieren, bei denen nur eine erforderlich wäre, wenn die Dateisystemblöcke korrekt mit den RAID -Streifen ausgerichtet sind.

Datenbankblockgröße

Die Datenbank verteilt Platz in einer Tabelle oder einem Index in einer bestimmten Blockgröße. Im Fall von SQL Server ist dies 8K und 8K ist der Standard für viele Systeme. Auf einigen Systemen wie Oracle ist dies konfigurierbar und bei PostgreSQL ist es eine Build-Time-Option. Bei den meisten Systemen zur Zuordnung von Systemen zu Tabellen wird normalerweise in größeren Stücken durchgeführt, wobei Blöcke in diesen Stücken zugewiesen werden.

Durch eine Fehlausrichtung von Dateisystem- und Datenzuweisungsblöcken können mehrere I/A für einen einzelnen Block geschrieben werden, was eine Leistungsstrafe vorantreibt.

E/A -Chunking

Normalerweise wird ein DBMS tatsächlich seine E/A in Stücken von mehr als einem Block machen. Auf SQL Server wird beispielsweise alle E/A in Stücken von 8 Blöcken, insgesamt 64.000, durchgeführt. Auf Oracle ist dies konfigurierbar. Die gelegentliche Inspektion der PostgreSQL -Dokumente zeigt keine spezifische Beschreibung, ob PostgreSQL dies tut. Ich bin mir also nicht sicher, wie es auf dieser Plattform funktioniert.

Wenn der E/A -Chunk größer als die Blockgröße des Dateisystems ist oder mit RAID -Streifengrenzen falsch ausgerichtet ist, kann eine Festplatte aus der DB mehrere Schreibvorgänge verursachen, was eine Leistungsstrafe erzeugt.

Speicherplatznutzung

Es wird kein Speicherplatz verschwendet - die Datenbank -E/A verwendet einen oder mehrere physische E/A -Operationen auf der Festplatte, um abgeschlossen zu werden - aber fälschlicherweise abgestimmtes I/A kann Ineffizienzen generieren, die die Datenbank verlangsamen. Die wichtigsten Dinge, die in Ausrichtung sein müssen, sind:

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

• Dateisystem -I/A -Allokation und RAID -Streifen-/Partitionsgrenzen - Eine RAID -Streifengrenze muss sich mit einer Dateisystemzuweisungeinheit ausrichten und sollte ein Vielfaches der Größe der Dateisystem -Zuordnungseinheit sein.

• Festplattenschreibgröße und Dateisystem -Zuordnungseinheit Größe. Es sollte eine 1: 1 -Beziehung zwischen Datenbank -E/A -Operationen und I/A -Operationen des Dateisystems bestehen.

Eine Fehlausrichtung erzeugt kein größeres Problem der Datenintegrität als sonst vorhanden wäre. Das Datenbank- und Dateisystem verfügt über Mechanismen, um sicherzustellen, dass die Opearationen des Dateisystems atomar sind. Im Allgemeinen führt ein Festplattencrash zu Datenverlust, aber nicht zu Problemen mit der Datenintegrität.