November 2010 Archive

Moinsen hier sind die Vortragsunterlagen für den den MySQL-Plugin-Vortrag auf der DOAG.

Viel Spaß
Erkan

DOAG 2010

| Keine Kommentare | Keine TrackBacks
Zwar ist die DOAG noch im vollen Gange, aber zumindest der MySQL-Track ist seit gestern abgeschlossen. Ich war von der schieren Groesse der Konferenz beeindruckt und der MySQL-Raum der vielleicht 50 Leute fasste wirkte auf den erste Blick etwas verloren.
Oliver Sennhauser schaffte es mit seinem Vortrag "MySQL Architecturen fuer Oracle DBA's" den Raum zum Bersten zu bringen und legte den passenden Grundstein fuer Track. Der Vortrag von Konstatin Osipov fiel leider aus, so dass Lenz Grimmer in gewohnter souveraener Art Einsprang und ueber die Neuerungen von MySQL 5.5 zu Berichten wusste. (Ich freue mich drauf:). Ihm folgte Mathias Jung mit einer Einfuehrung in MySQL-Backupstrategien. Axiom seines Vortrages war die Unvereinbarkeit der verschiedenen StorageEngines welches ihn dazu fuehrte als einzig wahre Backupstrategie mysqldump und/oder einen Snapshot (beides auf einem Slave) anzubieten. (Hier mag man geteilter Meinung sein.)
Nach einer Pause sorgte Ronald Bradford mit seinem Vortrag "MySQL Idiosyncraises That Bites", bei vielen fuer grosse Augen indem er einen grossen Schwenk ueber Pitfalls beim Arbeiten mit MySQL machte. Abgeschlossen wurde der Tag mit meinem Vortrag .. naja.
Vom zweiten Tag weiss ich nicht viel zu Berichten, den Vortrag von Mario Beck verpasste ich schlicht und ergreifend, wurde aber mit dem Vortrag von Paul McCullagh ueber PBXT mehr als entschaedigt. Der technischste Vortrag erklaerte die Funktionsweise von PBXT und machte einen Ausblick auf weitere Entwicklungen wie einen 2. Level Cache fuer die Daten auf SSD und Replikation auf Engine-Level. Der Vortrag war so inspirierend, dass wir nicht nur die Mittagspause nutzten um weitere Features fuer PBXT durchzudiskutieren. Hier zeigte sich, dass das klare Design von PBXT vieles verdammt "einfach" zu implementieren macht \o/
Die restlichen Vortraege habe ich kaum verfolgen koennen.
Das Community-Treffen am Di Abend war sehr ueberschaubar und endete fuer einige mit einem netten Abendessen.
Alles in allem eine wohl gelungene Konferenz und definitiv ausbaufaehig. Da mir persoenlich zu teuer, hoffe ich naechstes Jahr wieder als Vortragender beiwohnen zu koennen und mehr Oragglers in Gespraeche zu verwickeln;)

Mit MariDB 5.2 - und seit kurzem 10. November (5.5.7-rc) auch mit MySQL - kommt das Pluggable Authentication Framework. Hiermit können weitere Loginmechanismen für MySQL implementiert werden. So kommt MariaDB mit - dem nicht aktivierten -  socket_peercred Plugin. Dieses ermöglicht den Usern sich via dem Unixaccount zu authentifizieren. Das Plugin schaut einfach nach, unter welcher UID der sich verbindende (mysql)-Prozess (via getsockopt) läuft. Dieser Username gilt als authentifiziert  Da ich hierzu keine Doku fand und ich schon am INSTALL scheiterte, ein schnelles Howto:

INSTALL PLUGIN socket_peercred SONAME 'auth_socket.so';

Ab sofort können User mit diesem PLUGIN authetifiziert werden. I.e.:

CREATE USER erkan  IDENTIFIED VIA socket_peercred;

Und nun nicht erschrecken, die Password-Spalte ist leer.

MariaDB [(none)]> select user,host,password from mysql.user where user='erkan';
+-------+------+----------+
| user  | host | password |
+-------+------+----------+
| erkan | %    |          |
+-------+------+----------+

