mthie spaces

Ich hatte vorhin ein interessantes Gespräch mit einem Coder. Dieser versucht derzeit, ein Portal hochzuziehen und damit in Zukunft sein Geld zu verdienen. Das Portal ist auch soweit in den Grundzügen "fertig" und eigentlich kann es losgehen. Promotion wird bereits betrieben und Geldgeber sind vielleicht auch im Anmarsch. Also kann es ja eigentlich losgehen. Eigentlich.

Allerdings ist man überhaupt nicht darauf vorbereitet, von den Usern überrannt zu werden. Es gibt ein paar Kleinigkeiten, die auf jeden Fall bedacht werden muessen. Die Liste hat übrigens keinen Anspruch auf Vollständigkeit und Richtigkeit, sondern das sind einfach so meine Erfahrungen.

• wieviele Web-Server brauche ich am Anfang, um ca. 1.000 Besucher gleichzeitig abzufrühstücken - diese Zahl der Server wächst später natürlich stetig
• wie verteile ich diese User auf all diese Server - die Last muss per LoadBalancing verteilt werden
• wo speichere ich die Sessions der Besucher zentral - alle Webserver sollten in der Lage sein, jeden Besucher zu bedienen, ohne dass auf jedem ein neuer Login gemacht werden muss
• muss ich cachen - die Antwort lautet immer "JA"
• was muss ich cachen - cache ich nur die Ausgabe, weil das eh für alle User gleich ist oder cache ich auch Datenobjekte, damit diese nicht bei jedem F5 im Browser einen fiesen JOIN auf mehrere Tabellen machen müssen
• wie muss ich cachen - am Besten nicht auf der Festplatte, sondern im Arbeitsspeicher; keinesfalls in einer Datenbank, weil man sich das Caching sonst nämlich fast sparen könnte
• muss ich etwas berechnen - wenn man größere Datenmengen berechnen möchte, sollte man darüber nachdenken, ob man Computeserver benötigt; dies geht meistens mit Queueing einher, um das Computing gut zu verteilen
• kann mein Datenspeicher skalieren - nicht jede Datenbank kann wirklich gut skalieren; man muss sich halt je nach den zu erwartenden Userzahlen richten, welches System man benutzt, sollte aber auch etwas weiter rechnen, da Migrationen nicht immer so problemlos sind, wie man gerne glaubt
  
• ist meine Serverinstallation skalierbar - wenn man jeden Server einzeln installieren muss und sei es selbst anhand einer Step-by-Step-Anleitung, ist dies für eine schnelle Expansion untragbar, wenn man nur mal an 10 Server denkt; alle werden unterschiedlich sein, weil man irgendwas übersprungen, vergessen oder anders gemacht hat; lieber Installationsscripte und Packages für alle Komponenten, dies macht die Softwarewartung deutlich einfacher

Ich denke, ich werde diese Liste in Zukunft vielleicht noch etwas erweitern.

Der Sonntag lief viel entspannter. Ich hatte zwar Mühe aufzustehen, weil die Party im Sankt Oberholz doch etwas länger war, aber nach einer kurzen wässrigen Erfrischung gings dann. Ich kam grad beim Telekom-Gebäude an, als die Sessions festgelegt wurden, sodass ich noch mit abstimmen, mir aber nebenbei einen kleinen Snack gönnen konnte.

Leider konnte der Cellity-Vortrag zum Thema "Addressbook 2.0" keine Zuhörer gewinnen. Mich interessiert das Thema dann nämlich eigentlich doch, aber das muss wohl das falsche Publikum sein.

Meine erste besuchte Session war dann "Twitter im Unternehmen". Mich interessierte das Thema eigentlich sehr, da man meiner Meinung dort wirkliche gute Statusmeldungen machen kann, was auch die Kollegen interessiert. Außerdem finde ich die Möglichkeit der Diskussionsplatform nicht schlecht.

Leider hat der Vorträger dann aber dahingestellt, dass Twitter eigentlich für unternehmensinterne Kommunikation nicht brauchbar ist und hat dann noch zusätzlich Wordpress mit einem bestimmten Modul vorgestellt, was er selbst aber dann auch als "nicht genügend" deklariert hatte. Und dann kam's dann ganz dick: Er stellte seine eigene Software vor, die das alles besser, schöner und mit mehr Zeichen kann: "Communote". Das hatte für mich dann auch nichts mehr mit Twitter zu tun und ich bin dann gegangen, um am Ende nochmal zu lauschen, ob dazu Kommentare kommen, dass dies keine Werbeverkaufsveranstaltung ist, was aber nur minimal angeregt worden ist :(

Die nächste Session zum Thema "Zend Framework" war da dann schon deutlich interessanter (wenn man schon damit arbeitet ;)). Der Vortrag wurde auf englisch gehalten, weil es einen englischsprachigen Zuhörer gab. Als dieser dann gegen Ende gegangen ist, hat's niemand bemerkt und alle haben auf englisch weitergesprochen, bis ich dann angemerkt habe, dass wir ja unter uns seien. Schon wurde die Diskussionsrunde gleich größer und es sind weitere spannende Kontakte entstanden.

