Kristian Köhntopp hat einen sehr schönen Artikel über die Funktionsweise von InnoDB sowie der Bedeutung der einzelnen InnoDB spezifischen Optionen in der my.cnf geschrieben. Vielen Dank!

Nachdem ich schon seit vielen Jahren einen Account bei Xing (früher OpenBC) und seit anderthalb Jahren ein Profil bei StudiVZ habe, betreibe ich nun auch bei Facebook Seelenstriptease.

Diese “Social Networking” Portale finde ich auf viele verschiedene Arten faszinierend. Aber erstmal der Reihe nach. Am Mittwoch suchte ich aus Spaß nach ein paar Leuten, die ich im Tanzkurs kennengelenrt habe, und zwar mit genau den Suchparametern, die man in einer ganz normalen Konversation unter Studenten innerhalb von 2 Minuten in Erfahrung bringt: Vorname, Studienfach, Hochschule,. Was als Spaß begann, brachte schnell beunruhigende Tatsachen ans Licht: Die Trefferquote dieses Versuches lag bei nicht weniger als 100%.

Auf den ersten Blick ist das natürlich eine feine Sache: Man lernt jemanden kennen, möchte mit diesem in Kontakt treten, schaut schnell in’s Studiverzeichnis und drei Klicks später hat man alle notwendigen Informationen, um mit dieser Person in Kontakt zu treten.

Schaut man sich die Geschichte allerdings etwas genauer an, so wird einem schnell klar, welche Probleme dies mit sich bringt: Sobald man die oben genannten Parameter einer Person X in Erfahrung bringt, kann man mit Hilfe von StudiVZ die Liste der in Frage kommenden Personen so weit einschränken, dass das eindeutige Identifizieren dieser Person X im größten Teil der Fälle innerhalb weniger Minuten möglich ist.

Oder um das nochmal verständlicher auszudrücken: Durch die unschuldigen Fragen: “Wie heisst du? Was studierst du? Wo studierst du?” ist man heute schon in der Lage, fast jeden deutschen Studenten im StudiVZ wiederzufinden.

Machen wir uns nun einmal die Implikationen dieser Aussage auf unsere heutige Gesellschaft klar: Sobald ich ein StudiVZ Profil besitze, gebe ich bei jedem durchschnittlichen Gespräch, das ich mit irgendjemandem führe, genügend Informationen preis, um meine Identität komplett offenzulegen.

Die Frage, die sich nun natürlich stellt, ist, ob ein ungezwungener Umgang mit anderen Menschen so überhaupt noch möglich ist. Wird der eigene Vorname, das Studienfach oder der Studienort zur vertraulichen Information? Bisher war es eigentlich nicht ungewöhnlich, jemandem, den man gerade neu kennengelernt hat, zumindest seinen Vornamen mitzuteilen. Wird sich dies in Zukunft vielleicht ändern?

Bevor wir diese Frage beantworten, sollten wir uns jedoch zuerst überlegen, was Menschen dazu bewegt, ihre privaten Daten in exibizionistischer Art und Weise auf Webportalen der ganzen Welt zur Verfügung zu stellen. Der erste Schritt hierzu ist die Anmeldung bei dem besagten Portal. Meiner Meinung nach ist der Hauptgrund für die Anmeldung eins Users nicht der Verlangen, seine persönlichen Daten preiszugeben, sondern vielmehr der Wunsch, Informationen über andere Personen in Erfahrung zu bringen. So könnte man sich beispielsweise dafür interessieren, welcher Beschäftigung die ehemaligen Klassenkameraden heutzutage nachgehen.

Um die gewünsche Information zu erhalten, muss der neue User allerdings erst etwas tun, nämlich ein eigenes Profil anlegen. Hierzu ist die Eingabe einer Mindestmenge an Information erforderlich.

