[gnucash-de] Multi-User ( Datenbankanbindung und Performance)

Do Jan 19 15:25:39 EST 2017

Hallo Andreas,

also wenn die Frage nun explizit nach Multi-User-Fähigkeit ist: Nein, die ist 
leider weiterhin nicht in naher Zukunft zu erwarten.

Wenn jemand dieses Feature ernsthaft haben will, wäre mein Ratschlag 
folgender: Die SQL-Datenbank von Gnucash ist durchaus ein sinnvolles Format 
für die Daten, um die es geht. Aber der Datenbankzugriff von der Gnucash-
Applikation aus ist auf allen Programmcode-Ebenen leider weiterhin völlig 
ungeeignet für einen Multi-User-Zugriff. Ich würde daher vorschlagen, dass man 
ein neues GUI-Programm beginnt, welches auf die Datenbank zugreift, aber den 
Datenbankzugriff selber dabei völlig neu programmiert und dabei die Multi-
User-Fähigkeit auch von vorneherein einplant. Im Sinne einer agilen 
Vorgehensweise sollte es auch durchaus möglich sein ("minimum viable 
product"), relativ schnell eine GUI-Applikation hinzubekommen, die die 
Buchungen und den Saldo eines gewünschten Kontos anzeigt und die Eingabe neuer 
Buchungen erlaubt - und dabei für Multi-User-Zugriff dann parallele Änderungen 
in der Datenbank korrekt berücksichtigt. Gleichzeitig könnte man alternierend 
das bisherige Gnucash in vollem Feature-Umfang nutzen, wenn man vorhandene 
Features nutzen will, nur dann eben ohne Multi-User-Zugriff. (Das 
entsprechende Locking in der DB wird ja durchaus gesetzt, wenn gnucash 
gestartet wird.) Auf diese Weise könnte man mit einem kleinen neuen Projekt 
starten, welches Multi-User hat, und dann schrittweise weitere Entwickler 
hinzugewinnen und Features ergänzen.

Aber für den ersten Schritt müsste schon jemand ca. 2-4 Wochen investieren. 
Ich selber habe dafür zu wenig Anreiz und werde das nicht machen. Aber wenn 
das jemand will, wäre das durchaus eine Möglichkeit. Ich würde das auch gerne 
mit Rat&Tat, naja eher Rat, unterstützen.

Solange das aber niemand anpackt, gibt es auch aus meiner Sicht weiterhin 
eigentlich keinen Vorteil von SQL gegenüber XML und Umstieg auf XML wäre wohl 
sinnvoll.

Gruß
Christian

Am Montag, 16. Januar 2017, 01:14:35 schrieb Andreas Seidel:
> Hallo Christian,
> 
> vielen Dank für Deine ehrliche und schnelle Antwort.
> Sowas hatte ich mir bereits gedacht.
> Mein SQL-Server ist auf meinem Home-Server. Somit ohne SSH-Tunel.
> (Siehe Eingangsthread).
> Die Ladezeit am Anfang hält sich eigentlich noch in Grenzen.
> Dass GnuCash die Datenbank voll in den Speicher nimmt, erklärt, warum
> Buchungen sehr schnell funktionieren.
> Ich verstehe, dass die Datenbankanbindung keine Prio hat, solange noch
> kein Multi-User-Zugriff möglich ist. Das wäre ja eigentlich der
> wichtigste Grund für eine Auslagerung auf einen Server. Ist die
> Implementierung denn prinzipiell geplant? Ansonsten würde ich nämlich
> auch wieder auf die XML-Datei zurückstellen.
> 
> Grüße,
> Andreas
> 
> Am Sonntag, den 15.01.2017, 22:33 +0100 schrieb Christian Stimming:
> > Hallo Andreas,
> > 
> > mit der Datenhaltung in einer SQL-Datenbank habe ich mal kurz
> > experimentiert, 
> > benutze in der täglichen Arbeit aber weiterhin nur die XML-Datei. 
> > 
> > Ist das hier eine Datenbank auf localhost oder ist die woanders, auf
> > einem 
> > anderen Rechner im lokalen Netz oder mit etwas mehr Verzögerung
> > irgendwo im 
> > Internet (über SSH-Tunnel hoffentlich)? Ich hatte mal einen Server
> > woanders 
> > via SSH-Tunnel versucht und bin dann bei der Ladezeit beim
> > Programmstart von 
> > Gnucash vom Glauben abgefallen (wenn auch 1-2 Berichte ausgewertet
> > werden) - 
> > das dauerte mir definitiv viel zu lange. Von daher war mein
> > Zwischenstand, 
> > dass eine etwas größere Datei (200 Konten, 30.000 Transactions / 
> > Buchungssätze) für SQL nicht geeignet ist, außer vielleicht auf
> > localhost.
> > 
> > Die Verzögerungen bei den Import-Zuordnungen sind natürlich
> > ärgerlich. Das ist 
> > schlecht programmiert, eben für den Use Case SQL-Datenbank.
> > Eigentlich sollte 
> > es machbar sein, dies besser hinzukriegen - aber ich müsste dafür 4
> > Stunden am 
> > Code sitzen, und dafür hab ich a) nicht die Zeit, b) nicht die Lust,
> > und c) 
> > nicht selber den Leidensdruck, es machen zu müssen... sorry, das ist
> > die 
> > ehrhliche Einschätzung.
> > 
> > Ein Multi-User-Zugriff auf die SQL-Datenbank ist nicht (!) möglich!
> > Das würde 
> > nur abwechselnd gehen. Grund: Gnucash benutzt dummerweise das SQL
> > teilweise 
> > noch immer wie eine Datei, d.h. die Kontenstruktur wird beim
> > Programmstart 
> > geladen und im Speicher gehalten. Es wird zwar kontinuierlich
> > gespeichert, 
> > aber es wird eben nicht kontinuierlich geladen, d.h. eine zweite
> > Programm-
> > Instanz bekommt die Änderungen nicht mit, die von einer ersten
> > Programm-
> > Instanz gespeichert worden wären. Aus diesem Grund bekommt man
> > (hoffentlich) 
> > auch eine Fehlermeldung, wenn ein zweiter User auf die SQL-Datenbank
> > zugreift, 
> > solange noch ein erster User drin ist.
> > 
> > Da ist gnucash also leider weiterhin noch lange kein Multi-User-
> > Programm. 
> > Sorry.
> > 
> > Gruß
> > 
> > Christian
> > 
> > Am Sonntag, 15. Januar 2017, 15:27:48 schrieb Andreas Seidel:
> > > Hallo Zusammen,
> > > 
> > > schade, dass es in der Mailingliste bisher keine Antwort zu dem
> > > Thema
> > > SQL-Anbindung gibt. Ich habe in der Zwischenzeit folgende
> > > Beobachtung
> > > machen können:
> > > 
> > > 1. Eine einfache Buchung in GnuCash benötigt kaum Server-
> > > Performance.
> > > Das funktioniert sehr gut. Man muss nicht mehr speichern, da das
> > > die
> > > Datenbank bei jeder Buchung automatisch tut.
> > > 2. Die "Abfrage der Kontoumsätze" per HBCI benötigt ungefähr die
> > > gleiche Zeit, wie vorher.
> > > 3. Bei einer "Saldenabfrage" per HBCI entstehen keine zusätzlichen
> > > Zeitverzüge.
> > > 4. Während der Anpassung der Kontobuchungen aus "Abfrage der
> > > Kontoumsätze" mit der eigenen Datenbank entstehen wesentliche
> > > Verzögerungen während einer Umbuchung. z.B. hat GnuCash eine
> > > Buchung
> > > Konto A zugewiesen. Ich möchte, dass die Buchung auf Konto B
> > > gebucht
> > > wird. Sobald ich das neue Konto ausgewählt habe, vergehen für diese
> > > Umbuchung ca. 1 Minute.
> > > 5. Wenn ich "Abfrage der Kontoumsätze" abschließe, werden alle
> > > Buchung
> > > in die Datenbank übernommen. Hier kann ich abhängig von der Anzahl
> > > der
> > > neuen Buchungen zwischen 5 und 15 Minuten warten, bis ich GnuCash
> > > wieder benutzen kann.
> > > 
> > > Ein Workaround ist aktuell, dass ich Umbuchungen erst nach dem
> > > Abschluss Eingabemaske "Abfrage der Kontoumsätze" durchführe. Aber
> > > das
> > > ist ja eigentlich nicht so gewollt und auch unübersichtlich. Ich
> > > weiß
> > > auch nicht, ob die KI von GnuCash sich dann falsche
> > > Buchungszuordnungen
> > > einübt.
> > > Serverseitig habe ich folgende Optimierungen versucht:
> > > Anpassen der Speicherbelegung durch Postgresql in
> > > /etc/postgresql/8.4/main/postgesql.conf
> > > 
> > > #----------------------------------------------------------------
> > > ----
> > > ----------
> > > # RESOURCE USAGE (except WAL)
> > > #----------------------------------------------------------------
> > > ----
> > > ----------
> > > 
> > > # - Memory -
> > > 
> > > shared_buffers = 112MB                  # min 128kB
> > >                                         # (change requires restart)
> > > temp_buffers = 8MB                      # min 800kB
> > > max_prepared_transactions = 0           # zero disables the feature
> > >                                         # (change requires restart)
> > > #
> > > 
> > > Evtl. kann man da auch noch mehr Performance rausholen, in dem man
> > > Write ahead oder files per process anhebt.
> > > Hier erhoffe ich mir mehr Input aus Eurer Erfahrung.
> > > 
> > > Des Weiteren würde ich gerne mehrere Nutzer auf die Datenbank
> > > zugreifen
> > > lassen und auch deren Aktivität loggen. Wie kann ich Benutzern
> > > Zugriff
> > > auf die Datenbank gewähren?
> > > 
> > > Ich hoffe, jemand kann mir hierzu irgendetwas schreiben.
> > > Vielen Dank im Voraus,
> > > 
> > > Andreas
> > > 
> > > Am Freitag, den 30.12.2016, 12:22 +0100 schrieb Andreas Seidel:
> > > > Hallo Zusammen,
> > > > 
> > > > Zunächst wünsche ich der Mailingliste einen erfolgreichen Start
> > > > in
> > > > das
> > > > neue Jahr 2017. Auf dass GnuCash in diesem Jahr wieder einen
> > > > guten
> > > > Sprung voran macht.
> > > > 
> > > > Ich benutze GnuCash 2.6.12 auf einem Ubuntu 16.04 LTS Rechner mit
> > > > einer
> > > > Datenbankanbindung an eine PostgreSQL-Datenbank 8.4 auf einem
> > > > Server
> > > > mit Ubuntu 12.04.5 LTS Server.
> > > > Ich weiß, die Datenbank und der Server sind nicht mehr aktuell.
> > > > Trotzdem war ich erstaunt, wie leicht auf die Datenbank
> > > > umzustellen
> > > > war.
> > > > Nun ist mein Server auch nicht mehr der neueste Rechner. Mit
> > > > einem
> > > > Pentium 4 2,66GHz erledigt er aber bisher meine Ansprüche ganz
> > > > ordentlich. Nur bei GnuCash habe ich jetzt ein echtes
> > > > Performance-
> > > > Problem. Dadurch, dass ich direkt mit der Datenbank verbunden
> > > > bin,
> > > > benötige ich für jede neue Buchung ca. 1 Minute.
> > > > Wenn ich Online meine Kontoumsätze abrufe, kann das dann schon
> > > > eine
> > > > Weile dauern. Gibt es Tricks, um die Performance für den Benutzer
> > > > zu
> > > > erhöhen? Evtl. einen Buchungs-Cache, der erst bei Beendigung von
> > > > GnuCash ausgeführt wird? Oder vielleicht eine Einstellung auf dem
> > > > PostgreSQL-Server? Ich habe gesehen, dass die Datenbank nur 40% -
> > > > 60%
> > > > der CPU auslastet.
> > > > Im schlimmsten Fall muss ich dann doch wieder filebasiert
> > > > arbeiten.
> > > > Da die Vorteile einer Datenbank (Multiuser-fähigkeit) bei GnuCash
> > > > anscheinend noch nicht implementiert sind, gibt es aktuell eh
> > > > keinen
> > > > Grund auf eine Datenbank umzustellen.
> > > > 
> > > > _______________________________________________
> > > > gnucash-de mailing list
> > > > gnucash-de at gnucash.org
> > > > https://lists.gnucash.org/mailman/listinfo/gnucash-de