Die quelloffene relationale Datenbank RSQL strebt an, abgespeckte Instanzen des Microsoft-SQL-Servers vollständig zu ersetzen.
Datenbank-Systeme (DBS) gibt es seit über 60 Jahren. Solche Software speichert elektronische Daten strukturiert und dauerhaft ab, meist in Form von Tabellen mit Datensätzen einer festen Größe. Die zweite Aufgabe eines DBS besteht darin, diese Daten auch effizient wiederzufinden und bedarfsgerecht ans Licht zu holen. Darum kümmert sich die Datenverwaltung oder neuhochdeutsch das Datenbankmanagementsystem (DBMS). Er organisiert innerhalb des DBS die Ablage der Daten und kontrolliert unter Berücksichtigung der vergebenen Berechtigungen für die verschiedenen Datenbankbenutzer alle Lese- und Schreibzugriffe auf die einzelnen Datenbanken.
Der Zugriff auf Ihre Daten erfolgt mithilfe einer Abfragesprache, beispielsweise via Structured Query Language (SQL), Extended Structured Query Language (XSQL) oder XML Query Language (XQuery). Das hier im Mittelpunkt stehende DBMS namens RSQL [1] verwendet Transact-SQL (abgekürzt T-SQL) [2] und implementiert eine Teilmenge davon. Bei Transact-SQL handelt es sich um eine proprietäre Erweiterung des SQL-Standards durch Microsoft und Sybase. Dieser SQL-Dialekt zeichnet sich durch prozedurale Programmierung, lokale Variablen, Fehlerbehandlung, Zeichenkettenverarbeitung und mathematische Operationen aus [3].
Zur Kommunikation zwischen dem DBS und der Außenwelt dient entweder eine Datenbankkonsole im Terminal, eine Vermittlersoftware in Form eines ODBC- beziehungsweise JDBC-Treibers oder eine passende Bibliothek. Auf Linux-Systemen kommt als entsprechende Library in der Regel die Libdbi [4] zum Einsatz. RSQL liefert einen C#-Treiber mit, über den Sie als C#-Entwickler direkt mit dem DBS kommunizieren [5]. Der Treiber ist funktionell identisch zum C#-SQL-Server-Treiber von Microsoft. Es genügt also, wenn Sie in Ihrem C#-Programm die Zeile using System.Data.SqlClient; durch using Rsqldrv.SqlClient; ersetzen.
RSQL
Hinter RSQL steckt der in Genf beheimatete Entwickler Nicolas Riesch (siehe Kasten “Nicolas Riesch im Interview”). Als Ingenieur betreute er über ein Jahrzehnt lang Datenbanksysteme bei einer Versicherung, insbesondere in Kombination mit dem Microsoft-SQL-Server. Er beobachtete dabei, dass die meisten benötigten Reports vergleichsweise einfach ausfielen und nur einen Bruchteil der Möglichkeiten dessen nutzen, was das DBS mitbringt. Nur wenige Projekte benötigten Events, Trigger, Views und Stored Procedures. Eine passive Datenbank genügte, besonders für Backups.
Im Gegensatz dazu standen die enormen Lizenzkosten für das DBS. Diese stehen in keinem vertretbaren Verhältnis zu den Kosten für das Hosting im Rechenzentrum. Betreibt man mehrere Instanzen – üblicherweise das bewährte Trio für Entwicklung, Test und Produktion – wird das insbesondere für kleinere Unternehmen mit bestehenden Projekten sehr teuer. Der Wechsel zu MariaDB, MySQL oder PostgreSQL umgeht zwar den Kostenfaktor Lizenzen, gleichzeitig erhöht sich aber der Testaufwand. Eine Fülle an Funktionen des DBS bleibt weiterhin ungenutzt.
Den Wunsch, die bestehenden SQL-Anfragen ohne Veränderungen laufen zu lassen, setzte Nicolas Riesch in Form von RSQL um. Nach fünf Jahren Entwicklungsaufwand in vollständiger Eigenleistung liegen 140?000 Programmzeilen Go vor, die das abdecken, was er brauchte. Die Anmeldung zu RSQL erfolgt klassisch über die Kombination aus Benutzername und Passwort. Derzeit liegt die Begrenzung bei 64 parallelen Verbindungen pro RSQL-Instanz (Mehrbenutzer).
|
Kriterium |
Parameter bei RSQL |
|
|---|---|---|
|
Datenbanken pro RSQL-Instanz |
kein Limit für Größe und Anzahl |
|
|
Tabellen pro Datenbank |
kein Limit für Anzahl oder Größe der Tabellen |
|
|
Zeilen und Spalten pro Tabelle |
kein Limit für die Anzahl der Datensätze |
|
|
Datensatzgröße |
maximal 8 KByte |
|
|
Datentypen (aktuell) |
|
|
|
Datentypen (in Zukunft) |
|
|
|
Import/Export-Format |
CSV mit festgelegtem Trennzeichen |
|
|
Datenbankfunktionen |
Funktionen und Operatoren wie beim MS-SQL-Server |
|
|
Backup |
Full Backup, nicht formatidentisch zu MS-SQL-Server |
|
|
Replikation |
|
derzeit nicht unterstützt |
|
Cluster-Mode |
derzeit nicht unterstützt |
|
|
Transaktionssicherheit |
ja (Rollback beim Neustart des DBS) |
|
|
Mehrbenutzerbetrieb |
ja |
RSQL benutzen
Als Grundvoraussetzungen für den Einsatz benötigt RSQL ein 64-Bit-System, wobei es sich mit 100 MByte RAM sowie 100 MByte Speicherplatz auf dem Datenträger begnügt. Die Bedienung erfordert ein Basiswissen zu SQL und dessen Schreibweisen. Installationshinweise liegen in Varianten für einen schnellen Einstieg und für ein komplettes Client-Server-System vor.
Derzeit gibt es RSQL noch nicht in paketierter Form. Das Archiv der aktuellen Version 0.7.1 enthält Server und Client in Form eines bereits übersetzten Go-Files. Abhängigkeiten zu anderer Software bestehen nicht. Beim Entpacken des Archivs entsteht der Ordner rsql/bin/ mit den beiden Binaries (Listing 1, Zeile 1). Um sich Tipparbeit zu ersparen, benennen Sie Server und Client um (Zeile 2 und 3).
Listing 1
$ tar -xzf rsql-0_7_1-linux_amd64.tgz $ mv rsql/bin/rsql_server-0_7_1-linux_amd64 rsql/bin/rsql_server $ mv rsql/bin/rcli-0_7_1-linux_amd64 rsql/bin/rcli $ ls rsql/bin/ rsql_server rcli
Im nächsten Schritt legen Sie ein Projektverzeichnis an, hier schlicht rsql-test/ genannt (Listing 2; Zeile 1). Darin initialisieren Sie das DBS (Zeile 2). Ersetzen Sie dabei im Aufruf /home/User/ durch den Namen Ihres Heimatverzeichnisses, und passen Sie die gewünschte Lokalisierung an. Abbildung 1 zeigt im rechten Terminalfenster die Strukturen, die bei diesem Schritt entstehen. Nun starten Sie den RSQL-Server über die Kommandozeile (Zeile 3).
Listing 2
$ mkdir rsql-test $ ./rsql/bin/rsql_server -install -dir=/home/User/rsql-test -server_default_collation=en_ci_ai -server_default_language=en_us $ ./rsql/bin/rsql_server -dir=/home/User/rsql-test
Abbildung 1: RSQL im Einsatz. Im Hintergrund läuft der Server bereits, das Testverzeichnis (rechts) enthält die benötigten Strukturen.
Der Server läuft nun im Hintergrund. Sie stoppen ihn bei Bedarf jederzeit mittels [Strg]+[C]. Sofern Sie nichts anderes eingestellt haben, lauscht RSQL auf Port 7777. Starten Sie den RSQL-Client, verbindet er sich über diesen Port automatisch mit dem Server-Prozess. In einem weiteren Terminal senden Sie nun vom Client aus eine Anfrage an den RSQL-Server (Listing 3, erste Zeile).
Listing 3
$ ./rsql/bin/rcli -U=sa -P=changeme -Q="print 'hello, world';" $ ./rsql/bin/rcli -config_model > ~/rcli.conf $ ./rcli -d Datenbank batch.sql
Im Aufruf erfolgt die Verbindung als (bereits bestehender) Benutzer sa (Schalter -U) mit zugehörigem Passwort (Schalter -P) und dem auszuführenden Kommando (“query”, Schalter -Q), das im Beispiel die Zeichenkette “hello, world” ausgibt (Abbildung 2). Bei dieser Form des Aufrufs landen allerdings die Authentifizierungsdaten in der Historie der Shell – das ist unschön. Deswegen befördern Sie diese mit dem Aufruf in der zweiten Zeile von Listing 3 in eine Konfigurationsdatei.
Abbildung 2: Ein “hello, world” als Datenbank-Query via RSQL.
Analog zu Listing 3 übermitteln Sie entsprechende SQL-Kommandos, um in der Datenbank Tabellen anzulegen, diese mit Inhalten zu befüllen und die Inhalte abzufragen. Abbildung 3 zeigt anhand eines kleinen Telefonbuchs, wie RSQL damit umgeht. Der Schalter -d spezifiziert hierbei die verwendete Datenbank.
Abbildung 3: Verknüpfung zweier Tabellen mittels JOIN.
Dokumentation
Auf der Webseite des Projekts finden Sie ein Tutorial zum Erlernen des Umgangs mit der Software sowie eine Übersicht zu den Datenbankkommandos, Operatoren und Funktionen. Über eine Manpage verfügt RSQL noch nicht, zumindest aber über eine integrierte Hilfe zu den einzelnen Schaltern. Dokumentiert sind nur Schalter der Kurzform -s, erlaubt ist aber auch die auf Unix-Systemen gebräuchlichere Variante --schalter.
Auf der Projektwebseite stehen außerdem vorgefertigte Datenbankinhalte bereit, die die Leistungsfähigkeit von RSQL eindrucksvoll demonstrieren. Es lohnt sich, das auszuprobieren.
Bislang besitzt RSQL weder eine Datenbank-Konsole wie MySQL und PostgreSQL, noch gibt es ein grafisches Frontend. Alle Ausgaben erfolgen im Terminal. Möchten Sie dabei nicht jede Abfrage einzeln eintippen, sondern alle in einem Stapel übermitteln, dann schreiben Sie diese in eine Textdatei und geben diese RSQL beim Aufruf mit (Listing 3, letzte Zeile).
Fazit
Im Einzelkämpfer-Modus hat Nicolas Riesch mit RSQL eine bemerkenswerte Leistung vorgelegt. Laut seiner Angaben liegt die Ausführungsgeschwindigkeit seines MS-SQL-Klons etwas unter jener des Originals, die generelle Leistung genügt jedoch für die meisten Anwendungsfälle vollauf. Unsere Tests bestätigen das, sodass wir Ihnen RSQL als freie Alternative zu MS-SQL empfehlen können. Das DBS reifte lange im Verborgenen und hat noch Grate, die Riesch noch nachschleifen muss. Die Software erweist sich aber jetzt schon als alltagstauglich.
Nicolas Riesch im Interview
LinuxUser: Warum entwickelst du ein eigenes DBS?
Nicolas Riesch: Ich arbeite seit über 15 Jahren mit MS-SQL-Server und mag das Produkt. Die Lizenzkosten fallen aber exorbitant aus, beispielsweise 14?400 US-Dollar für die Installation auf einer Achtkern-Maschine, deren Hardware lediglich 3000 Dollar kostet. Je leistungsstärker die Maschine, desto teurer die Lizenz, da deren Kosten sich proportional zur Anzahl Kerne verhalten. In der Praxis muss man stets unbefriedigende Abwägungen zwischen den Lizenzkosten und der Leistung der Hardware machen. Daher war es mein Traum, einen MS-SQL-Klon zu schreiben, den ich auf jeder Maschine ohne jegliche Begrenzung installieren kann. Nach einer Menge Forschung zu den internen Mechanismen eines Datenbankservers war ich in der Lage, meine eigene Implementation zu schreiben.
LU: Die Wahl fiel auf die Programmiersprache Go. War das im Rückblick eine gute Entscheidung?
NR: Ursprünglich habe ich RSQL in C entwickelt. Als ich aber von Go hörte, entschied ich mich für einen Wechsel. Go wurde von berühmten Entwicklern wie Rob Pike oder Ken Thompson entworfen, es handelt sich praktisch um den Nachfolger von C und C++. Es bietet eine einfache, aber mächtige Syntax, wird übersetzt und hat einen Garbage Collector. Es erleichtert die nebenläufige Programmierung und das Schreiben von Threads. Es war ursprünglich dazu gedacht, Server-Software effizienter zu schreiben, eignet sich aber für vielfältige Programmieraufgaben. Es macht Spaß, in Go zu programmieren.
LU: Welchen Designprinzipien folgt RSQL — gibt es Vorbilder?
NR: Meines Wissens gibt es kaum Dokumentation über das interne Design von Datenbank-Servern – da muss man sich selbst schlau machen. Andererseits eröffnet das die Möglichkeit, selbst optimale Lösungen zu finden, ohne vorgegebenen Ideen zu folgen. Als Erstes muss man einen Compiler schreiben, der SQL-Text in Bytecode parst, der dann in einer virtuellen Maschine läuft. Die VM ist mehr oder weniger nur eine gigantische Switch-Anweisung innerhalb einer Schleife; alles wird um den Compiler als zentralen Teil der Software herumgebaut.
LU: Was soll RSQL leisten, was nicht? Welchen Einsatzrahmen stellst du dir vor?
NR: RSQL ist ein Ersatzprodukt, hauptsächlich gedacht für Entwickler auf der Microsoft-Plattform, die den MS-SQL-Server bereits kennen und in C# entwickeln. Ihnen bietet es die Möglichkeit, eine Menge Lizenzkosten zur sparen. Dabei besteht keine Lernkurve, da RSQL Transact-SQL implementiert, den SQL-Dialekt des MS-SQL-Servers. RSQL wird als vereinfachter Klon des MS-SQL-Servers nie so komplex sein wie das Originalprodukt. Derzeit bietet es beispielsweise Stored Procedures, noch Views oder andere erweiterte Eigenschaften. In der Praxis fallen allerdings die meisten Anwendungen recht schlicht aus. Wer nur die Anweisungen SELECT, INSERT, UPDATE und DELETE nutzt, wird auch mit RSQL glücklich. Im Zweifelsfall kann man jederzeit zurück zum MS-SQL-Server wechseln – ein SQL-Skript, das mit RSQL läuft, funktioniert auch mit dem MS-SQL-Server. Es gibt auch einen C#-Treiber, der dieselben Methoden implementiert wie der Treiber des Originals.
LU: In RSQL stecken bislang fünf Jahre Entwicklungszeit und 140:*000 Zeilen Programmcode. Hattest du dir das leichter vorgestellt?
NR: Als ich anfing, war ich durchaus auf drei oder vier Jahre Arbeit gefasst. Ich habe dann eine Menge Zeit dazu verwendet, den Code möglichst zu vereinfachen, und viele Teile mehrfach umgeschrieben. Eleganter Programmcode ist leichter zu warten, effizienter und weniger fehleranfällig – aber auch schwieriger und zeitaufwendiger zu schreiben. Datenbank-Server zählen zusammen mit Betriebssystemen und Compilern zu den anspruchsvollsten Formen von Software. Ein Klon erfordert obendrein Mehrarbeit, weil man das Touch & Feel des Originalprodukts imitieren muss. Allein der “Klon”-Teil von RSQL umfasst etwa 50 Prozent des Codes.
LU: Welcher Programmteil hat dir bisher am meisten Kopfzerbrechen bereitet?
NR: Die größten und komplexesten Komponenten von RSQL sind der RSQL-Compiler, der Cache (um Memory-Buffer und Transaktionen zu verarbeiten) sowie der Code zur Verwaltung mittels Btree (um Datensätze aus Dateien zu lesen und zu schreiben). Ich denke immer über das Gesamtdesign nach, das so einfach und elegant wie möglich ausfallen soll. Ich halte Programmierung für eine kreative Kunst mit einem tiefen Sinn von Ästhetik – meiner Meinung nach läuft Code schnell und problemlos, wenn er elegant ist. Wer einen Server schreiben möchte, dem kann ich nur raten, ihn in Go zu implementieren. Dazu sollte man aber auch in C geübt sein, der Mutter aller Programmiersprachen.
LU: Welche Hilfe und Unterstützung benötigt das Projekt? Welche Baustellen gibt es derzeit?
NR: Ich benötige Feedback von Anwendern, die RSQL installieren und ausprobieren. Ich würde gern über deren erste Eindrücke hören und über mögliche Fehler. Im Moment liegt ein Fokus darauf, den Zustand von RSQL zu konsolidieren und alle noch existierenden Kanten abzuschleifen. Bis Jahresende 2017 möchte ich noch die Datentypen IMAGE und TEXT implementieren, sodass man PDFs und Bilder speichern kann. Außerdem fehlen noch Features wie ein Optimierer, der Tabellen in einem FROM-Statement umsortiert. Aber das ist eine Menge Arbeit und kommt erst 2018 an die Reihe.
LU: Vielen Dank für das Interview!
Danksagung
Die Autoren bedanken sich für die vielen Detailinformationen und Geduld bei Nicolas Riesch und Werner Staub.
Über die Autoren
Frank Hofmann arbeitet von unterwegs – bevorzugt in Berlin, Genf und Kapstadt – als Entwickler, Trainer und Autor. Er ist Koautor des Debian-Paketmanagement-Buchs (http://www.dpmb.org). Mandy Neumeyer arbeitet im Tourismus, lebt seit neun Jahren in Südafrika, reist gern um die Welt und baut zur Zeit ein zusätzliches Einkommen als digitaler Nomade auf. Der gebürtige Kanadier Gerold Rupprecht wohnt seit 25 Jahren in Genf und hat sich auf Finanzsoftware sowie die Evaluierung und Optimierung von IT-Prozessabläufen spezialisiert. Er unterstützt seit 2000 das GNUstep-Projekt. Dieser Beitrag entstand als Kooperation in Berlin, Genf und Kapstadt.
Infos
-
RSQL: http://rsql.ch
-
Transact-SQL: https://docs.microsoft.com/de-de/sql/t-sql/language-reference
-
Transact-SQL (Wikipedia): https://de.wikipedia.org/wiki/Transact-SQL
-
Libdbi: http://libdbi.sourceforge.net
-
RSQL-Treiber: http://github.com/rin01/Rsqldrv
