Mittwoch, 31. August 2011

Technische Unterschiede PostgreSQL, MySQL, MariaDB - Teil 3

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
Begriffe

Bevor ich auf die technischen Unterschiede eingehe, möchte ich ein paar Worte über Bezeichnungen und Begriffe verlieren, die immer wieder zu Verwirrungen führen oder falsch verwendet werden.

Mehrzahl

In der Datenbanktechnik ist die Mehrzahl von Schema Schemas und die Mehrzahl von Index Indexe. Wer Schemata oder Indizes sagt, wird, vorallem im ehrenamtlichen Community Support sehr schnell aus Dau eingestuft. Das gilt sowohl für die englische als auch die deutsche Sprache. Leider trifft man auch immer wieder auf Lektoren, die es falsch korrigieren.


SQL

SQL wird Es-Kuh-El ausgesprochen. Es heisst Mei-es-kuh-el und es heisst Postgres-kuh-el. Wer hier Siequell sagt, dem wird automatisch Ahnungslosigkeit
unterstellt.

Es ist durchaus legitim PostgreSQL mit Postgres oder PG abzukürzen. Allerdings
sind Postgre nur sieben aneinandergereihte Buchstaben ohne jede Bedeutung. Hier gilt dasselbe wie für Siequell - wer Postgre sagt, zeigt automatisch damit an, dass er keine Ahnung hat.

MySQL kommt ursprünglich aus Finland / Schweden. Der richtig ausgesprochene Name ist, wie oben erwähnt Mei-es-kuh-el. Hier ist vorallem die europäische Community ziemlich angenervt von Leuten, die es falsch aussprechen, so dass, wer Meisiequell sagt, risikiert, dass er gar nicht mehr für voll genommen wird.


Cluster

Der normale ITler versteht unter einem Cluster ein veteiltes System mit
mehreren Nodes. So auch die PostgreSQL- und die MySQL-Welt.

Aber - sowohl PostgreSQL als auch MySQL verwenden das Wort Cluster gerne noch in anderen Zusammenhängen.

Neben dem klassischen MySQL bietet MySQL noch das Produkt mit Namen MySQL Cluster an. MySQL Cluster ist ein völlig eigenständiges Produkt. MySQL Cluster wird gerne in die Gruppe der NoSQL-Datenbanken gesteckt und hat eine eigene, völlig andere Zielgruppe.

PostgreSQL ist Meister im Verwirrung stiften, wenn es um das Wörtchen Cluster geht. PostgreSQLer sprechen auch von einem Cluster, wenn sie eine initialisierte Umgebung meinen. MySQL spricht hier von Instanz.

Den Begriff Instanz kennen die meisten Postgresler hier zusätzlich. Es ist ratsam, wenn ein Postgresler von Cluster spricht, nachzuhaken, ob er Cluster im Sinne von mehreren Nodes oder Cluster im Sinne von Instanz meint.

Daneben kennt PostgreSQL noch einen SQL-Befehl der CLUSTER heißt. Also immer nachhaken, was gemeint ist, wenn Postgresler das Wörtchen Cluster benutzen.

Schema

Ein weiteres Wort, was in vielen Lebenslagen benutzt wird, ist das Wort Schema.

Schema ist zum einen ein Datenbankobjekt, wie wir im nächsten Bericht sehen werden. Aber auch die Zeichnung, das Modell einer Datenbank, wird gerne als Schema bezeichnet.

Daneben spricht PostgreSQL gerne von Schemadump und Datendump.

Der Begriff Datendump ist auch bei MySQL geläufig. Ein Dump, der nur die Datensätze enthält.

Schemadumps sind in MySQL durchaus üblich, nur ist der Begriff weniger bekannt. Das kürzeste, was man hierfür in der MySQL-Welt findet ist Create-Only-Dump. Meistens jedoch, sieht man, dass der Begriff umständlich umschrieben wird.