Nun hat man den User nun durch das Wecken des Bedürfnisses nach Information bereits dazu gebracht, ein Profil im Social Network anzulegen. Dadurch wächst beim neuen User auch gleich das nächste Bedürfnis, nämlich das Verlangen nach einer positiven Selbstdarstellung: Ein leeres Profil sieht nicht gut aus, und das Löschen des Profils ist natürlich auch keine Option, da man hiermit ja auch den eigenen Zugang zu dem Dienst löschen würde.

Der Erfolg des Social Networks steht und fällt mit dem Anzahl der darin enthaltenen User. Natürlich würde sich niemand bei einem Dienst anmelden, der kaum User besitzt. Wie das Bootstraping des Social Networks genau aussieht ist natürlich Geschäftsgeheimnis des Betreibers. Geld auf die ganze Geschichte zu werfen, hilft allerdings. So kann man z.B. materielle Anreize für neue User schaffen, sich anzumelden. Wenn man sich nun die Tatsache vor Augen führt, dass die finanzielle Macht hinter StudiVZ niemand geringeres als die Samwer Brüder, denen die Welt auch schon Jamba! zu verdanken hat, ist, so ist dieses Szenario sogar recht wahrscheinlich. Wenn man nun noch weiß, dass StudiVZ Anfang 2007 für fast 100 Mio Euro von Holtzbrinck Networks gekauft wurde, wird schnell klar, welchen Wert eine Datensammlung dieser Größe besitzt.

Fakt ist, dass die Trennung zwischen der “realen” Welt, und der virtuellen Welt des Internets lange nicht mehr zeitgemäß ist. Zwischen diesen beiden Welten hat längst eine Verschmelzung stattgefunden. Ereignisse des realen Lebens werden im Internet in Text-, Bild- und Tonform dokumentiert und Aktionen im Internet haben Einflus auf das reale Leben. So melden wir uns z.B. im Internet zu Klausuren an, überweisen Geld via Onlinebanking, kommunizieren mit Leuten per und E-Mail oder stellen eben auch private Informationen über uns im Internet zur Verfügung.

Nun aber zurück zu meiner eigentlichen Frage, ob denn ein ungezwungener, offener Umgang mit Leuten im realen Leben so noch möglich ist. Sicher ist, dass sich unsere Gesellschaft durch die oben beschriebene Verschmelzung starken Veränderungen unterliegt. Die Welt ist kleiner geworden, Informationen über andere Personen sind leichter den je, zu bekommen. Wie genau diese Veränderungen aussehen werden, bin ich nicht in der Lage, vorherzusagen. Sicher ist jedoch, dass die besagten Veränderungen nichtmehr rückgängig gemacht werden können, und dass wir einen völlig neuen Umgang mit unseren Informationen werden erlernen müssen.

Ich möchte damit sagen, dass man sich vollkommen fern von Social Networking Diensten halten sollte – dies würde wahrscheinlich sehr schnell dazu führen, dass man in eine Art digitale Aussenseiterrolle gedrängt wird. Warnen möchte ich jedoch davor, zu viele, zu private Informationen von sich selbst preiszugeben. Oder Informationen, die einen später diskreditieren könnten – denn eins ist sicher: Das Netz vergisst nichts.

Lieber Leserin, lieber Leser,

zunächst einmal möchte ich mich entschuldigen, dass ich so lange schon nichts mehr geschrieben habe. Viel ist passiert in der letzten Zeit, genüg was es eigentlich wert wäre, seperat gebloggt zu werden – ob ich dazu die Muße habe weiss ich allerdings noch nicht.

Das interessanteste wahr wohl mein zweiwöchiger Tripp nach Colorado. Für mich war das ja der erste Aufenthalt in den USA und ich muss sagen, es hat mich sehr beeindruckt. Ich muss ja zugeben, dass ich anfangs sehr skeptisch und unsicher war, weil ich nicht wusste was mich erwartet. Und auch zugeben muss ich, dass ich, was dieses Land angeht, sehr viele Vorurteile hatte. Für mich war es auf jeden Fall eine sehr wichtige Erfahrung, und eine Menge neuer Eindrücke, die erst einmal verarbeitet werden mussten.

