Kleine Notiz, auch für mich selbst. Wer aus einer PostgreSQL-Datenbank mal flott alle Duplikate löschen möchte, kann wie folgt vorgehen:
DELETEFROM tabellennameWHERE feldmituniquekey NOT IN (SELECT MAX(dup.feldmituniquekey) FROM tabellenname As dup GROUP BY dup.doppeltezeile1, dup.doppeltezeile2, dup.doppeltezeile3, dup.doppeltezeile4);
Die Anzahl der GROUP-BY-Felder kann beliebig erweitert werden, um das versehentliche Löschen von teilweise identischen Datensätzen zu verhindern.
Um die Vorteile eines LTS-Release von Ubuntu (aktuell 10.04.2) weiterhin genießen zu können, ohne auf aktuelle Software verzichten zu müssen, gibt es unter Ubuntu die so genannten PPAs, Personal Package Archives. Das sind separate Repositorys, mit denen man sein Ubuntu füttern kann um Pakete über die Paketverwaltung zu installieren, die aus irgendeinem Grunde noch keinen Weg in die offiziellen Repositorys der Distribution gefunden haben. Canonical verfolgt die Philosophie, innerhalb eines Release keine Versionssprünge der ursprünglich ausgelieferten Software mitzumachen. Was sehr schade ist, hängt man doch so auf PostgreSQL 8.4, Git 1.7 und Nginx 0.7 fest. Dank einiger fleissiger Paketschnürer gibt es aber PPAs, die genau diese Probleme beheben. Da ich alle drei zuvor genannten Anwendungen/Dienste regelmäßig und auf verschiedenen Servern nutze, habe ich mir dafür entsprechende PPAs rausgesucht.
Um PPAs zum System hinzuzufügen, bietet sich das Kommando add-apt-repository an. Sollte das Kommando nicht gefunden werden können, leistet folgender Befehl Abhilfe:
sudo aptitude install python-software-properties
Dieses Kommando fügt das Repository zur Apt-Sources-Liste hinzu und importiert gleich den passenden GPG-Schlüssel.
Fügen wir nun nacheinander die drei zuvor erwähnten PPAs hinzu:
sudo add-apt-repository ppa:nginx/stablesudo add-apt-repository ppa:git-core/ppasudo add-apt-repository ppa:pitti/postgresql
Ein abschließendes sudo aptitude update nicht vergessen und schon sind die aktuellen Versionen von Nginx, Git und PostgreSQL via apt/aptitude verfügbar.
Die Cloud, das Buzzword des letzten Jahres, ist in aller Munde. Und hat auch schon erste Federn lassen müssen. Was die Cloud eigentlich kennzeichnet, ist nahezu grenzenlose Skalierbarkeit. Wenn es nach den Befürwortern der Cloud geht, bucht niemand mehr physikalische Maschinen, sondern Speicherplatz, RAM, Rechenleistung in dem Umfang, den er benötigt. Wird zwischenzeitlich mal mehr gebraucht, dreht man kurz an der entsprechenden Schraube und zahlt eben für die Zeit ein wenig mehr. Es gibt unheimlich viele Anbieter, gerade Amazon, eigentlich Interneteinzelhändler, hat in diesem Bereich von sich reden gemacht. Amazon bietet alles denkbare an Cloud-Dienstleistungen an, was man sich nur so vorstellen kann. Genau das ist dem Wikileaks-Projekt zum Verhängnis geworden, weil der Anbieter somit auch am einzigen Hebel sitzt. Legt er den um, ist Feierabend. Amazon bietet zwar eine recht große Produktpalette an, alles abdecken tun sie dann aber auch nicht.
Wer beispielsweise Rails-Anwendungen in der Cloud laufen lassen möchte, ist auf andere Dienstleister angewiesen. In den letzten Jahren hat sich ein Anbieter namens Heroku einen Namen in der Community gemacht. Erst kürzlich wurde Heroku von salesforce.com, einem großen Anbieter von Geschäftsanwendungen, für rund 212 Mio. US-$ aufgekauft.
Heroku hat ein für den Entwickler sehr effizient zu nutzendes und einfaches Deployment-Verfahren entwickelt, welches komplett Git– und Rake-gestützt ist. Der Rails-Entwickler muss sich also nicht mit der Administration und Konfiguration von Webservern herumärgern. Ein Vorteil gegenüber den klassischen Rails-Hostern, von denen es ohnehin relativ wenige gibt ist, dass man nicht auf die vom Hoster installierten Ruby-Gem-Versionen angewiesen ist, sondern seine eigenen Versionen spezifizieren kann, wie man es von seiner Entwicklungsmaschine her kennt.
Wer reine Rails-3-Anwendungen deployen möchte, hat seine Anwendung binnen weniger Minuten online:
sudo gem install herokugit initheroku creategit add .git commit -a -m 'first deployment commit to Heroku'git push heroku masterheroku rake db:migrateheroku open
Das war es schon. Die Anwendung sollte online sein und sich im Browser geöffnet haben.
Bei Rails-2-Anwendungen gestaltet sich das Deployment etwas schwieriger, aber auch nicht viel. Bevor man die oben erwähnte Befehlskette anschubsen kann, muss erst einmal eine Datei namens .gems erstellt werden. In dieser müssen dann alle erforderlichen Gems, ggf. inklusive Versionsnummer notiert werden. Beispiel:
rails --version 2.3.5i18n --version 0.4.2rack --version 1.0.1
Erst dann darf deployed werden. Neben den oben erwähnten Möglichkeiten gibt es aber noch viele weitere, die allesamt auf den wirklich tollen Support– und Dokumentations-Seiten von Heroku dokumentiert sind. So kann man, sofern man bereits lokal PostgreSQL verwendet, seinen kompletten Datenbankinhalt mittels heroku db:push in die Anwendung bei Heroku pushen. PostgreSQL ist übrigens die einzige Datenbank, die von Heroku angeboten wird. Laut Heroku deswegen, weil sie dort die optimale Kombination zwischen Zuverlässigkeit, Datenintegrität und Geschwindigkeit sehen. Ein Statement, das ich durchaus unterschreiben kann. Das heroku-Gem ist äußerst mächtig und bietet einem Zugriff auf sämtliche installierbare Add-Ons (s.u.), auf die Logs und noch vieles mehr. Eine Studie der Dokumentation ist empfehlenswert.
Ab sofort kann dann direkt in den Anwendungscontainer bei Heroku deployed werden, indem man ein ganz reguläres Git-Commit erstellt. Einfacher geht es kaum noch.
Nachdem die erste Version der Anwendung deployed wurde, kann man sie um einige tolle, teilweise auch kostenlos nutzbare Add-Ons erweitern. Dazu gehören nützliche Erweiterungen wie CNAME-Einträge für die Anwendung (damit man sie auch unter einer eigenen (Sub-)Domain betreiben kann), Jasondb, MongoDB und CouchDB für die NoSQL-Anhänger unter uns, Exception-Tracker, Echtzeitsuche, New Relic, SMS-Gateways, automatisierte Datenbankbackups, etc. Manche kosten gar nichts, manche nur wenig Geld, andere wiederum sind recht teuer (wobei teuer mal wieder relativ ist). Dolle ins Geld geht ein SSL-Zertifikat, da solche Zertifikate weiterhin IP-basiert sind, was bei einem Cloud-basierten Dienst natürlich recht finster werden kann.
Apropos Kosten: jeder kann bei Heroku beliebig viele Anwendungen hosten lassen, die auch erst mal nichts kosten, in der Leistungsfähigkeit aber arg eingeschränkt sind. Benötigt man mehr Ressourcen, muss man in die Tasche greifen, ab ca. 36 US-$ (0,05 $-Cent pro Stunde) monatlich geht es los. Dabei unterteilt Heroku in Dynos und Worker. Dynos beschleunigen das Frontend, Worker die Hintergrundprozesse der Rails-Anwendung. Der Maximalausbau liegt bei 24 Dynos und 24 Workern, wofür dann aber auch 2,35 US-$ pro Stunde, oder umgerechnet rund 1.700 US-$ monatlich anfallen. Die Performancestufe dürfte aber auch „gehobenen“ Ansprüchen genügen.
Damit ist aber noch nicht Schluss, denn eine dedizierte Datenbank ist bei dem Preis noch nicht inklusive. Kostenlos gibt es 5 MB Shared Database, für 20 US-$ monatlich 20 GB Shared Database. Wer gern eine dedizierte Datenbank hätte, muss bspw. für den kleinsten Tarif Ronin 200 US-$ monatlich berappen. Dafür erhält er 16 gleichzeitige Verbindungen, 1,7 GB RAM und 1 computing unit. Für 6.400 US-$ gibt es 400 Verbindungen, 68 GB RAM und 26 computing units. Wer’s braucht…
Herokus Dateisystem ist read-only, Dateiuploads lassen sich also nicht realisieren. Hierzu kann/sollte man, auch laut Heroku-Dokumentation, auf Anbieter wie Amazon S3 ausweichen. Für Rails-Anwendungen gibt es diverse Möglichkeiten, Uploads zu Amazons S3 (Simple Storage Service) aus der Anwendung heraus zu realisieren. Namentlich erwähnt werden Attachment-Fu und Paperclip. Eine persönliche Präferenz kann ich hier abgeben, ich hab mit beiden noch nicht gearbeitet. Heroku empfiehlt im Übrigen generell, große Dateien, die die Applikation zum Download bereitstellen soll, aus Performancegründen zu S3 oder ähnlichen Services auszulagern, weil das Dateisystem von Heroku nicht für derartige Anwendungszwecke konzipiert und optimiert wurde.
Um die Performanceunterschiede messen zu können, habe ich eine Installation von Redmine bei Heroku vorgenommen. Das Deployen dieser Anwendung ist leider nicht total trivial, die einzelnen Schritte habe ich deswegen in einem Gist (welcher auch noch mal ganz unten eingebettet ist) niedergeschrieben.
Zum Ergebnis meiner Benchmarks, gemessen auf einer Projektübersichtsseite mit ab -c 50 -n 200:
Die Anzahl der Worker wirkt sich also in keiner Weise auf die Anwendungsperformance aus, die Anzahl der Dynos hingegen beträchtlich. Den größten Gewinn (prozentual gesehen) bekommt man hier, wenn man von dem einen kostenlosen Dyno auf einen zweiten, kostenpflichtigen aufrüstet. Die monatlichen Kosten liegen mit diesem bei rund 36 US-$, also umgerechnet in etwa 27 €. Eigentlich nicht zu viel verlangt, man darf nur nicht vergessen, dass in diesem Preis noch kein Storage und nur 5 MB an Datenbankplatz inklusive ist.
Zum Vergleich: mein nicht optimierter Root-Server (Athlon64 X2 6.400+, 4 GB RAM, OpenVZ) liefert rund 10,5
R
equests pro Sekunde. Den muss ich natürlich selbst administrieren, warten, etc. Und das Deployment ist auch längst nicht so bequem bzw. müsste erst mal von mir auf diesen Bequemlichkeitslevel gebracht werden.
Heroku bietet für einen akzeptablen Preis einen wirklich tollen und performanten sowie äußerst flexiblen Service an. Für den Rails-Entwickler, der keine Lust hat, sich mit der Einrichtung und Administration eines Rails-fähigen Webservers rumzuschlagen und ggf. auftretende Probleme zu beheben ist Heroku aus meiner Sicht optimal. Zumal man hier nicht gleich einen zweiten Server hinzu kaufen muss, nur weil die Anwendung an ein oder zwei Stunden am Tag mal mehr Ressourcen braucht, als es die eigene Hardware zulässt. Die Anmeldung kostet nichts und das Deployen der eigenen (oder fremden) Anwendung genau so wenig. Einem Versuch steht also nichts im Wege. Viel Spaß dabei.