With high probability, I will start as research assistent (aka PhD student) at the Paderborn Center for Parallel Computing.
There I will research in the area of storage systems, especially on the topic "data deduplication". It is really nice to be able to continue and complete the work of my master thesis.
Vorgestern wurde ein sehr guter Beitrag bei Software Engineering Radio veröffentlicht. Dieses Mal kein Model-Driven Buzzword-Bingo, sondern ein Beitrag über die Architektur von eBay. Randy Shoup, ein eBay-Architekt, stellt vier Hauptideen vor:
- Partition everything
- Asynchrony everywhere
- Automate everything
- Design the system keeping in mind that everything fails at some time
Im Grunde sind es die klassischen Ideen für Internet-Scale Systems. Ähnliche Ideen werden auch vorgestellt in "On Design and Deploying Internet-Scale Services" , ein Paper über die Erfahrungen des Windows Live Server Teams.
Eine weitere, meiner Meinung nach zentrale, Idee wurde nicht in der Zusammenfassung genannt: Der teilweise Verzicht auf die ACID-Eigenschaften und verteilte Transaktionen, weil diese die Performance und Skalierbarkeit einschränken. Diese Idee wird auch von Pat Helland (damals Amazon, heute (wieder) Microsoft) in "Life beycond Distributed Transactions: An Apostate's Opinion" ausgeführt.
Wirklich ein hörenswerter Podcast-Beitrag.
Bei InfoQ gibt es auch ein Video über das gleiche Thema.
Einer der Vorteile von Python ist die gute Integration von C-Bibliotheken z.B. um einzelne Funktionen aus Performancegründen auszulagern. Die Zusammenarbeit mit Java ist viel schwieriger. Es gibt mehrere Gründe, warum eine bessere Zusammenarbeit wünschenswert ist. Zum einen sind die sehr umfangreichen Bibliotheken ein riesiger Vorteil der Java-Welt, auf der anderen Seite könnte man eine Verbindung mit Java-Legacy-Anwendungen aus Python heraus herstellen wollen.
Es gibt mit Jython eine Python-Implementierung auf der JVM, die natürlich sehr einfach mit Java-Bibliotheken und -Programmen zusammenarbeiten kann. Jython hat in letzter Zeit einige Fortschritte erzielt, aber die Implementierung ist immer noch Jahre hinter der aktuellen Entwicklung der Sprache hinterher. In vielen Situationen scheidet Jython als Alternative einfach aus.
Eine Lösung, die ich seit einigen Wochen verwende, ist JPype. JPype erlaubt aus normalen (C-)Python heraus Zugriff auf Java-Bibliotheken und integriert diese gar nicht schlecht. Ein Beispiel:
import jpype
jpype.startJVM(jpype.getDefaultJVMPath(), "-Djava.class.path=%s" % classpath)
java = jype.JPackage("java")
de = jype.JPackage("de")
contact = de.dirkmeister.example.Contact(surname = "Meister")
contact.mail = "XYZ@XYZ.de"
contact.sendMail("Test-Mail")
java.lang.System.out.println("Mail sent")
Die Integrationg geht soweit, dass Java’s hashCode() Methode als __hash__, equals() als __eq__ und toString() als __str__ verwendet werden, so dass man quasi kaum merkt, ob ein Objekt nur ein Python- oder ein “Java”-Objekt ist. Selbst Getter- und Setter werden als Python-Properties integriert und sogar Exceptions werden transparent umgesetzt. Auch Swing-Anwendungen sollen einfach möglich sein.
Nachdem die Hürde der Installation überwunden hat, gestaltet ich die Arbeit erstaunlich flüssig und problemlos.
Ich verwende JPype um in Python auf das Hadoop Distributed File System (HDFS) zu zugreifen und dabei die volle FileSystem-API auf eine pythonifizierte Art zu verwenden z.B. sollen die Stream-Objekte als “File-like Objects” integriert werden. Den Code will ich in ein paar Wochen auf hier vorstellen.
This is a video about scaling the blogging site wordpress.com using techniques like WP-Cache and horizontal database partitioning using a "a plugin" called HyperDB.
The video is really interessing, but I woundered about the calculation of the maximal number of pages views possible with several configurations. The speaker claimed for example that the base wordpress installation can handle 8 requests per second and the can therefore handle 691.000 requests a day. But this is only true if the requests are uniformly distributed around the day.
When I plan to handle the requests even at the peak times (I mean day peak times not really extraordinary events like a Digg-attack), you can handle 8 requests per second at the peak, not on the average. Using the average over-the-day distribution of juli-blogs.de (based on the hours average) with peaks at 19h, I get a number that is smaller by more than a factor of 4. And even that is highly aggregated and not conservative calculation. Ok, even that number is clearly high enough for most wordpress sites (sure for dirkmeister.de ;-) )
Twitter ist eine stark wachsende Web 2.0-Anwendung, die mit Rails entwickelt wurde.
Ich möchte mich hier gar nicht mit dem Sinn und Unsinn von Twitter beschäftigen, sondern ich möchte mich auf ein aufschlussreiches Interview mit dem Twitter-Entwickler Alex Payne verweisen in dem es auch um die Skalierbarkeit von Rails geht.
In dem Interview heisst es:
Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.
The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time.
The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t] reach your site.
None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.
Dies hat mit der (Grundsatz-)Entscheidung des Ruby Entwicklers David Heinemeier zu tun, sich um Skalierbarkeit und Performance wenig Gedanken zu machen. Er gibt Entwicklern den Rat "Don’t scale".
Ein (in der extremen Form wie ihn David Heinemeier gibt) riskanter Rat wie Greg Linden in diesem Posting von 2005 argumentiert.
Auf der Konferenz SD Forum 2006 haben zwei eBay-Architekten mit der Präsentation "The eBay Architecture"(pdf) die Architektur vorgestellt mit der eBay eine Milliarde Page Views pro Tag, 2 Petabytes Daten und und 212 Millionen registrierte Benutzer bewerkstelligt.
Die Slides wurden im Blog "Adding Simplicity - An Engineering Mantra" von eBay-Architekt Dan Pritchett veröffentlicht.
Es ist interessant zu sehen wie eBay diese Aufgaben bewältigt und wie sich die Architektur von eBay im Laufe der Jahre verändert hat.
Besonders interessant finde ich den Abschnitt "Scale the Data Tier", weil eBay bei der Datenhaltung gege viele Dogmen, die man so in Vorlesungen wie "Datenbanken", DBIS und so vermittelt bekommt, verstößt.
eBay verlagert alle CPU-intensiven Arbeiten in die Anwendungsschicht z.B. die Sicherstellung der referentiellen Integrität, Joins und das Sortieren der Daten.
Es werden absolut keine client-seitigen Transaktionen oder verteilte Transaktionen verwendet. Auf diese Weise werden Deadlocks vermieden und Schreiboperationen können verschränkt werden.
Weitere Blog-Einträe über die eBay-Architektur-Präsentation:
