Start frei

Mit Falcon steht nun die dritte transaktionsfähige Storage Engine (neben DBD und InnoDB) für MySQL bereit. Entwickelt wurde dieser Tabellentyp vom bekannten Datenbankarchitekten Jim Starkey, der unter anderem das Datenbankmanagement System InterBase entwickelt und an der Open Source Datenbank Firebird mitgearbeitet hat.

Folgende Hauptziele wurden bei der Entwicklung der Falcon Engine verfolgt:

1. Eine einfache Verwaltung der Storage Engine (Zitat: "People have more important things to do than tune databases.")
2. Eine optimale Performance

Auf den zweiten Punkt von Mr. Starkey's Zielsetzung werden wir aus Platzgründen in diesem Artikel nicht näher eingehen. Für Interessierte ist aber sicher Verweis [1] aufschlussreich. In dem Artikel "InnoDB vs MyISAM vs Falcon benchmarks - part 1" werden die Vor- und Nachteile der Storage Engine MyISAM, InnoDB und Falcon aus Performance-Sicht umfangreich erörtert.

Tablespaces

Im Gegensatz zu vielen anderen Storage Engines verwaltet Falcon seine Objekte, wie z. B. Tabellen, über eine zusätzliche, logische Ebene: die Tablespaces (ähnlich wie bei Oracle).

Derzeit wird nur eine Datenbankdatei pro Tablespace unterstützt, allerdings wurde bereits eine Erweiterung auf mehrere Dateien angekündigt. Derweil mag es trösten, dass die Größe einer Datei auf 110 TB limitiert ist und damit in der Regel ausreichend Platz für Objekte jeglicher Art bieten sollte.

Physikalischer Platz wird im Übrigen über Pages (Blöcke) allokiert. Ähnlich wie bei Oracle kann die Größe einer Page bei der Initialisierung der Engine definiert werden (Default 4 KB). Eine spätere Änderung ist leider ohne Weiteres nicht möglich. Dies ist bei MySQL eine absolute Neuerung, da alle anderen Engines bislang mit festen Werten (zumindest nach der Kompilierung der MySQL Binaries) gearbeitet haben.

mysql> create tablespace testdaten -> add datafile 'testdata.fts' -> engine falcon; Query OK, 0 rows affected (1.78 sec) mysql> create table test_tabelle -> ( a int, b varchar(20), c date ) -> engine=falcon tablespace testdaten; Query OK, 0 rows affected (0.08 sec) Abb. 1: Tablespaces im Einsatz. Bei der Erstellung eines Tablespaces wird für die Datendatei keine Größe spezifiziert. Die Datei wächst dynamisch.

Abb. 2: Der MySQL Record Cache. vergrößern

+----------------------------------------+ | Tables_in_information_schema (FALCON%) | +----------------------------------------+ | FALCON_TABLES | | FALCON_SYSTEM_MEMORY_DETAIL | | FALCON_SYSTEM_MEMORY_SUMMARY | | FALCON_SERIAL_LOG_INFO | | FALCON_RECORD_CACHE_DETAIL | | FALCON_TRANSACTION_SUMMARY | | FALCON_DATABASE_IO | | FALCON_SYNCOBJECTS | | FALCON_TRANSACTIONS | | FALCON_RECORD_CACHE_SUMMARY | +----------------------------------------+ Abb. 3: Die Storage Engine Falcon wurde in die Metadatenbank "information_schema" integriert. Allerdings fehlen an einigen Stellen noch wichtige Informationen.

Datafiles

Ebenfalls wichtig zu wissen ist, dass bei der Erzeugung eines Tablespaces (und damit eines Datafiles) keinerlei Einfluss auf die initiale und maximale Größe der Dateien genommen werden kann (siehe Abbildung 1). Zu Beginn belegt ein Datafile in aller Regel 16 KB (4 Blöcke à 4 KB Default-Blockgröße). Mit zunehmendem Platzbedarf wächst das Datafile an.

Es mag für die Nutzer anderer Datenbanksysteme verwirrend sein, dass bei Falcon Tablespaces ähnlich wie bei der Storage Engine InnoDB von mehreren Datenbanken eines MySQL Servers genutzt werden können. Dieses Verhalten ist zwar recht praktisch, da vom Datenbankadministrator keine manuellen Eingriffe, z. B. zur Vergrößerung eines Tablespaces oder Datafiles, notwendig sind, jedoch erschweren Sie das Monitoring der Datenbank und ihres Wachstumsverhaltens.

Aktuell sind leider noch keine Systemsichten zur Analyse der Tablespaces oder Datafiles vorhanden. Zur Überwachung einer Tablespace-Größe ist aktuell also ein Blick ins Dateisystem notwendig.

Speichernutzung

