Ankündigung

Einklappen
Keine Ankündigung bisher.

16: Store it!

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • 16: Store it!

    16:
    Nicht selten herrscht Verwirrung darüber, welche der vielen Storage-Engines, die MySQL bietet, denn nun die beste ist und oftmals ist es dem angehenden Programmierer noch nicht einmal bekannt, dass MySQL hier überhaupt Unterschiede macht.
    Im Normalfall ist gerade noch bekannt, dass InnoDB Foreign-Key-Relations, also Fremdschlüsselbeziehungen, nativ unterstützt. Doch Wissen, das darüber hinausgeht, ist selten anzutreffen und oft den eingefleischten Datenbankgeeks vorbehalten. Doch das muss nicht sein. Sicherlich darf sich jeder, der eine Datenbankengine wie MySQL bis ins letzte Detail durchdrungen hat, als absoluter Profi bezeichnen, da hinter dem trivial scheinenden Gebilde weit mehr steckt als bloß ein bisschen Datenverwaltung, doch geht es darum gar nicht. Ein grundlegendes Wissen über Storage-Engines (auch Tabellentypen genannt) sollte jedem Programmier zugänglich und verständlich sein. Wenn man auch die internen Abläufe nicht versteht und auch nicht zwangsläufig verstehen muss, so lässt sich doch zumindest anhand einiger Tatsachen und Regeln feststellen, welche Storage-Engine sich für welchen Einsatzzweck eignet.

    Zunächst sollte aber noch erwähnt werden, dass man sich nicht unbedingt auf einen einzigen Tabellentyp festlegen muss, da sich (wie der Name schon sagt) in einer Datenbank auch mehrere Tabellentypen/Storage-Engines verwenden lassen.
    Doch nun zur Auswahl der Storage-Engine. Um hier eine Aussage treffen zu können, ist es wichtig, die signifikanten Unterschiede zu kennen.
    Als erstes wäre da die MySQL-Standard-Engine MyISAM. Sofern nicht anders angegeben, erhalten Tabellen stets diesen Typ, was sich auf lange Zeit auch bewährt hat, auch wenn es ehemals als der Hinkefuß von MySQL angesehen wurde. MyISAM ist an sich eine Storage-Engine mit vergleichsweise wenigen Features, aber eben dies macht sie so flexibel und schnell. Insbesondere in Hinsicht auf auf das Locking, also das Sperren von Datensätzen bei Schreib- und Lesevorgängen zur Vermeidung von Datenintegritätsproblemen bei konkurrierenden Querys, hat MyISAM wenig zu bieten. Erfolgt ein Zugriff, sperrt MyISAM währenddessen die gesamte Tabelle, was eine sehr geringe Parallelität ergibt.
    Es ist allerdings zu unterscheiden zwischen Schreib- und Leselocks bzw. zwischen Exclusive Locks und Shared Locks. Bei Lesezugriffen wird ein Shared Lock angewendet, d.h. es sind in der Zeit keine Schreibzugriffe möglich, das Lesen das Datensatzes ist allerdings weiterhin möglich. Bei Schreibzugriffen wird ein Exclusive Lock angewendet, d.h. dass in der Zeit keine weiteren Zugriffe erlaubt sind, ob schreibend oder lesend. Es ist offensichtlich, dass Exclusive Locks bei tabellenbasiertem Locking sehr verschwenderisch sind, allerdings generiert diese Art des Lockings nur einen geringen Overhead und genau an dieser Stelle macht MyISAM aus der Not eine Tugend und präsentiert seine eigentliche Stärke: hohe Performance bei Lesezugriffen. MyISAM ist dazu konzipiert, hauptsächlich (optimal: ca. 90%) Lesezugriffe zu bedienen und das ist auch allermeist der Fall. Vor allem bei Blogs und i.d.R. auch bei Wikis u.ä. Anwendungen bestehen die meisten Zugriffe aus reinen Leseoperationen. Hier bietet sich also vornehmlich MyISAM an. Auch wenn oft die Anzahl vorhandener Datensätze mittels SELECT COUNT(*) benötigt wird, ist MyISAM zu empfehlen, da diese der Storage-Engine stets ohne Nachzählen bekannt ist.

    Eine weitere sehr prominente Storage-Engine ist InnoDB, welche von Innobase Oy bereitgestellt wird (Ironie des Schicksals: Innobase Oy wurde mittlerweile vom Softwareriesen und größten Konkurrenten Oracle übernommen). InnoDB behebt die meisten Defizite von MyISAM, wartet dafür aber auch mit einem deutlich größeren Overhead auf und sollte daher mit Bedacht eingesetzt werden. Insbesondere beim Ermitteln der Anzahl der Datensätze schwächelt InnoDB, da hier tatsächlich jede Spalte einzeln gezählt werden muss.
    Aber verlassen wir das Gebiet, für das InnoDB nicht gebaut ist. Dessen Stärken liegen nämlich ganz woanders, nämlich bei hoher Parallelität (Concurrency) und Datensicherheit (Data Integrity). So unterstützt InnoDB neben strukturellen Dingen wie Fremdschlüsselbeziehungen auch Transaktionen, also Operationen aus mehreren Querys, die in einem Rutsch durchgeführt und bei einem Fehler auch wieder rückgängig gemacht werden können (Rollback). Dies ist besonders bei sensiblen Daten, bei deren Speicherung keine Fehler auftreten dürfen, wichtig.
    Durch ein zeilenbasiertes Locking gewährleistet InnoDB eine sehr hohe Parallelität. Es wird jeweils nur der zu schreibende Datensatz gesperrt, der Rest der Tabelle ist weiterhin frei für Lese- und Schreibzugriffe.
    Doch damit nicht genug: InnoDB bietet darüber hinaus noch Multi-Version Concurrency Control (MVCC), oder auch einfach gesagt: Versioning. Dieses Verfahren hier eingehend zu erklären, würde den Rahmen sprengen, es handelt sich grob gesagt aber um eine Versionierung der Datensätze, um eine höhere Parallelität zu erreichen. Dies bewirkt, dass für Leseoperationen nichts gesperrt werden muss, da nur mit Schnappschüssen gearbeitet wird und anhand der Versionierung die Datensicherheit gewährleistet werden kann. Dafür ergibt sich eine größere Datenmenge, da für jede Zeile zwei zusätzliche Werte gespeichert werden müssen, nämlich Identifikationsnummern zur Erstellung und zur Löschung sowie eine datenbankglobale System-Version, die mit jedem Query erhöht wird.
    InnoDB macht sich also sehr gut in Umgebungen, die auf Datensicherheit und Parallelität Wert legen, versagt hingegen kläglich, wenn es um performante Zugriffe geht. Entgegen langläufiger Meinung semiprofessioneller Datenbankingenieure ist InnoDB folglich nicht stets die bessere Wahl.

    Eine weitere weniger bekannte Storage-Engine, die sich eher am Rand der MySQL-Welt tummelt ist die Berkeley-DB (BDB), welche von Sleepycat entwickelt wurde. Wie irgendwie alles im Datenbankbereich wurde Sleepycat mittlerweile von Oracle übernommen.
    Da die Berkeley-DB-Storage-Engine in MySQL 5.1 entfernt wird, soll an dieser Stelle nur kurz auf diesen Datenbanktyp hingewiesen werden. Es handelt sich dabei praktisch um einen Kompromiss zwischen MyISAM und InnoDB. BDB bietet ebenfalls Transaktionen, ist bei der Locking-Granularität aber etwas großzügiger als InnoDB und lockt nicht einzelne Zeilen sondern sogenannte Pages von 8 kB Größe. Hierdurch wird eine höhere Performance erreicht, allerdings auch deutlich größere Parallelität als bei MyISAM.

    Wieder ein anderer Kandidat ist MEMORY (ehemals HEAP), eine Storage-Engine, die durch Schnelligkeit besticht, dafür aber nur für temporäre Tabellen geeignet ist. Wie der Name schon sagt, werden hier sämtliche Werte im Speicher gehalten. Lediglich die Tabellenstrukturen werden als .frm-Dateien auf der Festplatte hinterlegt. Die MEMORY-Engine ist wohl die schnellste von allen, dafür sind auch alle Daten weg, sobald der Server neugestartet wird. Es empfiehlt sich also nicht, Daten, die einer Persistenz bedürfen, der Geschwindigkeit wegen mit dieser Storage-Engine zu speichern und darauf zu setzen, dass der Server sowieso nicht neugestartet werden muss.

    Natürlich sind dies nicht alle Tabellentypen und es gibt sicherlich Hunderte Weiterer, doch sind dies die bekanntesten ihrer Art.
    An einer Stelle soll dieses Türchen aber auch anregen, über den Tellerrand hinauszuschauen. Wie wäre es, eine vollkommen neue Storage-Engine zu entwickeln, die aus dem gelernt hat, was InnoDB erfolgreich vorgemacht hat, und dies mit einer guten Performance sowie vielen anderen guten Eigenschaften zu kombinieren?
    Dank MySQLs Pluggable Storage Engine Architecture sind der Entwicklung von Storage-Engines praktisch keine Grenzen gesetzt und viele haben sich der Entwicklung an dieser Stelle angenommen. So auch PrimeBase mit der Storage-Engine PrimeBase XT (PBXT), welche erstaunliches Potential zeigt und in Zukunft vielleicht irgendwann in einer hohen Liga mitspielen wird. Wer weiß, was die Zukunft bringt?

    Ein kleiner Tippe noch zum Schluss: wer sich noch eingehender mit dem Thema Storage-Engines oder generell MySQL-Internals beschäftigen möchte, dem sei außer dem MySQL-Handbuch und viel googlen auch noch das Buch High Performance MySQL aus dem O'Reilly-Verlag empfohlen.

    Und so verbleibe ich mit diesem vergleichsweise langen aber dennoch kleinen Einblick in die Welt der Storage-Engines
    Euer Nikolaus


  • #2
    InnoDB kümmert sich tatsächlich um Fremdschlüsselbeziehungen? Werden auch die UPDATE-Anweisungen ausgeführt?
    Soweit erstmal wieder vielen Dank an unseren netten Nikolaus.

    Kommentar


    • #3
      MySQL :: MySQL 5.1 Reference Manual :: 1.7.5.4 Foreign Keys

      Kommentar


      • #4
        Jaja, hast ja recht, das hätte ich auch machen sollen.
        Dann habe ich ja mal wieder was zu tun

        Kommentar


        • #5
          ORM-Systeme wie Doctrine (denke Propel auch, weis ich aber nicht sicher) passen sich übrigends an die Storage-Engine an, wenn sie InnoDB erkennen, wird beim erzeugen der Tabellen die relation auch passend dazu erzeugt, wenn eine andere Storage-Engine benutzt wird, kümmert sich Doctrine selbst darum die Aufgaben die die in der konfiguration definierten Relationen gehabt hätten zu übernehmen.
          robo47.net - Blog, Codeschnipsel und mehr
          | Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

          Kommentar

          Lädt...
          X