Karl Brodowsky's IT-Blog – Seite 40 – IT Sky Consulting GmbH

Wo bleiben die Transaktionen bei den NoSQL-Datenbanken?

Jetzt war mal wieder so ein Vortrag bei einer der vielen User-Groups, in der ich drin bin. Diesmal ging es um Riak und der Vortrag war von einem der Entwickler und war wirklich gut. Ein Stück weit wurde die Grundsatzthematik der NoSQL-Datenbanken behandelt, wobei natürlich Riak im Zentrum stand.

Während es bei den SQL-Datenbanken vielleicht etwa vier gibt, die einigermaßen austauschbar sind, was die Funktionalität betrifft (Oracle, MS-SQL-Server, DB2 und PostgreSQL, mit Einschränkungen auch mySQL und MariaDB), ist hier die Frage relevant, das richtige Werkzeug für die richtige Aufgabe zu verwenden. Und das richtige Werkzeug sind oft die relationalen transaktionalen Datenbanken. Die Austauschbarkeit der relationalen Datenbankprodukte gilt natürlich nur, wenn man eine neue Applikation entwickelt, nicht wenn man Software nachträglich umschreiben muss und die Datenbankadministrationsprozesse nachträglich ändern muss.

Nun sind die Daten ja immer sehr wichtig, sonst könnte man sich den Aufwand ja sparen, sie zu speichern. Und wenn die Datenbank nicht transaktional ist, dann ist das gruselig, weil die Daten nicht zuverlässig und nicht genau genug gespeichert werden. Das Versprechen der transaktionalen Datenbanken für Transaktionen wird ja kurz mit „ACID“ bezeichnet:

„Atomic“ bedeutet, dass die Transaktion entweder komplett oder gar nicht ausgeführt wird
„Consistent“ bedeutet, dass die Daten immer in einem konsistenten Zustand sind.
„Isolated“ bedeutet, dass verschiedene gleichzeitig laufende Transaktionen sich nicht gegenseitig beeinflussen.
„Durability“ bedeutet, dass die Daten nach Abschluss der Transaktion garantiert dauerhaft gespeichert sind.

Super, da kann nichts mehr schief gehen. Und Software von Oracle oder IBM ist serienmäßig komplett fehlerfrei, von Microsoft sowieso und bei PostgreSQL bauen die Entwickler der Software, die die Datenbank verwendet, allfällige Fehler der DB-Software selbst noch kurz in der Nacht aus… Aber fairerweise muss man sagen, dass die Kernfunktionalität der Datenbankprodukte tatsächlich recht zuverlässig funktioniert und die nervigen Fehler eher am Rande bei unwichtigen Dingen wie Installern oder Security-Features aufgetreten sind, die hier nicht das Thema sind. 😉

Also gut, man kann also mal annehmen, dass die DB-Software vernünftige Zuverlässigkeit hat. Was ist mit der Hardware? In einem großen Rechenzentrum muss rein rechnerisch immer irgendwo ein Hardwaredefekt sein. Ist aber kein Problem, man baut die Hardware und damit die Datenbankinstallation einfach redundant auf. Und es gibt tolle Mechanismen, die mit erheblichem Aufwand sicherstellen, dass ACID immer noch gilt. Man hat also eine Datenbank, die auf mehreren Rechnern läuft und sich gegen außen wie einer verhält. Eine Transaktion kann auch mehrere dieser Rechner involvieren. Egal was passiert, soll immer ACID-Transaktionalität gelten. Mit „Two-Phase-Commit“ und solchen Werkzeugen kann man das hinbekommen. Zumindest sagt man, dass es in der Praxis zuverlässig funktioniert. Vielleicht bis zu einer gewissen Größe, denn wenn eine einzige Datenbank ein ganzes großes Rechenzentrum beansprucht, kann man sich sicher auf einen hohen Stromverbrauch verlassen, aber mehr will ich dazu hier nicht sagen. Reale Rechenzentren, die transaktionale Datenbanken betreiben, haben erfahrungsgemäß auch viele mehr oder weniger unabhängige Datenbanken am Laufen.

Man kann also mit recht großen ACID-transaktionalen Datenbanken die Unzuverlässigkeit der Hardware recht gut in den Griff bekommen. Das ist nicht billig und es lohnt sich gute Datenbankberater heranzuziehen.

