Freitag, 16. September 2011

Technische Unterschiede PostgreSQL, MySQL, MariaDB - Teil 7

Die vorangegangenen Teile dieser Artikelserie sind hier:
  1. http://miraspostgresqlwelt.blogspot.com/2011/08/technische-unterschiede-postgresql.html 
  2. http://miraspostgresqlwelt.blogspot.com/2011/08/technische-unterschiede-postgresql_30.html
  3. http://miraspostgresqlwelt.blogspot.com/2011/08/technische-unterschiede-postgresql_31.html
  4. http://miraspostgresqlwelt.blogspot.com/2011/09/technische-unterschiede-postgresql.html
  5. http://miraspostgresqlwelt.blogspot.com/2011/09/technische-unterschiede-postgresql_02.html
  6. http://miraspostgresqlwelt.blogspot.com/2011/09/technische-unterschiede-postgresql_06.html 
Wie ist das jetzt genau mit den Transaktionen und dem Redo?

Aufgrund vieler Nachfragen zu genau diesem Thema, werde ich es vorziehen und schon heute darauf tiefer eingehen.

Wie bereits erwähnt loggen sowohl PostgreSQL als auch InnoDB abgeschlossene Transaktionen. Ebenfalls bereits erwähnt hatte ich, dass bei PostgreSQL die Blöcke in der Regel 8 kB groß sind und bei InnoDB 16 kB.

Checkpoints sorgen bei beiden dafür, dass die Änderungen permanent gespeichert werden.

Geänderte Blöcke zwischen zwei Checkpoints werden dirty pages genannt.

InnoDB überträgt nur die geänderten Bereiche eines geänderten Blocks in das Log.

Wird bei PostgreSQL nach einem Checkpoint zum ersten Mal ein Block geändert, dann schreibt PostgreSQL den gesamten Block ins Redo-Log.

Wird ein Block dann nochmal geändert, bevor der nächste Checkpoint passiert, dann wird bei PostgreSQL, genau wie InnoDB nur die Änderung festgehalten.

Bei einem Checkpoint schreiben beide die dirty pages auf die Platte.

InnoDB schreibt dabei die dirty pages zweimal auf die Platte. Zuerst einmal in den Double Write Buffer und danach an die eigentliche Position. Auf diese Weise hat InnoDB eine Kopie der Page, die es zur Rekonstruktion verwenden kann, falls der Server während des Schreibens an die eigentliche Position crashed (z.B. bei einem Stormausfall).

PostgreSQL hat keinen Double Write Buffer. Es schreibt die dirty pages direkt an die eigentliche Position. Da PostgreSQL bei der ersten Änderung nach einem Checkpoint die Page komplett ins Redo-Log geschrieben hat, hat es hier eine Kopie der Page, auf die es zurückgreifen kann, wenn beim Schreiben der Strom ausgefallen ist. Zur Rekonstruktion angelt sich PostgreSQL die Page aus dem Redo und patched die weiteren Änderungen, die weiter hinten im Redo-Log stehen, einfach in die Page hinein.

Das speichern der gesamten Page im Redo ersetzt bei PostgreSQL den Double Write Buffer von InnoDB.

Je weniger Checkpoints umso mehr einzelne geänderte Zeilen stehen im Redo und umso länger dauert somit die Rekonstruktion. Bei PostgreSQL lassen sich die Checkpoints konfigurieren. InnoDB nutzt andere Algorithmen hier und die Konfiguration der Checkpoints ist nicht so ohne weiteres möglich.

Fortsetzung folgt ....

Keine Kommentare:

Kommentar veröffentlichen