Einloggt werden wird trotzalledem nicht:

mariatestbox:/# mysql -u erkan
ERROR 1045 (28000): Access denied for user 'erkan'@'localhost' (using password: NO)

Aber als UnixUser erkan (ja der erkan ist einer \o/)

mariatestbox:/# su - erkan
erkan@mariatestbox:~$ mysql -u erkan
Welcome to the MariaDB monitor.  Commands end with ; or \g.
[snip]
MariaDB [(none)]> \s
--------------
mysql  Ver 14.16 Distrib 5.2.2-MariaDB-gamma, for debian-linux-gnu (x86_64) using readline 5.1

Connection id:          37
Current database:
Current user:           erkan@localhost

Um einen Überblick zu behalten, welche User nun via welchem Plugin verwaltet werden, muss bei obigen SELECT nur eine weitere Spalte abgefragt werden:

select user,host,password,plugin from mysql.user where user='erkan';
+-------+------+----------+-----------------+
| user  | host | password | plugin          |
+-------+------+----------+-----------------+
| erkan | %    |          | socket_peercred |
+-------+------+----------+-----------------+

Viel Spaß


Theoretisch unterbaut vom Kleine-Welt-Phänomen und etwas Graphentheorie erquicken sich "Soziale" Netzwerke großer Beliebtheit. Mit Hilfe von Graphen können solche Strukturen aufgezeichnet und bearbeitet/analysiert werden. Selbstredend gibt es mit Neo4j auch eine NoSQL-Version mit der Graphen gebaut werden können.
Mit OQGraph existiert auch für MySQL ein Plugin, welches sich diesem Thema gewidmet hat. Der Einfachheit halber wurde zum Vorführen die MariaDB 5.2.2(gamma) verwendet. Diese hat den Vorteil, dass das SE-Plugin schon mitgeliefert wird und das Compilieren entfällt. (Auch wenn es noch via INSTALL PLUGIN oqgraph SONAME 'ha_oqgraph.so'; installiert/eingebunden werden muss.)
Doch vorab Graphentheorie light:
Ein Graph G(Vertex,Edge) besteht aus Knoten (V) und sie verbindende Kanten/Wege (E). Mit OQGraph hat man einen gerichteten Graph, sprich jede Kante/Weg hat eine Richtung. Auch Schlingen sind möglich, also Wege die ein und den selben Knoten als Anfangs- und Endpunkt haben. Kurzum jede Row welche in eine Tabelle (ENGINE=OQGRAPH) eingefügt wird entspricht einer Kante und definiert somit zwei Knoten (wenn es keine Schlinge ist:).
Doch erst mal einen Schritt zurück. Oben haben wir das Plugin geladen, als StorageEngine-Plugin haben wir nun die Möglichkeit Tabellen vom Engine-Typ OQGraph zu erstellen. Die Tabellenstruktur ist dabei vorgegeben und einzuhalten. Sonst gibt es eine Fehlermeldung:


MariaDB [graph]> create table failure (id int) engine=oqgraph;
ERROR 1005 (HY000): Can't create table 'graph.failure' (errno: 145)


Hier die vorgegebene Struktur


CREATE TABLE graph (
    latch   SMALLINT  UNSIGNED NULL,
    origid  BIGINT    UNSIGNED NULL,
    destid  BIGINT    UNSIGNED NULL,
    weight  DOUBLE    NULL,
    seq     BIGINT    UNSIGNED NULL,
    linkid  BIGINT    UNSIGNED NULL,
    KEY (latch, origid, destid) USING HASH,
    KEY (latch, destid, origid) USING HASH
  ) ENGINE=OQGRAPH;

Doch fangen wir einfach mal an. Beispiele nach WerKenntWen-Manier sind wohl etwas abgedroschen. Diese Technik kann auch für z. B. Routinganalyse genutzt werden. Für unser Beispiel nehmen wir uns Straßen zum Vorbild. Folgendes wollen wir abbilden:
stadt.png
stadt-bild
Wir haben 8 befahrene Straßen und eine davon in zwei Richtungen, dass ergibt 9 Rows/Kanten. (OQGraph kennt nur gerichtete Kanten.)  Zum Einfügen einer Kante (und damit der Definition der Knoten) reichen die spalten originid und destinationid.