Wie sieht es mit der Applikationssoftware aus? Die wird heutzutage ja oft in Java geschrieben und läuft deshalb in der Sandbox, was ja alle Probleme verhindert, weil die Sandbox unterbindet, dass irgendwas gefährliches gemacht wird… 😉

Ist die Applikationssoftware fehlerfrei? Oder zumindest so fehlerfrei, dass nie mit den Daten etwas schief gehen kann? Vielleicht, wenn man optimistisch ist? Wenn wir schon bis hierher Optimismus aufbauen konnten… Die transaktionale Datenbank ist ein nütziches Werkzeug, wenn man sie mit hinreichend korrekter Software benutzt. Aber das machen wir alle und auf dem Laptop des Entwicklers hat es wirklich funktioniert, es sind halt die Benutzer schuld, die mehrere Requests gleichzeitig abschicken. Was ist mit dem „I“ aus ACID passiert? Ja, die Datenbank macht es schon richtig, aber die Applikation stürzt ab oder erzeugt korrumpierte Daten. Oder verwendet zu kleine oder zu große Transaktionen. Schade…

Nun kommt aber noch die Software- und Systemarchitektur ins Spiel. Man fängt an, ein großes System über mehrere Server zu verteilen, Caching wird verwendet, Teilbereiche der Daten werden über Services angesprochen. Natürlich arbeitet man mit tollen Frameworks und die Datenbank ist für den Applikationsentwickler schon recht weit weg, aber immer noch macht man irgendwo implizit oder explizit schöne Transaktionen auf und beendet sie mit commit oder rollback. Niemand weiß mehr, in welcher Schachtelungstiefe von solchen Methoden, die implizit Transaktionen durchführen, man sich befindet und mit bestimmten Mustern kann man das aus Versehen austricksen, aber so etwas passiert natürlich nicht. Wie sieht es jetzt mit ACID aus?

Kurz gesagt, für reale Applikationen muss man genauer hinschauen, ob ein etwas schwächeres Modell als ACID wirklich ein Nachteil ist.

Nun muss man aber noch einmal auf den Ausgangspunkt zurückkommen. Transaktionen lassen sich sehr gut für nicht-relationale Datenbanken definieren und auch implementieren. Umgekehrt kann man für manche Zwecke durchaus relationale SQL-Datenbanken verwenden, die nicht transaktional sind. Oder man hat wie bei MongoDB Transaktionen für einzelne DB-Operationen, kann diese aber nicht zusammenfassen.

MongoDB im RAM

Hier ist eine interessante Beschreibung, wie man MongoDB (unter Linux) komplett im RAM betreiben kann:

How to use MongoDB as a pure in-memory DB (Redis style)

Die Idee ist einfach und interessant, weil sie sich auch für viele andere, ähnlich gelagerte Anwendungsfälle eignet.

Für die Entwicklung von Mongo-DB-basierenden Applikationen und vor allem für die Unit-Tests kann das auch eine sehr nützliche Sache sein.

Responsive Design

Neu ist dieser Blog mit „responsive design“ ausgestattet. Das bedeutet, dass das Layout sich von selber kleinere Bildschirme von Mobiltelefonen anpasst.

Auch die Seite IT Sky Consulting GmbH hat responsive Design. Dies ist nur mit CSS umgesetzt, die HTML-Seiten existieren nur einmal.

Ein paar Besonderheiten von Linux/Unix-Filesystemen

Unix und in der Folge auch Linux liegt ein gewisses Verständnis darüber zugrunden, wie die Dateisysteme (Filesysteme) funktionieren. Man kann zwar unter Linux auch Filesysteme wie FAT32 einbinden, die diese Eigenschaften nicht haben, sollte das aber nur tun, um Daten mit einem Medium auszutauschen, das auch von anderen Betriebssystemen verwendet wird, nicht aber für die eigentliche Linux-Installation, nicht einmal für das Home-Verzeichnis.

Man hat aber heute eine Vielzahl von guten Filesystemen zur Verfügung, die die benötigten Features haben.