MySQL war bislang für eine sehr zurückhaltende Speichernutzung bekannt. Zumindest wurde immer propagiert, dass MySQL Engines mit sehr wenig Speicher auskommen. Jim Starkey will mit dieser Tradition teilweise brechen. Im Rahmen der Präsentation von Falcon auf der MySQL UC (MySQL User Conference [2]) erläuterte er, dass sich die Speichergrößen und Zugriffsgeschwindigkeiten von RAM seiner Meinung nach in den letzten Jahren enorm entwickelt haben, während die Zugriffszeiten von Plattensystemen im Vergleich dazu kaum Fortschritte machten. Zwei seiner Kernaussagen lauteten daher:

• CPUs and memory are faster
• Exploit large memory for more than just a bigger cache

Die Aussagen sind im Prinzip nachvollziehbar. Allerdings findet man im produktiven Einsatz selten MySQL-Server, die mehr als 1 GB Speicher nutzen. In der Regel sind die betriebenen Datenbanken so klein, dass Hauptspeicherprobleme recht selten sind.

Row Cache

Natürlich kann in diesem Artikel nicht umfassend auf die unterschiedlichen Hauptspeicherbereiche und deren Nutzung eingegangen werden, allerdings sollen die Besonderheiten der Engine an dieser Stelle hervorgehoben werden.

Wie jede andere Engine besitzt Falcon natürlich auch einen Page Cache, in dem die benötigten Seiten von der Platte in den Speicher zur weiteren Verarbeitung gelesen werden. Der Nachteil beim Lesen von Seiten besteht darin, dass in der Regel auch immer Daten in den Seiten enthalten sind, die vom Anwender nicht benötigt werden (siehe Abbildung 2).

Aus diesem Grund wurde neben dem Page (Seiten) Cache auch ein Record Cache implementiert. In diesem Cache werden nur die Datensätze gehalten, die auch wirklich in Verwendung sind.

Ein kleines Rechenbeispiel:

Sie benötigen 100 Datensätze á 20 Byte. Leider befinden sich diese jeweils in einer einzelnen 8 KB großen Seite. Der Page Cache benötigt 100 * 8 KB = 800 KB. Da im Record Cache nur die benötigen Datensätze gespeichert werden, benötigt man dort weniger als 2 KB (100 * 20 Byte = 1,95 KB). Der Record Cache ist mit einem Default von 20 MB um den Faktor fünf größer als der Page Cache (4 MB).

Monitoring

Das Monitoring von Falcon-Objekten wurde durch die Einbindung in die MySQL-Metadatenbank "information_schema" realisiert. Insgesamt stehen derzeit 10 Tabellen (Views) zur Überwachung der Engine zur Verfügung (siehe Abbildung 3).

In der momentan zur Verfügung stehenden Version gibt es aber leider keinen Weg, die physikalische Speicherauslastung von Tablespaces zu monitoren (siehe Abschnitt Datafiles). Für das GA (General Availability) Release wurde aber zugesagt, dieses Manko abzustellen. Vermutlich wird es dann eine weitere View für Tablespaces im "information_schema" geben.

Einschränkungen

Besonders negativ stößt zurzeit die Tatsache auf, dass Falcon noch keine Foreign-Key-Beziehungen (referentielle Integrität) unterstützt. In einigen Foren findet man jedoch bereits die "inoffizielle" Ankündigung dieser Funktion für die Version 6.1. Zusätzlich fehlen noch Konfigurationsmöglichkeiten für Tablespaces und Datafiles.

Es wäre auf jeden Fall wünschenswert, wenn man die initiale und maximale Größe von Datafiles optional festlegen könnte. Darüber hinaus sollte die versprochene Mehrdateiunterstützung eines Tablespaces möglichst bald implementiert werden. Auch der Informationsgehalt in der Metadatenbank "information_schema" sollte, wie angekündigt, noch ausgebaut werden.

Fazit

Die neue Storage Engine Falcon bietet viele neue und interessante Ansätze, die so in noch keiner anderen MySQL Storage Engine zu finden waren.

Allerdings gibt es in vielen Bereichen noch deutliche Einschränkungen bzw. Unschönheiten, die die Freude ein wenig dämpfen. Man sollte im Hinblick auf das Alter der Engine daran denken, dass es sich um ein recht junges Storage Plugin mit viel Entwicklungspotential handelt.

Ein Blick auf die aktuelle Entwicklungsplanung gibt Hoffnung, dass dieses Potential demnächst auch tatsächlich genutzt wird. Aus diesem Grund dürfte es sich lohnen, die Entwicklung von Falcon aufmerksam zu beobachten. Nicht zuletzt wird diese Hoffnung durch die Übernahme der Firma MySQL AB durch Sun genährt.

Wir halten Sie natürlich über die weitere Entwicklung von MySQL und der Storage Engine Falcon auf dem Laufenden.