Ein Schemadump ist nichts anderes, als ein Dump der reinen Datenbank- bzw. Schemabeschreibung. Alles, was an Objekten in der Datenbank bzw. dem Schema angelegt worden ist. Alle CREATE Statements. Von Tabellen bis hin zu Routinen, Triggern und Indexen. Man könnte auch sagen, ein Dump von allem außer den Daten selbst.

Fortsetzung folgt ....

Dienstag, 30. August 2011

Technische Unterschiede PostgreSQL, MySQL, MariaDB - Teil 2

Teil 1 dieser Artikelserie ist hier:
http://miraspostgresqlwelt.blogspot.com/2011/08/technische-unterschiede-postgresql.html

MySQL und MariaDB

Zuerst möchte ich ein paar Worte zu MySQL und MariaDB verlieren.

MySQL hatte das große Pech, zweimal innerhalb von kürzester Zeit verkauft zu werden. Zuerst an Sun und danach hat Oracle Sun gekauft. Heute besitzt somit Oracle das Copyright für MySQL.

Monty Widenius war der Urentwickler von MySQL.

MariaDB ist ein Fork von MySQL, der vor dem Verkauf von Sun an Oracle von Monty gezogen wurde. Viele der Entwickler, die ursprünglich am MySQL Server selbst mitgewirkt haben, haben Sun bzw. Oracle verlassen und die meisten dieser Entwickler arbeitet heute im Monty- / MariaDB-Umfeld. Zum Glück sind nur wenige, wie ich selbst, abtrünnig geworden und arbeiten heute ganz woanders.

Zu dem Monty-/MariaDB-Umfeld gehören Dienstleistungsfirmen wie SkySQL (Finland), FromDual (Schweiz) und Percona (Amerika). Jede mit eigenen, individuellen Schwerpunkten. Ich nenne diesen Zusammenschluss auch gerne die Monty-Wolke.

MariaDB hat sich mitlerweile unabhängig und gut weiterentwickelt.

Natürlich ist vieles in MySQL und MariaDB gleich. Aber auch einiges bereits unterschiedlich. Sofern es notwendig ist, werde ich beide getrennt behandeln. An den Stellen, wo es keine Unterschiede gibt, werde ich sie unter einem Namen zusammenfassen. Wenn nicht beide explizit erwähnt werden, sondern nur einer, gilt die Aussage für beide.

Für mich persönlich ist MariaDB das eigentliche MySQL, da für mich ein Produkt
nicht nur aus dem Produktnamen sondern auch aus den Leuten, die dahinterstehen, besteht.

Storage Engines MySQL und MariaDB

Was wird zum Vergleich herangezogen?

MyISAM ist eine Storage Engine - die eine völlig andere Zielgruppe hat als PostgreSQL. MyISAM ist transaktionslos und kümmert sich mit Absicht nicht unbedingt um Eingabekontrolle. MyISAM ist nicht ACID-konform.

ARIA ist eine Neuentwicklung in MariaDB. Der Unterschied zu MyISAM ist, dass ARIA zumindestens jetzt schon Durable (das D aus ACID, crashsicher) ist.

InnoDB ist ACID-konform und unterstützt MVCC.

XtraDB ist ein InnoDB-Fork der Firma Percona, der stetig individuell und unabhängig von Percona weiterentwickelt wird. Percona hat hier zusätzlich grundlegende Patche, die von Google und Facebook zur Verfügung gestellt wurden, eingearbeitet.

XtraDB ist in MariaDB implementiert.

MyISAM und ARIA haben eine völlig andere Zielgruppe als PostgreSQL, InnoDB und XtraDB.

Auch PostgreSQL verfügt über einige Zusatzfeatures, mit denen andere Zielgruppen angesprochen werden.

Der Artikel beschränkt sich hier auf den Anwendungsbereich, in dem die Zielgruppe identisch ist. Es wird nur MySQL und MariaDB mit Einsatz von InnoDB bzw. XtraDB berücksichtigt.

InnoDB und XtraDB haben viele Gemeinsamkeiten. Auch hier werde ich nur von einem sprechen, solange es keine Unterschiede gibt. Auch hier gilt, wird nur einer erwähnt, gilt die Aussage für beide.

