Herausforderung kostenlose Datenbank

„Wir brauchen eine kostenlose Datenbank für unsere neue dot4-Discovery!“ Mit dieser Anforderung war es vorbei mit der gewohnten MSSQL-Server-Umgebung, mit der wir über Jahre hinweg Erfahrung gesammelt hatten. Eine neue Herausforderung für mein Team und mich lag vor uns.

Die Auswahl an kostenlosen SQL-Datenbanken war überschaubar, aber um eine Entscheidung zu treffen, brauchten wir weitere Kriterien. Folgende wurden definiert:

– Entity-Framework-Unterstützung

– einfache Installation

– möglichst großer Funktionsumfang

Damit reduzierte sich die Auswahl stark, und wir zogen schnell SQLite und SQL Server Compact 4.0 näher in Betracht. Aufgrund des größeren Funktionsumfangs, wie z. B. die Unterstützung von Sichten (virtuelle Datentabellen, die Daten aus mehreren Datentabellen aufbereiten; engl. ‚views‘), fiel die Entscheidung auf SQLite.

Bei SQLite handelt es sich um eine freie Datenbank, die einen großen Teil des SQL-Standards enthält. Zudem muss beim Kunden nichts installiert werden, da sie keine Client-Server-Architektur verwendet, sondern aus einer oder mehreren Dateien besteht. SQLite findet bereits in vielen Applikationen Verwendung – vor allem bei mobilen Apps für Android und iOS ist sie nicht mehr wegzudenken. Doch man muss bei SQLite auch mit mehreren Einschränkungen leben, die wir zum Teil sehr früh, zum Teil aber auch erst später im Entwicklungsprozess erkannten. Auf diese Einschränkungen möchte ich im Folgenden näher eingehen.

Die wohl größte Einschränkung ist die fehlende Multithread-Unterstützung. Daraus ergeben sich im Entwicklungsprozess neue Herausforderungen: Die SQL-Abfragen müssen kleiner werden, um ein unnötiges Blockieren zu vermeiden. Um diese Beschränkung zu umgehen, sollte man über eine sinnvolle Aufteilung der Datenbank in mehrere SQLite-Dateien nachdenken. Darauf waren wir eingestellt. Zwei weitere Einschränkungen – oder sollte man eher von ungewöhnlichem Verhalten sprechen – trafen uns hingegen völlig unerwartet. Da diese zudem auch nur schwer identifizierbar waren, mussten wir viel Zeit und Nerven aufwenden, um diese zu ermitteln.

Das erste ‚ungewöhnliche Verhalten‘ von SQLite ist ein Problem, das schreibgeschützte SQLite-Dateien betrifft: Da wir unter anderem SQLite-Dateien hatten, in denen nichts geändert werden sollte, haben wir uns entschlossen, diese mit einem Schreibschutz zu versehen. Als unsere Applikation extrem träge und langsam wurde, gingen wir nicht davon aus, dass dies mit dem Schreibschutz zu tun haben könnte. Wir überlegten und überlegten, aber erst durch einen Zufall kam uns letztlich der Gedanke, es mal ohne Schreibschutz zu versuchen. Danach lief alles wieder gewohnt schnell – und wir waren um eine Erfahrung reicher.

Das zweite ungewöhnliche Verhalten hielt uns dann um einiges länger auf: Um Daten besser und schneller aufzubereiten, hatten wir uns für den Einsatz von Sichten entschieden. Alles funktionierte auch wunderbar – vorerst zumindest. Bei unseren ersten Massentests ließ das Problem jedoch nicht lange auf sich warten: „Out of Memory“-Exception, sprich kein freier Arbeitsspeicher, und die Applikation brach ab. Während der Tests konnte man gut sehen, wie der Arbeitsspeicher immer weiter anstieg, bis für eine 32-Bit-Anwendung nichts mehr da war. Daher war natürlich unsere erste Maßnahme die Umstellung auf 64 Bit. Natürlich kein Problem, aber damit hatten wir zwar die Auswirkung unterdrückt, aber nicht die Ursache behoben, denn so viele Daten beinhalteten unsere Massentests auch wieder nicht. Also machten wir uns auf die Suche nach Speicherlecks. Glücklicherweise bietet das Visual Studio diesbezüglich gute Möglichkeiten, die uns relativ schnell den Verursacher präsentierten: die SQLite-Anbindung über das Entity Framework. Doch leider wussten wir noch immer nicht, wo genau das Problem lag. Unser Verdacht fiel auf die Speicherverwaltung, aber wir konnten keinen direkten Zusammenhang erkennen. Sehr lange wurde gesucht, getestet, geändert, unter anderem auch die Erzeugung und Verwendung der Sichten deaktiviert, alles ohne Erfolg. Fast schon mit unserem Latein am Ende, suchten wir die letzte funktionierende Version über unsere Quellcodeverwaltung – und es kam zu den ersten Überraschungen: Ein und dieselbe Version erzeugte bei unterschiedlichen Personen unterschiedliche Ergebnissen, bei dem einen stieg der Speicher, bei dem anderen nicht. Alle Ergebnisse deuteten aber immer mehr auf ein und dieselbe Ursache: die Sichten. Mit dieser Erkenntnis war das Problem dann schnell gelöst. Es hatte nicht gereicht, die Sichten lediglich aus dem Quellcode zu entfernen, sie mussten zusätzlich auch aus der SQLite-Datei entfernt werden – das alleinige Vorhandensein von Sichten in der SQLite-Datei hatte zu dem Speicheranstieg geführt. Damit war klar, dass wir keine Sichten verwenden konnten. Wir mussten „nur“ noch die entsprechende Umstellung unserer Software durchführen, und auch dieses Problem war Geschichte.

In der weiteren Entwicklung gab es noch ein paar kleinere Probleme, wie zum Beispiel die fehlende automatische Generierung von Datenbanktabellen aus dem Quellcode (Code-First) seitens des Entity Frameworks. Zudem haben wir bis heute keine Möglichkeit gefunden, wie man die SQLite-Datei von der Applikation trennen kann, um unsere nicht änderbaren SQLite-Dateien während der Laufzeit zu aktualisieren, ohne die Applikation zu beenden. Aber dies sind letztlich nur kleinere Einschränkungen, mit denen wir leben müssen und dies auch gut können.

Fazit: Dank meines großartigen und motivierten Teams haben wir es nicht nur geschafft, eine kostenlose SQL-Datenbank bereitzustellen, sondern auch eine Discovery-Lösung zu entwickeln, die keinen Vergleich zu scheuen braucht.

 

Autor: Michael Pach, Entwicklungsleiter

Kontakt: Michael.Pach@dot4.de

 

Netzwerktopologien auf Knopfdruck: Alles über den Information Hub dot4

 

Schreibe einen Kommentar

Your email address will not be published. Required fields are marked *