INSERT INTO stadt (origid,destid) VALUES (1,2),(2,3),(4,1),(2,5),(5,2),(3,6),(5,4),(6,5),(6,7);

Indem wir bei Abfragen latch setzen, sagen wir der Engine welche Informationen wir aus dem Graphen wollen, sprich welche interne Funktion ausgeführt wird. Zum Beispiel latch=0 entspricht keiner Funktion, holt die Daten aus dem Graphen. Das Ergebnis erhält die Spalte linkid. Hier fragen wir schlicht, welches sind die nächsten Kreuzungen von 6 ausgehend,

MariaDB [graph]> select linkid from stadt  where origid=6 and latch=0 ;
+--------+
| linkid |
+--------+
|      7 |
|      5 |
+--------+

Wollen wir den kürzesten Weg, so setzen wir latch=1 via seq bekommen wir noch die einzelnen Schritte:

MariaDB [graph]> select linkid,seq from stadt  where origid=6 and destid=3 and latch=1 ;
+--------+------+
| linkid | seq  |
+--------+------+
|      6 |    0 |
|      5 |    1 |
|      2 |    2 |
|      3 |    3 |
+--------+------+

Der kürzeste Weg von 5 nach 2 ist offensichtlich der direkte.

MariaDB [graph]> select linkid,seq from stadt  where origid=5 and destid=2 and latch=1 ;
+--------+------+
| linkid | seq  |
+--------+------+
|      5 |    0 |
|      2 |    1 |
+--------+------+

Via weight (default=1) werden einzelne Wege gewichtet. Je mehr desto ungünstiger:

MariaDB [graph]> update stadt set weight=10 where origid=5 and destid=2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [graph]> select linkid,seq from stadt  where origid=5 and destid=2 and latch=1 ;
+--------+------+
| linkid | seq  |
+--------+------+
|      5 |    0 |
|      4 |    1 |
|      1 |    2 |
|      2 |    3 |
+--------+------+
4 rows in set (0.00 sec)

Und schon ist der direkte Weg so ungünstig, dass der Umweg um den Häuserblock sich lohnt. latch=2 tut so, als wäre für alle weight=1:

MariaDB [graph]> select linkid,seq from stadt  where origid=5 and destid=2 and latch=2 ;
+--------+------+
| linkid | seq  |
+--------+------+
|      5 |    0 |
|      2 |    1 |
+--------+------+


Es ist auch möglich herauszubekommen, welche Nodes/Kreuzungen zwei Kanten/Straßen entfernt sind:

MariaDB [graph]> select linkid,weight from stadt  where origid=1  and latch=2 and weight=2;
+--------+--------+
| linkid | weight |
+--------+--------+
|      5 |      2 |
|      3 |      2 |
+--------+--------+

Arbeiten mit OQGraph mach schon Spaß, doch es gibt noch eine Anzahl an Limitierungen. So zum Beispiel Table Locking, keine Transaktionen und in Memory only. OpenQuery sucht nach Sponsoren, um diese Limitierungen (Daten auf Storage) zu beheben.

Für alle deren Englisch so miserabel wie meins ist:
If you have a need for persistence, more speed on larger datasets, and increased storage efficiency, please contact Open Query. You'll probably want the backend storage to be on SSD, but HD will technically work. The pricing for that edition is simple, $/EUR 5000.  Licensing also GPLv2+ unless you have other needs.

Damit ist nicht gemeint, dass schon etwas existiert. Musste selbst im #irc nachfragen, da ich dies vermutet hatte:)
Ganz im Gegenteil wird nach Sponsoren gesucht. Das war ein kurzer Einblick. Auf die Dokumentation ist verlinkt und viel Spaß beim selber Spielen;)


Vortrag auf der DOAG

| 1 Kommentar | Keine TrackBacks
Moinsen,
werde am 16.11 auf der DOAG über das Pluginkonzept von MySQL, wie einige Plugins referieren dürfen.
Geplant ist ein managertauglicher Vortrag:)