Ich hatte mir zwar dann noch weitere Sessions auf die ToVisit-Liste geschrieben, die ich dann aber dynamisch irgendwie vergessen und dann abgesagt habe. Zum Schluß gab es noch eine Lotterie, bei der so jeder auf einen wirklich großartigen Sitzsack gehofft hatte. Nunja, ich wurde zwar gezogen, aber bei der Verlosung, bei der es drei Bücher zu verlosen gab: "Mac OS X 10.5", "iPod und iTunes" sowie "MySQL 5". Letzteres wird dann wohl auch das einzige Buch sein, was es aus seiner Verpackung schafft, bei mir als Linux-User. :)

Nach der Verlosung war dann auch schon Schluss und ich bin dann gemütlich in Richtung Bahnhof und von dort aus nach Hause gefahren.

Mein Fazit: Die spürbare Werbeverkaufsveranstaltungsatmosphäre war zwar irgendwie nicht wie eine Unconference, sondern eher wie eine Konferenz, aber sonst fand ich es sehr schön die Leute kennenzulernen und ich würde dies dann gerne nächsten Monat in Hamburg wiederholen beim Barcamp Hamburg 2008 :)

Puh, nach dem Essen sind wir alle gemeinsam ins Sankt Oberholz gegangen, wo die angemeldeten Teilnehmer Freigetraenke geniessen durften.

Die Kneipe ist mit WLAN ausgestattet, sodass es den Bloggern, Twitterern und sonstigen Nerds an nichts fehlen sollte. Natürlich wird es immer und überall irgendwann voll, es waren ja auch schließlich fast 500 Leute für die Party registriert.

Dadurch, dass @mspro ein Massen-Beleidigung2.0-Twittern gestartet hatte, kam man schnell mit Leuten, die man zwar von Twitter kannte, aber noch nie gesehen hatte, schnell ins Gespräch und der Abend verlief danach eher ruhig, aber lustig mit vielen witzigen Bekanntschaften.

So, nun war ich auf meinem ersten Barcamp. Und das sogar in Berlin, der Stadt, die ich eigentlich nie so wirklich besuchen wollte. Ich war damals 1986 das letzte Mal in Berlin und da war ich vier und es war noch die DDR...

Eigentlich hatte ich bisher zwar von den Leuten häufig positive Meinungen über Berlin gehört, allerdings wollte ich das aufgrund vieler anderer Berichte nicht so recht glauben und hab Berlin immer etwas "verabscheut". Trotzdem muss ich sagen, bin ich recht positiv überrascht, dass diese Stadt doch so interessant ist.

Die Strassen voller Menschen und nicht so dreckig, wie ich glaubte. Allerdings war ich in Berlin-Mitte... Vielleicht ist das einfach kein Maßstab.

Nun gut, zurück zum Barcamp. Ich kam im Telekom-Gebäude an, zu dem ich mich erstmal zweimal verlaufen hatte. Dort holte ich mir mein Namensschildchen, ein T-Shirt und ein paar Sticker ab, gab meine Jacke bei der kostenlosen Garderobe ab und schaute mich erstmal um. Wirklich ein beeindruckender Bau, den die Telekom da hat.

Zum Glück traf ich dann auch gleich mal ein paar Bekannte, sodass ich nicht ganz so verlassen da stand. Dazu gesellten sich dann später noch weitere Leute, denen man schon bei Twitter followed, aber man sich noch nie getroffen hat. Man kommt bei so einem Barcamp schon aufgrund des WLANs ins Gespraech, weil jeder Tipps gibt, wie man rein kommt, aber nur alle Tipps zusammen bringen es dann ;-)

Übrigens ist das Telekomgebäude so groß, dass man gar nicht gemerkt hat, dass da 600 Leute waren.

Naja und dann gab es ja auch noch Vortragssessions und ich bin erstmal in den Vortrag "5 reasons why all web software projects fails". Schade nur, dass die Vortragsräume überwiegend keine Räume waren, sondern es war ein großer Raum und dieser war mit Trennwänden geteilt worden. Das war natürlich übermäßig laut und kaum jemand, der weiter als 3 Reihen vom Vorträger entfernt war, hat noch ansatzweise ein Wort verstanden.

Dies berichteten natürlich alle Leute und auch dem Orga-Team war dies bewusst, war aber leider nicht anders machbar.
Später dann hab ich mir noch eine Erlang-Einführung angeschaut und danach viel genetworked und viele interessante Leute kennengelernt, sowie sehr gute Diskussionen gehabt.
Alles in allem, ein guter Tag aber es war eher eine kostenlose Konferenz, als eine Unconference. Danach gings dann erstmal zum Essen ins 12 Apostel und zur Party im Sankt Oberholz.

Ich hatte gestern Abend das Vergnügen, von Jan Lehnhardt eine Präsentation über die CouchDB zu sehen. Man denkt sich natürlich gleich: «Yet another database engine». Aber das stimmt so nicht, denn CouchDB ist keine typische relationale Datenbank wie MySQL, sondern basiert auf Dokumenten. Jeder, der schon einmal etwas mit Lotus Notes gemacht hat, weiß wovon ich rede. Man hat pro Datensatz ein Dokument (ähnlich wie die Zeile in einem RDBMS), welches wiederum Attribute mit Werten beinhaltet. Diese Attribut-Wert-Paare sind als JSON-Arrays im Dokument gespeichert.