Grundsätzlich ist ein Verzeichnis (engl. Directory) selbst eine spezielle Datei, die die darin vorkommenden Dateinamen und jeweils eine Referenz zu einem sogenannten I-Node (inode) enthält, wo u.a. gespeichert ist, welche Berechtigungen, welche Änderungs- und Zugriffsdaten und welche Größte die Datei hat und wo man deren Inhalte finden kann. Normalerweise sind die Dateien in „Blöcken“ gespeichert, die z.B. 1024 Bytes groß sind, wobei der letzte Block normalerweise nicht vollständig ausgenutzt wird. Zusätzlich benötigt man bei größeren Dateien mit vielen Blöcken eine Struktur, um diese zu finden, die im I-Node selbst keinen Platz hat.

Nun kann man sogenannte „hard-links“ anlegen, z.B. mit ln. Das bedeutet, dass ein I-Node von mehreren Verzeichnissen referenziert wird. Der hard-link und sein
Original sind dabei völlig gleichberechtigt, es gibt keinen Unterschied zwischen dem zuerst vorhandenen Eintrag und dem neuen, als Hardlink angelegten. Deutlich zu unterscheiden ist das von sogenannten Softlinks, die auf einen anderen Verzeichniseintrag verweisen und damit indirekt auf eine Datei, wenn dieser Verzeichniseintrag tatsächlich existiert. Wegen der hard-links kann eine Datei also beliebig oft im Dateisystem eingetragen sein und wenn man sie mit rm löscht, dann wird in Wirklichkeit nur der eine Eintrag im Verzeichnis gelöscht. Nur wenn diese Datei wirklich nirgendwo sonst mehr referenziert wird, wird sie auch selber gelöscht. Dazu führt der I-Node noch einen Referenzzähler.

Was passiert nun, wenn man eine Datei mit einem Programm öffnet und löscht, bevor das Programm beendet ist? Etwa so etwas:

In xterm1:

$ sort grosse-datei.txt > sorted.txt

Und in xterm2 direkt nachdem das sort gestartet wurde, aber bevor es beendet wurde:

$ rm grosse-datei.txt

?
Die Datei wird wirklich aus dem Verzeichnis gelöscht, ist also mit ls nicht mehr zu sehen.

Das „sort“ greift aber über den I-Node darauf zu und hat noch weiterhin zugriff, zählt also auch als eine Referenz in der Zählung. So kann sort seine Arbeit noch beenden, aber kein anderes Programm mehr auf diese „halb-gelöschte“ Datei zugreifen. Man kann das mit df -k erkennen. Sobald das sort fertig ist, wird der Referenzzähler im I-Node heruntergezählt und wenn nicht noch Hardlinks oder andere Programme darauf zugreifen, dann geht er auf 0 runter und die Datei wird wirklich gelöscht, erkennbar mit df.

Vorsicht ist natürlich geboten bei Programmen, die eine Datei zwar lesen, aber dabei eine raffinierte File-Handle-Verwaltung benutzen, also die Datei immer wieder kurz zum Lesen öffnen, ein paar Daten lesen und wieder schließen, um aufwendige Berechnungen mit den Daten zu machen, bis der nächste Lesezugriff erfolgt. Bei so einem Programm würde das Wiederöffnen der Datei in unserem obigen Szenario zu einem Fehler führen, weil die Datei vom System als nicht mehr referenziert erkannt und
definitiv gelöscht worden wäre.

Die typischen Unix/Linux/Posix-Tools wie grep, sort, uniq, cat,…. öffnen aber die betreffende Datei nur einmal und lesen alles sequentiell. Dieses raffinierte Öffnen und Schließen ist eher bei Datenbanksytemen und datenbankähnlicher Software zu üblich.

Wenn man dieses Verhalten kennt, kann man damit viel anfangen, wenn man es nicht kennt, gibt es wohl gelegentlich Überraschungen.

Design-Patterns: Singleton

English

Dieses Singleton-Pattern hat den Vorteil, dass man es sich merken kann und damit beim Thema Design-Patterns dabei ist.

Interessant ist höchstens die Frage der Initialisierung („lazy“ oder „eager“) und vielleicht noch die Frage der Abhängigkeiten, wenn man sehr viele Singletons hat.

Aber ich möchte hier einmal auf zwei Verallgemeinerungen eingehen.

Ein Singleton ist „einmal“ „im ganzen Programm“ vorhanden. Verallgemeinerungen können also bei dem „einmal“ oder bei dem Universum (hier „im ganzen Programm“) ansetzen.

