Java SQLite Datenbank auf Freigabe sinnvoll?

[CPU]

Hallo Community,

ich hoffe Ihr könnt mir bei einem "Entscheidungsproblem" helfen: ich habe eine Anwendung, mit der max. 12 Nutzer arbeiten und üblicherweise Daten eingeben, bearbeiten und ausgeben (1-3 MB Traffic pro Tag/Nutzer würde ich schätzen). Bei den Daten handelt es sich nur um Texte & Zahlen.

Nun habe ich derzeit das ganze Ding mit MySQL laufen. Doch das gefällt mir nicht, weil (1) MySQL in diesem Fall etwas unhandlich ist (Installation, Backup & Wartung) für DIESEN Fall und (2) mir die gesamte Geschichte schon mehrmals vor die Füße gefallen ist, weil die Benutzergeschichte so komplex ist und nicht mit meinem einfachen "Rechtesystem" klar kommt (jeder kann auf die Datenbank komplett zugreifen).

Daher habe ich mir mal den SQL-Jet angeschaut und festgestellt, dass der garnicht so schlecht ausschaut. Meine Benutzerprobleme wäre ich los und alles Andere ist auch total easy. Man würde nur noch die Anwendung + Datenbankdatei auf die Freigabe legen und jeder könnte damit bequem arbeiten.

Auf der Arbeit haben wir auch soetwas: mit Microsoft Acces eine "Frontend"-Datei und die Datenbank. Das klappt auch ganz gut!

Nun steht aber hier:

If you have many client programs accessing a common database over a network, you should consider using a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, the file locking logic of many network filesystems implementation contains bugs (on both Unix and Windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same database at the same time, resulting in database corruption.[...]

Nun inwieweit ist jetzt die Performance schlecht, bei einem 100 Mbit/s Netzwerk mit max. 12 Teilnehmern?

Und was bedeutet, dass das Dateisystem die Datenbank kaputt macht? Und kann man das durch regelmäßiges Sichern der Datei umgehen?

Also auf der Arbeit ist besagte Acces-Datenbank auch ein mal im Jahr kaputt gegangen. Aber wir hatten immer ein Backup. Und seit dem Umzug von einem Novell 5 Server auf einen Windows Server ist nichts mehr kaputt gegangen. :-)

Nun zur Erklärung: die Lösung mit der SQLite-Datenbank wäre wesentlich besser für meinen Fall, denn ich kann etwas wesentlich kompakteres mit minimalen Anforderungen (nur Netzwerkfreigabe) bereitstellen, was in diesem Fall durchaus wichtig ist! Dennoch, sollte es nicht sein, dass alle 2 Tage die Datei kaputt ist!

Danke für's zuhören & antworten (hoffentlich)!

Gruß,
CPU

 

[HighTech-Freak]