Der eigentliche Anlass für die Reise war ja eher beruflicher Natur, Artus hatte mich zum diesjährigen PASS Community Summit eingeladen, der größten Veranstaltung rund um das Thema Microsoft SQLServer. Die Veranstaltung war sehr stark auf das Thema Business Intelligence konzentriert, was ja auch gerade mein Studienschwerpunkt ist. So konnte man durchaus das ein oder andere interessante mitnehmen. Das Beste an der durchaus sehr guten Veranstaltung waren allerdings die vielen interessanten Leute, die wir kennengelernt haben.

Nach den USA gab es noch zwei Wochen privaten Urlaub mit Freunden in Mallorca, der auch sehr schön und vor allem sehr erholsam war. Für mich war das der erste richtige Urlaub seit über drei Jahren, und vor allem die Gelegenheit, mal wieder auf den Boden zurück zu kommen. Gerade das letze Jahr war viel anstrengender als ich dachte, und wie gestresst ich wirklich war, merkte ich eigentlich erst, als ich mal eine Zeit ganz ohne Stress geniessen konnte.

Frisch erholt zurück hatte ich nun endlich die Energie, mich mal um ein paar Dinge zu kümmern, die ich schon eine ganze Weile vor hatte, für die sich allerdings nie die Zeit gefunden hat. So habe ich einige Bastelprojekte wieder aufgenommen – unter anderem habe ich eins von fd0s Etherrapes zusammenbebaut und endlich mit dem lang geplanten Laser Beamer angefangen, den ich schon seit 5 Jahren bauen wollte. Ausserdem habe ich beschlossen, dieses Jahr etwas mehr an der Uni zu tun (geplant sind 1 Vertiefungsfach, 3 Wahlpflichtfächer, 1 Seminar und 1 Studienarbeit – mal sehen, wieviel davon am Schluss noch übrig ist. , wieder einen Tanzkurs angefangen und schon viel für meine Kunden gearbeitet.

Ich glaub, ich sollte öfter Urlaub machen, das tut nämlich gut.

Ich gehöre nun wirklich nicht zu den Leuten, die übertriebenen Wert auf Rechtschreibung legen (um ehrlich zu sein habe ich da oft selbst das ein oder andere Problem). Auch bin ich niemand, der sich prinzipiell gegen Fremdwörter wehrt, auch nicht gegen Englische. Aber gerade im E-Mail Verkehr begegnen mir in letzter Zeit Dinge, die man bestenfalls als grausam bezeichnen kann. Beispiel:

• Kontakten: Hierbei handelt es sich um einen Reimport des englischen Verbs “to contact” ins Deutsche. Das Wort Kontakt stammt vom lateinischen Wort “contingere” (berühren) ab. Die korrekte deutsche Form von “kontakten” lautet “kontaktieren” oder besser “Kontakt aufnehmen”.
• !!!!!!! – schrecklich! Ausrufezeichen stehen im Deutschen nach Ausrufe-, Wunsch- und Aufforderungssätzen, nach Ausrufewörtern, dem Irrealis. Ausserdem habe ich in der Schule mal gelernt, dass man es in der Anrede von Briefen an Stelle des Komma verwenden kann. Auch eingesetzt wird es zur besonderen Betonung von Aussagesätzen und hier liegt meiner Meinung nach das Problem. Offenbar vertreten einige Leute die Ansicht, dass die Verwendung besonders vieler Ausrufezeichen dazu führt, dass ihr Problem oder Anliegen besonders schnell behandelt wird:
  “Der Mailserver geht nicht!!!!, “Ich komme nicht ins Internet!!!!” (oder schöner: “Das Internet geht nicht!!!!”), “Bitte drum kümmern!!!!!”.
  Doch hierbei wird genau das Gegenteil von dem erreicht, was man eigentlich erreichen wollte: Auf den Leser wirkt dies plump und aggressiv, man hat oft garkeine Lust mehr, sich dem Problem anzunehmen. An dieser Stelle würde ich gerne Terry Pratchett zitieren: “Mehrfache Ausrufezeichen sind ein sicheres Zeichen für einen kranken Geist.”
• “@person:” – man schreibt eine E-Mail an mehrere Personen. Nun möchte man innerhalb dieser E-Mail mehrere Personen adressieren (Ob dies sinnvoll ist, oder ob es nicht doch besser wäre, in diesem Falle mehrere E-Mails zu schreiben sei nun mal dahingestellt). Die korrekte Möglichkeit wäre meiner Meinung nach die Anrede mit Name und nachgestelltem Komma.
  Beispiel: “Hallo Stefan, Hallo Peter! Die E-Mail von Herrn Müller habt ihr sicherlich erhalten. Stefan, richtest bitte den Account entsprechend den Wünschen des Kunden ein. Peter, kümmere du dich bitte darum, Ihn noch heute zurückzurufen.”
  Die Anrede mit @ erinnert bestenfalls an ein Webforum und wirkt in einer E-Mail mindestens unfreundlich.

E-Mail scheint leider immer noch ein Medium zu sein, bei dem aufgrund seiner schnellen Auslieferungsgeschwindigkeit und vermeintlich kurzen Lebensdauer der Eindruck herrscht, man müsse sich nicht so viel Mühe beim Formulieren geben wie bei normaler Post. Ich möchte hier zu Bedenken geben: Ein Großteil der Papierpost landet nach kurzer Zeit in irgendwelchen Ordnern oder in Rundablage P; E-Mails jedoch überdauern oft Jahre in den Mailclients und IMAP Servern der Empfänger und eine einzige unfreundliche E-Mail kann selbst nach Jahren beim Durchsehen des Mail Archivs noch für Unmut bei eben diesem sorgen.

In http://justinsomnia.org/2007/08/search-engine-marketeers-are-the-new-script-kiddies/ beschreibt Justin Watt, wie er eines Tages fesstellen musste, dass seine Seite plötzlich aus dem Google Index verschwunden war. Durch einiges Nachforschen stellt er fest, dass ein Suchmaschinenspammer daran schuld ist – aber lest selbst, der Artikel ist sehr spannend und lesenswert.

Bei einem Kunden haben wir neulich einige Datenbanken auf einen neuen Datenbankserver umgezogen. Da wir aus Latenzgründen jedoch nicht alle Anwendungen auf den neuen Server umstellen konnten (der neue Server befindet sich im Rechenzentrum eines anderen Providers), haben wir uns entschlossen, eine Kopie der Datenbanken auf dem bisherigen Datenbankserver zu belassen.

Nun stellte sich allerdings das Problem, dass wir irgendwie beide Datenbanken synchron halten mussten. Replikation war leider keine Option, da wir den besagten Server bereits mit einem Backup-Server replizierten. Auch das periodische ziehen eines Dumps kam nicht in Frage, da wir die Daten nach dem Schreiben sofort auf beiden Systemen benötigten.

Wir entschieden uns daher, die Pflegeanwendung in beide Datenbanken gleichzeitig schreiben zu lassen. Damit es zu keinen Problemen mit inkonsistenten Datenbeständen zwischen den beiden Servern kommt implementierten wir das Schreiben folgendermaßen:

Starte Transaktion auf Server 1
Starte Transaktion auf Server 2

For QUERY in QUERIES:
    Führe Query auf Server 1 aus
    Führe Query auf Server 2 aus

If !ERROR:
    Commite Transaktion auf Server 2
    Commite Transaktion auf Server 2

Else:
    Rolle beide Transaktionen zurück

In unseren Tests lief alles gut, das Transaktionshandling funktionierte. Selbst bei provozierten Fehlern verhielt sich alles so, wie erwartet.

Kurz nach der Installation der Anwendung beim Kunden traten jedoch Probleme auf mit einem Fall, den wir leider vollkommen übersehen hatten: Durch einen unglücklichen Umstand war es möglich, auf Server 1 ein Insert-Query auszuführen, das auf Server 2 fehl. Eigentlich sollte hier unser Transaktionshandling eingreifen und die Änderungen rückgängig machen.

So weit die Theorie. In der Praxis hat das Rollback zwar durchaus die Änderung rückgängig gemacht, hat allerdings das AUTO_INCREMENT Value nicht wieder dekrementiert. Dies bedeutete nun, dass das AUTO_INCREMENT auf Server 2 eins niedriger war als das auf Server 1, was dazu führte, das alle weiteren Updates fehlschlugen, da nun alle von unserer Tabelle abhängigen Foreign Keys schief standen.

Die rettende Idee kam von einem Kollegen: Nach dem ausführen des Insert Statements auf dem ersten Server lesen wir nun mit LAST_INSERT_ID() den Wert der AUTO_INCREMENT Spalte aus und fügen diese explizit in den Set Part des Statements, das wir auf dem zweitem Server ausführen, ein. Somit laufen die IDs nicht auseinander und unser Tag und die Applikation war gerettet.

MySQL überrascht mich immer wieder. Gerade ist mir aufgefallen, dass es in der Version 5.0 möglich ist, über mehrere Datenbanken hinweg Foreign Keys zu setzen. Der Syntax dafür lautet wie folgt:

FOREIGN KEY(`blub`) REFERENCES  `andereDatenbank.andereTabelle` (`column`) ON …

Und  ja, das funktioniert wirklich und ja, der MySQL Server enforced die Foreign Keys richtig. Und ja, ich bin mir ziemlich sicher, dass das in der Version 4.1 noch nicht ging.

Durch einen freundlichen Hinweis von Christoph erfuhr ich heute von einem Google Vortrag in der Uni, den ich auch spontan besuchte. Der Vortrag wurde von Thomas Hofman gehaltern, seineszeichens “Director of Engineering” bei Google in Zürich. Davor war er Professor an der ETH.

Der Vortrag war sehr interessant, einige bemerkenswerte Dinge möchte ich hier in Auszügen wiedergeben.

(weiterlesen…)

Einer meiner Kunden hatte nach einem Datenbankredesign das Problem, dass einige Anwendungen noch nicht auf das neue Datenbankdesign umgestellt war. Also hatten wir die Idee, mittels Views die alte Struktur auf Basis der neuen Datenbank nachzubauen. Es stellte sich nun folgendes Problem: Die neue Datenbank befindet sich auf einem ganz anderen Server wie die alte. Nach einigem Überlegen fassten wir den Plan, die Views auf dem entfernten Datenbankserver, auf dem sich auch die neue Datenbank befindet, zu definieren und diese als Federated Tables auf dem Datenbankserver, mit der alten Datenbank einzubinden. Zangsläufig ergab sich daraus für uns die Frage, ob es überhaupt möglich ist, Federated Tables auf Views zu definieren. Um es kurz zu fassen: Es ist möglich! Ein Select auf die Federated Table ist sogar recht performant.

Wie sich jedoch leider herausstellte, überträgt die Federated Storage Engine bei einem Join den gesamten Inhalt der Tabelle, was dazu führt, dass ein Join gelinde gesagt – äh – nicht wirklich performt. In unserem Testfall dauert ein Join über zwei Tabellen über 20 Sekunden. Insgesamt war die Lösung also leider nicht für den praktischen Einsatz geeignet.

Das Problem mit dem Join ist den MySQL Entwicklern übrigens bekannt, und Abhilfe wurde in Aussicht gestellt. In welcher Version diese Verfügbar sein wird, ist mir allerdings nicht bekannt.