Das „einmal“ auf eine bestimmte endliche Anzahl zu erweitern ist für viele Routine. Bei den Java-Entwicklern nennt sich das enum, aber in anderen Programmiersprachen gibt es oft ähnliche Konstrukte oder man kann sie sich leicht selber aufbauen, indem man die Erzeugung bestimmter Objekte einschränkt und nur für die endlich vielen „enum-Einträge“ Instanzen anlegt und entsprechend erreichbar macht.

Die andere, etwas komplexere Verallgemeinerung setzt bei dem „Universum“ an. Eine Applikation kann verteilt sein oder mehrere parallele Prozesse (nicht nur Threads) verwenden, womit man ein potentiell größeres Universum als beim klassischen Singleton hat. Frameworks kennen so etwas oft und es sind dort Komponenten oder „Beans“ mit „Application-Scope“. Entsprechend gbit es kleinere Universen, zum Beispiel „Session Scope“.

Wenn man also nur diese Komponenten richtig als Verallgemeinerungen des Singleton-Patterns liest, werden diese obskuren Frameworks vielleicht etwas verständlicher und nützlicher. Und die Investion, mal mit diesem einfachen Design-Pattern anzufangen, hat sich gelohnt. Irgendwann werden wir sehen, ob sich noch andere Patterns lohnen… 😉

SSD billiger als magnetische Festplatten?

In der vergangenen Woche war ein interessanter Vortrag bei der Elastic Search User Group in Zürich, vom Gründer der Firma und des Projekts…

Eine Bemerkung war, dass es in typischen Elastic-Search-Anwendungen billiger sein kann, SSDs als magnetische Festplatten einzubauen. Magnetische Festplatten sind natürlich für das gespeicherte Byte viel billiger, aber wenn man Durchsatz in Bytes/sec braucht, seien SSDs billiger.

Ein interessanter Gedanke, erst einmal verwirrend.

Aber man baut letztlich eine Serverfarm auf, um die nötige Leistung zu erbringen. Wenn nun die Hauptaufgabe dieser Server in geschickten Lesezugriffen auf ihren Daten besteht, dann braucht man mit vollständiger Verwendung von SSDs weniger Server. Das könnte kostengünstiger sein. Und gerade für überwiegendes Lesen sind SSDs unumstritten gut.

Mobiltelefon-Betriebssysteme

Heutige Mobiltelefone sind meisten kleine Computer, die abgesehen von den Bedienelementen und der Anzeige etwa dem Stand eines Laptop- oder Desktopcomputers von vor 10 Jahren entsprechen. Das trifft für die sogenannten Smartphones zu, aber wohl auch für einen Teil der nicht als Smartphone bezeichneten Geräte. Witzigerweise gibt es sogar dieselben drei Betriebssysteme, die wir auf Desktoprechnern heute häufig finden, jeweils in Varianten für Mobiltelefone, wobei Linux bei den Mobiltelefonen in Form von Android klar dominiert, was beim Destop ja erst für 2014 erreicht werden könnte ;-), während das MS-Windows-Phone im Gegensatz zu seinem großen Bruder auf dem Desktop eher eine Randerscheinung ist.

Nokia war Anfang 2011 mit Symbian Marktführer und hatte mit Maemo und Meego aussichtsreiche Systeme in der Entwicklung, um diesen Stand zu halten, hat sich aber selbst abgeschossen bzw. ist vom Management versenkt worden und jetzt nur noch ein unbedeutender Nischenanbieter für diejenigen, die gerne ein MS-Windows-Mobiltelefon haben wollen und dieses nicht von einem der ostasiatischen Anbieter kaufen. Die Entwicklungsabteilungen sind 2011 weitgehend abgewickelt worden, aber vielleicht ist das auch eine Chance für innovative Startup-Firmen, die in Finnland und anderen ehemaligen Nokia-Standorten sehr gute Entwickler für Mobiltelefone und Mobiltelefonsoftware finden können. Eine solche Startup-Firma ist Jolla, die das ehrgezeige Ziel verfolgen, mit einem kleinen Teil der ehemaligen Nokia-Entwickler an die Tradition dieser Firma anzuknüpfen und die besten Mobiltelefone zu bauen. Ob das ein Erfolg wird, werden wir sehen, es ist sicher noch zu früh, darüber etwas zu sagen. Und was die besten Telefone sind, darauf gehe ich weiter unten noch kurz ein.