Am Beispiel eines registrierten Users auf einer Website sähe das dann so aus:

{
"username": "MyUsername"
"password": "EncryptedPassword"
"enabled": 1
}

Diesen Inhalt gibt die Datenbank dann auch genauso zurück und jede halbwegs aktuelle Programmiersprache kann das JSON dann von Haus aus dekodieren.

Der Zugriff auf die Datenbank ist so simpel, dass es wirklich jede Programmiersprache unterstützt, die TCP kann, da man über HTTP mit einer REST-API darauf zugreift. Man ruft also URLs mit den HTTP-Methoden GET, POST, PUT oder DELETE auf und kann damit entsprechende Abfragen tätigen. Dies erzeugt bei lokalen Datenbank nicht so viel Overhead, kann aber durch das HTTP/REST wunderschön gecached werden.

CouchDB selbst ist in Erlang geschrieben und ist damit sogar in 10 Jahren, wenn wir mehrere hundert Prozessorkerne im Server haben, noch up-to-date, wo andere Datenbanksysteme zwecks der Lastverteilung noch mächtig nachholen werden müssen.

Ähnlich wie bei Lotus-Notes kann man die Datenbank auch verteilt betreiben und replizieren, da alle Dokumente versioniert sind und die Datenbank sehr gute Replikationsalgorithmen dafür hat. Durch diese Versionierung hat man sogar Konfliktdokumente, wenn mal ein Datensatz von mehreren System geändert wurden und dann drüberrepliziert werden. Dies ist vielleicht im Web nicht so der Alltag aber lösbar und eigentlich auch etwas, was man will. Denn diese Konfliktdokumente werden auch versioniert und man hat keinen Datensatzverlust. Man kann sich für diesen Zweck Mergescripts schreiben, die solche Probleme dann automatisch lösen, denn wenn auf einer DB nur der Username und auf einem anderen Server nur das Passwort geändert wurden, sollte das kein Problem für ein Script darstellen, da man ja schauen kann, was sich seit der letzten Version wirklich geändert hat.

Diese Replikationen muss man allerdings im Gegensatz zu anderen DBMS manuell anstoßen. D.h. man lässt sich von CouchDB an ein Script Bescheid geben, dass Datensätze geändert wurden, und dieses Script kann dann je nach belieben z.B. nach 1000 Transaktionen die Replikation zu anderen DB-Servern anstoßen. Das hat Vor- allerdings auch Nachteile. Das kann aber jeder bei Projektbeginn bedenken und ein anderes System benutzen :)

Natürlich hat man bei solchen dokumentbasierten Datenbanken das Problem, dass man ja nicht immer den Key kennt, nachdem man in der Datenbank nach einem Datensatz sucht. Dafür gibt es in CouchDB Views. Diese darf man aber nicht so recht mit Views aus RDBMS vergleichen, sondern eigentlich ist es ein Index auf der Datenbank, den man abfragen kann. Diese Indexe/Views werden per JavaScript-Syntax festgelegt und lazy aktualisiert. Es gibt in der CouchDB eine Storage- sowie eine Index-Engine. Diese Index-Engine fragt einfach regelmäßig den Storage (oder bei Aufruf des Views), ob sich was geändert hat und ergänzt dann den Index. So kann es dann auch schon mal vorkommen, dass ein Index ein bisschen hinter dem Datenbestand hinterherhinkt, aber auch das kann man bei der Programmierung bedenken, z.B. wenn man nach dem Einfügen einfach mal den View aufrufen lässt. Dies wird sich in zukünftigen Versionen bestimmt noch einfacher lösen lassen, denke ich, ist aber derzeit für die Schreibgeschwindigkeit ein Plus, da nicht beim Schreiben, wie bei MySQL, direkt auch alle Indexe der entsprechenden Spalten mit aktualisiert werden müssen, was z.B. bei UNIQUE-Indexen und großen Datenmengen eine wirkliche Strapaze ist.

Da kommen wir auch gleich mal zu einem kleinen Nachteil. Solche UNIQUE-Indexe gibt es in dokumentbasierten DBMS nicht. Dies muss man schon selbst in die Hand nehmen, was meist von den eh besser skalierbaren Webservern gemacht werden kann.

Auf der CouchDB-Homepage wird auch von vornherein gesagt, dass es kein Ersatz für eine RDBMS ist, womit die Entwickler natürlich nicht ganz unrecht haben. Es gibt für jeden Einsatzzweck das beste Tool und kein DBMS ist für alles das Beste, auch nicht CouchDB. Allerdings bietet diese derzeit knapp 7,5k Codezeilen-Datenbank (ohne die JavaScript-Engine, diese stammt von Mozilla) sehr viele Vorteile, wenn man einen erweiterten Key-Value-Speicher benötigt. Außerdem hat es durch den Erlang-Hintergrund wirklich sehr großes Potenzial, was die Skalierbarkeit angeht.