Also ich bin jetzt kein Datenbankspezialist, aber dass die SQLite-Datei beschädigt wird, geschieht nur dann, wenn mehrere Clients (also Frontends*, wenn man's so haben will) auf die gleiche SQLite Datei schreibend zugreifen (-was normalerweise das Dateisystem verhindern sollte). So ein Setup ansich ist aber schon ein fettes NoGo. SQLite file auf einem Network-Share ist absolut unproblematisch. Die Latency ist absolut vernachlässigbar im LAN...

MfG, Thomas

*Beschriebens Szenario in deinem Quote:
Frontend 1 (PHP) => SQL-Server 1 => Datenbankdatei
Frontend 2 (Gameserver) => SQL-Server 2 => Datenbankdatei
In dem Fall greifen zwei Server auf das gleiche File zu. Das kann nicht gut gehen...
Es wird allerdings bei SQLite öfters mal (fälschlicherweiße) gemacht, da der SQL-Server embedded ist in der Anwendung, der User oft nur den Pfad zur SQLite-Datei angeben muss.
Korrekterweiße müsste in so einem Fall aber ein zentraler "richtiger" SQL-Server installiert werden, damit das ganze so aussieht:
Frontend 1 (PHP) => SQL-Server 1 => Datenbankdatei
Frontend 2 (Gameserver) => SQL-Server 1 => Datenbankdatei
Aber ich schätz mal Du hast da einfach zu kompliziert gedacht... ^^

 

[CPU]

Hey,

Aber ich schätz mal Du hast da einfach zu kompliziert gedacht... ^^

Also bisher läuft auf dem Server ein MySQL-Server und die Clients verbinden sich eben über JDBC an den Server.

Nun will ich die Datenbank aber auf ein Share auslagern, d.h. Datenbankdatei und Programm liegen in ein einem Ordner. Jeder Nutzer startet das Programm dann von hier und bearbeitet die Daten in der Datenbankdatei. Klar ist es dann so, dass mehrere Leute mit der gleichen Datenbankdatei arbeiten.

Für meinen Fall wäre das wesentlich besser zu realisieren, denn z.B. folgendes Szenario: stell Dir vor, es arbeiten nur Leute mit diesem Programm, die gerade mal den Windows Explorer bedienen können. Wenn der MySQL-Server abschmiert sind die aufgeschmissen. Aber wenn das "System" (Datenbank + Programm) aus zwei Dateien besteht, dann können die einfach die Dateien kopieren und wenn das System oder die Datenbank crashed dann können sie einfach die alte Kopie an den selben Ort kopieren und alles läuft wieder. Und das ist ein Faktor, der nicht unterschätzt werden sollte!

Gruß,
mythbu

P.S.: Jetzt hat mir jemand H2 (http://www.h2database.com) empfohlen. Und das steht "Multi Version Concurrency". Heißt das, dass mehrere Benutzer damit gleichzeitig arbeiten können?

 

[HighTech-Freak]

Jeder Nutzer startet das Programm dann von hier und bearbeitet die Daten in der Datenbankdatei. Klar ist es dann so, dass mehrere Leute mit der gleichen Datenbankdatei arbeiten.

Das ist auch kein Problem, solange das nicht gleichzeitig passiert. Ich weiß nicht wie dein SQLite-"Server" arbeitet, aber oft ist es so, dass das SQLite File während die Datenbank von einem SQLite "Server" geöffnet ist, somit kein Schreibzugriff möglich ist. Damit kriegt dann ein anderer User, eine Fehlermeldung, wenn er das SQLite file benutzen will. Musst Du ausprobieren...
Wenn dein "Server" das SQLite File hingegen einliest und nur kurz beim Schreiben lockt, dann ergibt sich ein anderes Problem: Sie werden während der Bearbeitung vlt. von einem anderen User verändert, was dann überschrieben wird, je nach Anwendung könnte das die Integrität der Datenbank gefärden. Wenn das eine reine Kunden-Datenbank oder so sein soll, ist das egal, aber wenn das Anwendungsparameter sind, die da gespeichert werden, würde ich das auf keine Fall so lösen.

Du solltest in der Anwendung nur sicherstellen, dass das File nicht von zwei Usern gleichzeitig benutzt wird, sprich die Anwendung nicht von zwei Usern gleichzeitig gelaunched werden kann. Das könnte man über ein TXT-File lösen, dass die Anwendung schreibt, sobal sie gestartet wird. In das TXT-File kommt alle 5 Minuten der aktuelle Timestamp. Beim Schließen wird das TXT-File gelöscht. Wenn die Anwendung gestart wird prüft sie ob so ein File existiert und ob die Zeit darin nicht älter als 6 Minuten ist. Sollte eines von beiden zutreffend sein, erscheint die Fehlermeldung, dass gerade ein anderer User aktiv ist und das SQLite File wird garnicht erst versucht zu öffnen. Falls bei irgendwem die Anwendung abschmiert, ist so sichergestellt, dass nach spätestens 6 Minuten weitergearbeitet werden kann.

Falls das File tatsächlich beabsichtigt von mehreren Anwendern gleichzeitig geöffnet sein soll -was uU oben genannte Risiken mit sich bringt- geht das zwar mit SQLite sehr wohl, aber schreibend kann immer nur ein User zugreifen, was bei wenigen Schreibzugriffen kein Problem sein sollte: http://www.sqlite.org/faq.html#q5, saubere Lösung ist es aber mMn keine...

Allerdings würde mich interessieren, was genau das Problem mit dem (My)SQL-Server ist... Is ja nicht so, dass der nicht perfekt stabil laufen würde auf abertausenden Servern weltweit...

MfG, Thomas

als "Server" versteht sich die in die Anwendung eingebettete SQLite Instanz

 

[CPU]

Hey,

nun, ich finde es sehr schade, dass ich diese Idee verwerfen muss. Denn es ist wirklich ideal, wenn man die Anforderung an minimale Wartung & Backupmöglichkeit sucht - nur eine Datenbankdatei zugänglich für jeden auf der Freigabe. Dennoch ist das mit gleichzeitig lesen und schreiben ein Problem. Und das mit der Integrität der Daten sehe ich ein ...

Allerdings würde mich interessieren, was genau das Problem mit dem (My)SQL-Server ist...

Die "Architektur": Java-Anwendung bei den Clients und MySQL-Server. Die Benutzer werden als MySQL-Benutzer angelegt und existieren nochmal in meiner Datenbank um Zuordnungen zu ermöglichen (d.h. einem Auftrag in der Datenbank die ID des Bearbeiters zuordnen). Zusätzlich gibt es zwei Berechtigungsstufen: Admin (Benutzer hinzufügen + Datenbank ansehen & verändern) und Nutzer (Datenbank ansehen & verändern).

Probleme:
* Benutzer existieren in zwei Tabellen (mysql.user für die Authentifizierung gegenüber MySQL mit JDBC __UND__ meindatenbank.user) und müssen somit auch an zwei Orten synchron gehalten werden
* Rechte setzen der Nutzer (mit GRANT und REVOKE) schlägt regelmäßig fehl

Schön wäre es jetzt die Nutzer in nur einer Tabelle zu haben und den Krampf mit den Rechten los zu werden!

Is ja nicht so, dass der nicht perfekt stabil laufen würde auf abertausenden Servern weltweit...

Ich habe nicht behauptet, dass MySQL schlecht oder nicht perfekt oder instabil ist. Ich habe nur gesagt, dass es für meinen aktuellen Anwendungsfall total overkill ist.

Gruß,
CPU

 

[AlbertLast]

machst halt auf "meindatenbank.user" ein paar trigger der die system user anpasst.
Ka ob es in mysql geht, in pg ginge es: http://archives.postgresql.org/pgsql-sql/2005-04/msg00273.php