Blackberry (bzw. damals als Firma noch RIM) hatte für ein Marktsegment ein gutes Telefon mit einem Gesamtkonzept angeboten und für den Zweck, EMails zu schreiben, sind diese Geräte mit einer echten Tastatur wohl immer noch den reinen Touch-Screen-Geräten von Samung, HTC und Apple überlegen, aber ihr Marktanteil ist trotzdem zurückgegangen. Waren „Coolness“ und „Mode“ und die bessere Spielesammlung wichtiger als ein zweckmäßiges Arbeitsgerät? Oder reicht es in der Regel, die Mails unterwegs lesen zu können? Wir werden sehen, ob die neuen Blackberry-Geräte nach dem „Relaunch“ diesen Trend aufhalten können.

Android ist sicher im Moment mit großem Vorsprung Marktführer, was Apple mit iOS trotz Hype nie war und wahrscheinlich auch nicht mehr werden wird, weil sie ihren Zenit schon überschritten haben und jetzt auf dem absteigenden Ast sind. Wir werden in ein paar Jahren sehen, ob Apple es schafft, sich als Nischenanbieter zu stabilisieren. Man weiß nicht, was die Zukunft bringt, aber es lässt sich doch heute erkennen, dass Leute, die Android und iOS-Telefone (oder sagen wir Samung- und Apple-Geräte?) kennengelernt haben, meistens die Android-Geräte präferieren. Den „Coolness“-Faktor haben heute selbst in der sehr Apple-orientierten Schweiz eher die Top-Android-Geräte. Da nun das Apples Geschäftsmodell mit dem App- und Musikstore sehr auf einen Massenmarkt fixiert ist, wird es spannend, wie es sich auswirken wird, wenn der Rückgang nicht nur in Marktanteilprozenten, sondern auch in absoluten Zahlen spürbar wird. Aber es ist ja gut, dass wir eine gewisse Vielfalt und damit einen Wettbewerb der Systeme haben.

Auf der Linux-Seite gibt es übrigens noch andere Systeme außer Android, die interessant werden können. Fast zu viele, könnte man sagen. Maemo ist auf dem Nokia N900 eingesetzt worden, mir sind aber keine zukünftigen Mobiltelefon-Projekte bekannt, die Maemo verwenden wollen. Meego war ein gemeinsames Projekt von Nokia und Intel, das auf dem N9 zum Zuge kam und für das es gerüchteweise Entwicklungen bei Nokia gab, um recht „kleine“ Smartphone zu bauen, die relativ wenig kosten, wenig Strom verbrauchen oder nicht so schwer und groß im Gepäck sind, aber diese Entwicklungen sind alle eingestellt worden, bevor die ersten Geräte damit erschienen sind, deshalb werden es wohl Gerüchte bleiben. Meego selbst wird wohl von keinem großen Anbieter mehr verfolgt, aber daraus sind Tizen, das Samsung in Zukunft verstärkt einsetzen möchte, und Sailfish von Jolla entstanden. Nun gibt es noch ein Ubuntu-Derivat für Mobiltelefone, Ubuntu Mobile, FirefoxOS und vielleicht noch WebOS. Eine schöne Sammlung an Systemen und wer noch ein altes Zweit-Smartphone hat, kann vielleicht sogar ein paar von diesen Systemen ausprobieren. Vielleicht mache ich das selber auch einmal, dann wird es hier Erfahrungsberichte gbeben…