Fortsetzung folgt ...

Montag, 29. August 2011

Technische Unterschiede PostgreSQL, MySQL, MariaDB - Teil 1

Vorwort

In dieser Woche möchte ich mich mit den Unterschieden von PostgreSQL, MySQL und MariaDB befassen. Es ist in keiner Weise in dieser Artikelserie meine Absicht, den einen oder anderen schlecht zu machen. Sondern möchte ich Euch sachlich und neutral die technischen Unterschiede sowie die zu bedenkenden Unterschiede in der Anwendung aufzeigen.

Ein weiterer Hintergrund für diese Artikelserie ist, dass ich immer wieder Vorträge und Artikel zu diesem Thema lese, bei denen sich mir alle Nackenhaare sträuben, weil der Autor bzw. Vortragende sich hier dann doch nur in einem System wirklich auskennt und teilweise hanebüchene Dinge über das jeweils andere System erzählt werden.

Es gibt weltweit nur zwei Experten für beide Systeme. Zwei, die seit Jahren am PostgreSQL-Projekt mitwirken und die hauptberuflich jahrelang als Entwickler und Supporter für MySQL gearbeitet haben. Zwei, die beide Systeme gleich gut - bis in die Tiefen - kennen. Der eine ist Amerikaner und arbeitet heute für Facebook; die andere bin ich selbst.

Ich denke es ist notwendig, hier mein Wissen zu teilen und einen sachlich richtigen Artikeln zu verfassen, um den ganzen hanebüchenen Unsinn, der sich an jeder Ecke findet, Herr zu werden.

Da das Thema recht umfangreich ist, werde ich es häppchenweise hochladen. Ich werde versuchen, mich von oben nach unten durch das Thema durchzuhangeln. Heisst ich fange auf der Entwicklungsebene an und Performance-Tuning auf Betriebssystem- und Hardwareebene wird am Ende sein.

Fortsetzung folgt ...

Montag, 22. August 2011

Was hat NoSQL mit Kalbsleberwurst gemeinsam?

Seit einigen Jahren gibt es in der IT einen neuen Begriff: NoSQL. Übersetzen würde ich es mit kein-SQL oder Nicht-SQL. SQL ist eine Programmiersprache zur Beschreibung von relationalen Datenbanken.

Jetzt könnte angenommen werden, da SQL eine Programmiersprache ist, handelt es sich bei NoSQL um alle anderen Programmiersprachen. Wäre ja naheliegend. Genauso naheliegend, wie die Annahme, dass Kalbsleberwurst aus Kalbsleber besteht. Aber beides ist ein Trugschluss.

Liest man die Beschreibungen durch, erfährt man:
NoSQL soll quasi der Oberbegriff für alle Datenbankkonzepte in der IT, die nicht SQL zur Beschreibung nutzen. Relational oder nicht ist dabei egal.

Datenbankkonzepte ohne SQL. Wie war das noch - da gibt es doch seit Jahren mehr als das relationale Konzept - es gibt hierarchische Datenbankkonzepte (Implementierte Beispiele sind Dateisysteme und LDAP) und es gibt objektorientierte Datenbankansätze (OODB).

Und die meisten relationalen Systemen benutzten, bevor sie SQL implementierten auch etwas anderes. Postgres hat POSTQUEL benutzt und bekam durch die Hochzeit mit SQL lediglich einen neuen Namen Postgres95, der sich dann nur wenig später durch die Hochzeit mit OpenSource nochmals in PostgreSQL änderte.

Daraus folgt offensichtlich - dass Postgres NoSQL war.

Mit dem Begriff NoSQL ist also vorsicht geboten. Nicht nur moderne System wie MongoDB, CouchDB, GraphDB und MySQL Cluster sind NoSQL. Sondern auch alte Systeme wie Ext, XFS, UFS, FAT und LDAP. Und Postgres war durchaus nicht das einzige SQL System, das als NoSQL angefangen hat.