Da die allermeisten Anwender, zu denen ich mich auch zähle, das Betriebssystem nutzen, das mit dem Telefon ausgeliefert wird, ist die Frage also auch, was die Gerätehersteller so anbieten werden. Vielleicht wird es aber auch wie bei Desktop- und Laptop-Computer Angebote geben, die nur die reine Hardware verkaufen und dem Benutzer die Wahl lassen, welches der Systeme darauf installiert wird? Wenn sich für die Entwicklung von Mobiltelefonapplikationen HTML5 weitgehend durchsetzt, wird es auch kein Nachteil mehr sein, eine seltene Plattform zu haben. Zumindest von Sailfish weiß ich aber auch, dass sie auch die Möglichkeit vorsehen, Android-Apps zu installieren und auszuführen, was vielleicht nicht so schwierig ist, da ja beides Linux-basierte Systeme sind, allerdings ist die Grafikschicht wohl sehr verschieden, was doch noch eine größere Hürde sein könnte. Interessant ist noch, dass der Linux-Kernel bei diesen Systeme praktisch derselbe Linux-Kernel ist, der auch auf größeren Systemen bis zu den größten Supercomputern läuft, abgesehen von kleineren Unterschieden bedingt durch die Prozessorarchitektur und die Versionsnummern. Wie es bei iOS und MS-Windows-Phone ist, ob diese Systeme viele Gemeinsamkeiten mit ihren großen Brüdern MacOS X und MS-Windows haben oder nur kleine Teile gemeinsam nutzen und einfach gemeinsam vermarktet werden, weiß ich nicht.

Welches System ist nun das beste? Ich denke, dass das jeder selber entscheiden möchte. Die Grundfunktionen, die man eigentlich braucht, können alle. Das sind gar nicht viele:

Telefonieren
SMS (ja, dafür gibt es Flatrates)
Licht, um ein Schild zu lesen oder ein Zahlenschloss zu öffnen oder so
Fotografieren (ja, da gibt es Unterschiede, Nokia soll mit dem am besten gewesen sein)
Musik hören
EMails lesen und schreiben (beim Schreiben sind Geräte mit physikalischer Tastatur wie Blackberry oder N900 im Vorteil)
Webseiten lesen, Webapplikationen verwenden (das können alle)
Landkarten und Navigation (da ist Android gut, Nokia war noch etwas besser und Apple will und wird das auch irgendwann einmal können)
Kalender
Uhr
Wecker

Und natürlich braucht man noch sehr viele Apps, was ich auf dem N900 auch habe, obwohl das ein eher seltenes System ist. Ja, einige Apps sind schon schön zu haben, wie zum Beispiel die SBB-App oder das Äquivalent von der deutschen Bahn, die man nur für Android und iOS bekommt, aber dort helfen auch die entsprechenden Web-Applikationen ganz gut weiter. Aber wenn man die Unmengen an Apps anschaut und diejenigen, deren Funktion sich gut durch vorhandene Webapplikationen ersetzen lässt oder die nicht wirklich viel bringen, aussortiert, bleiben sicher ein paar interessante Apps übrig, die man vielleicht sogar in die obige Liste hinzufügen möchte. Man kann sich noch überlegen, ob man Freude daran hat, Firmen zu unterstützen, die durch exzessive Patentklagen auf sich aufmerksam machen, zum Teil mit Trivialpatenten, wie man sie nur in den Vereinigten Staaten bekommen kann. Oder Firmen, die bei Einkäufen mit dem Mobiltelefon, die mit einer App getätigt werden, 30% vom Umsatz einsammeln, was mehr als Wucher ist. Ich denke, dass man ähnlich wie man in der EU einem großen Betriebssystemanbieter das Bundling von OS und Browser eingeschränkt hat, auch den Herstellern von Mobiltelefonen und Mobiltelefonbetriebssystemen abverlangen könnte, dass sie es dem Anwender ermöglichen, einen anderen App-Store und einen anderen Musik-Store zu verwenden als den vom Systemanbieter betriebenen.

Letztlich ist es wie bei Kleidung überwiegend eine subjektive Entscheidung, welches Mobiltelefon und welches zugehörige Betriebssystem man bevorzugt und deshalb auch schwierig, darüber zu diskutieren, welches besser ist. Welche Kleidung wird primär mit technischen Eigenschaften wie z.B. der Reißfestigkeit verkauft?

Versionsverwaltung

Versionsverwaltung (englisch „Source Code Management“ oder „Revision control“) ist für Software-Entwicklung, aber zunehmend auch für andere Bereiche in der Informatik nicht nur nützlich, sondern geradezu unentbehrlich. Vielleicht das erste derartige System war SCCS, das durch das von Walter Tichy entwickelte RCS ersetzte aber fast SCCS vollständig. RCS mag noch eine gewisse Existenzberechtigung haben, wenn man lokal einzelne Dateien versionieren will und dies schon seit langer Zeit mit RCS macht, aber die Einschränkungen waren doch erheblich: RCS funktionierte nur innerhalb des Dateisystems. Mittels NFS oder SMB kann man zwar gemeinsame Dateisysteme mounten oder als Netzwerklaufwerke verbinden, aber die Restriktion war letztlich störend und unnötig. Außerdem konnte man nur einzelne Dateien, nicht aber Verzeichnisse und Gruppen von Dateien verwalten. Gewisse Wrapper wie z.B. SNiFF+ oder MKS versuchten diese Einschränkungen teilweise zu umgehen, letztlich war aber die auf der Basis von RCS entstandene Neuentwicklung CVS die bessere Lösung. Auch wenn CVS heute längst obsolet ist. Etwa gleichzeitig kam ClearCase auf, ein ebenfalls heute nicht mehr empfehlenswertes System. Sowohl CVS als auch ClearCase haben aber Konzepte eingeführt oder populär gemacht oder auch nur getestet, die man für heutige Versionsverwaltungssysteme verwendet oder auch für überflüssig erkannt hat, man konnte auch wieder aus den Schwächen dieser Systeme lernen. CVS hat keine Konsistenz sichergestellt, das heißt, dass bei einer Änderung, die mehrere Dateien umfasst, jemand, der zeitnah mit dem Einfügen der Änderungen ins CVS daraus liest, unter Umständen eine nicht lauffähige Mischung aus alt und neu erhält. Das Umbenennen und Verschieben von Verzeichnissen und Dateien, insbesondere in der Java-Welt als „Refactoring“ bekannt und populär, wird sehr schlecht unterstützt bzw. durch das Löschen und Neuanlegen behelfsmäßig abgebildet. Und binär-Dateien werden schlecht unterstützt. ClearCase hat zusätzlich noch weitere Nachteile: Es ist sehr langsam, unzuverlässig und braucht einen hohen Administrationsaufwand. Außerdem waren die Lizenzen einmal sehr teuer, was aber heute egal sein sollte, da es keinen vernünftigen Grund gibt, neue Projekte mit ClearCase anzufangen und bei vorhandenen Projekten die Lizenzierung gelöst und bezahlt sein sollte. Immerhin macht einem der Lizenz-Manager noch zusätzlich gelegentlich das Leben schwer. MS-VisualSourceSafe habe ich eine zeitlang sporadisch benutzt und es war etwa zwischen RCS und CVS anzusiedeln, soll aber durch ein besseres TFS ersetzt worden sein, das ich nicht kenne.

Nun kommen wir zu den Systemen, die man heute noch benutzen kann, auch ohne durch Altlasten dazu gezwungen zu sein. Ein Ersatz für CVS war SubVersion, das die wesentlichen Schwächen von CVS behebt. Wenn auch durchaus Linus‘ Torvalds Kommentar dazu bedenkenswert ist: „SubVersion is CVS done right, but CVS can’t be done right“ oder so ähnlich, z.B. in diesem Tech Talk von 2007. Git hat ein funktionierendes verteiltes Repository gebracht. Das bedeutet, dass man sogar ohne Netzwerkverbindung noch mit dem immer vorhandenen lokalen Repository arbeiten kann, dass „Backups“ einfach durch die Vielzahl der Repositories „passieren“, sogar ohne dass man sie explizit durchführt (was man natürlich trotzdem tun sollte) und dass die parallele Arbeit von sehr vielen Entwicklern an verschiedenen Orten erleichtert wird. Ein Problem ist dabei sicher die Benennung von Versionen, wenn man nicht von einem zentralen „Zähler“ abhängig sein will. Für Google mag es sinnvoll sein, in vielen größeren Rechenzentren eine Atomuhr aufzustellen, so dass man recht zuverlässige Zeitstempel hat, aber mein Laptop ist offline doch schon einmal etwas ungenau mit seiner Uhrzeit. Git verwendet eine SHA1-Prüfsumme von 128 Bit Länge, die ihren Zweck einigermaßen zuverlässig erfüllen, weil es schwierig ist, eine Datei zu konstruieren, die denselben Prüfsummenwert liefert, selbst wenn man es gezielt versucht. Mercurial und vielleicht auch Bazaar sollen ähnliche Features wie git bieten und es ist teilweise eher eine Geschmacksfrage, welches dieser Systeme man verwendet. Vielleicht hat git einen kleinen Vorteil wegen der hohen Verbreitung und wegen github.

Kurze Zusammenfassung: Subversion ist nicht schlecht, man kann das für kleine Projekte nehmen oder es beibehalten, wenn es in vorhandenen Projekten eingesetzt wird. Aber für neue Projekte oder für Projekte, die heute auf CVS, ClearCase oder anderen veralteten Versionsverwaltungssystemen entwickelt werden, empfehle ich, git, mercurial oder eventuell bazaar einmal genauer anzuschauen und auf eines dieser Systeme zu wechseln. Grundsätzlich sind die sicher alle gut, aber man kann sagen, dass sich git durchgesetzt hat, weshalb es wohl die beste Wahl darstellen dürfte, weil es alle kennen, weil es dafür Infrastruktur gibt u.s.w..

Auch wenn diese Versionsverwaltungssysteme primär für Software-Quelltexte gemacht sind, kann man sie auch für andere Dateien einsetzen. Allerdings gibt es auch Software, die implizit eine Versionsverwaltung enthält, zum Beispiel Wikis wie MediaWiki oder ECM-Systeme oder Dokumentenmanagementsysteme wie z.B. OpenText oder SharePoint, wo die Versionsverwaltung nur einen Teil der angebotenen Funktionalität ausmacht. Für die Details würde ich Experten für ECM-Systeme fragen…

Es wird noch interessant, ob uns die Zukunft noch neue interessante Versionskontrollsysteme mit neuen Konzepten bringt oder ob die Generation von Git uns jetzt für eine sehr lange Zeit begleiten wird.

Frohe Ostern

Ich wünsche allen Lesern frohe Ostern!

Festplatten zur Erdbebenmessung

Auch wenn SSDs immer mehr Verwendung finden, sind magnetische (mechanische) Festplatten weiterhin verbreitet und werden es wohl auch noch lange bleiben.

Diese mechanischen Festplatten enthalten Sensoren, mit denen man Erschütterungen erkennen kann, zum Beispiel um den Kopf in eine ungefährliche Position zu bringen, um Schäden zu verhindern. Diese Sensoren sind sicher nicht so genau wie die Seismographen, die man zur Vorhersage von Erdbeben, Tsunamis und Vulkanausbrüchen und für die geophysikalische Forschung verwendet. Aber sie sind überall vorhanden und könnten so wertvolle zusätzliche Daten liefern. Das könnte vielleicht so funktionieren, dass die Betreiber von Rechnern mit Festplatten der Erfassung und Übermittlung von seismographischen Daten an ein geophysikalisches Rechenzentrum zustimmen. Weil die genaue Standortinformation ziemlich essentiell ist, sind sicher stationäre Rechner besser geeignet als Laptops, außer es werden noch GPS-Daten zusätzlich erfasst und übermittelt, was aber ein größeres Missbrauchsrisiko der Daten impliziert. Wenn Millionen von Nutzern mitmachen würden, hätte man genug Daten, um die Ungenauigkeiten der Messung teilweise zu eliminieren, weil nach dem Gesetz der großen Zahl angenommen werden kann, dass sich zufällige Fehler relativ gesehen verringern, wenn man etwa Mittelwerte vieler Messwerte bildet. Systematische Messfehler eines Sensors kann man auch erkennen und korrigieren oder sogar die Ausreißer weglassen. Noch besser wäre vielleicht eine Gewichtung der Messwerte nach Qualität.

Eigentliche Mittelwerte sind nur sinnvoll, wenn man mehrere Festplatten am selben Standort hat, ansonsten wäre wohl eine mehrdimensionale Funktion, die von Ort und Zeit abhängt, zu approximieren. Die Geophysiker wissen etwa, wie diese Funktionen aussehen könnten und man kann die Messwerte, von denen man Ort und Zeit kennt, verwenden, um ein paar Parameter dieser Funktion abzuschätzen. Diese Daten könnte man mit den genaueren Messungen der professionellen Geräte kombinieren. Der Vorteil der Festplattensensoren wäre vor allem, dass man ein viel flächendeckenderes Sensorennetz erhielte als man je durch Aufstellen von Seismographen bezahlen könnte. Das wäre eine echte Big-Data-Anwendung.