Größe der configDB

[Prof. Dr. Peter Henning]

Ich benutze nun schon seit langer Zeit die configDB, kann auch darüber nicht meckern.

Allerdings frage ich mich, warum die SQLite-Datei bei gerade mal 18377 config entries und 2548 saved entries sagenhafte 60 MByte groß ist.

Nein, es liegt nicht an fehlenden Re-Organisationen.

Könnte mir mal jemand sagen, wie groß seine SQLite-Datei ist ?

LG

pah

[mahowi]

Meine ist 6,5 MB bei 3686 saved entries.

configdb info:

Code Auswählen Erweitern

-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 12120 2016-09-05 19:06:04Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
-----------------------------------------------------------------
config: 9336 entries

Ver 0 saved: Mon Feb  6 18:51:06 2017 def: 272 attr: 1273
Ver 1 saved: Wed Feb  1 17:42:02 2017 def: 272 attr: 1275
Ver 2 saved: Wed Feb  1 16:57:11 2017 def: 272 attr: 1274
Ver 3 saved: Wed Feb  1 16:53:02 2017 def: 276 attr: 1282
Ver 4 saved: Wed Feb  1 16:50:29 2017 def: 280 attr: 1290
Ver 5 saved: Wed Feb  1 16:42:37 2017 def: 278 attr: 1286
-----------------------------------------------------------------
state: 3686 entries saved: Tue Feb  7 09:09:52 2017
-----------------------------------------------------------------
filesave: 50 files stored in database
-----------------------------------------------------------------

Code Auswählen Erweitern

pi@raspberrypi:~ $ ls -lah /opt/fhem/configDB.db
-rw-r--r-- 1 fhem dialout 6,5M Feb  7 09:10 /opt/fhem/configDB.db

[Benni]

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 12120 2016-09-05 19:06:04Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
-----------------------------------------------------------------
max Versions: 25
config: 150812 entries


Code Auswählen Erweitern


-rw-rw-rw- 1 fhem dialout 200M Feb  7 08:01 configDB.db


[arne.dien]

23 MB bei 15269 entries

Code Auswählen Erweitern

-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 12120 2016-09-05 19:06:04Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
-----------------------------------------------------------------
config: 14992 entries

Ver 0 saved: Tue Feb  7 10:56:07 2017 def: 613 attr: 3138
Ver 1 saved: Wed Jan 25 20:27:41 2017 def: 613 attr: 3134
Ver 2 saved: Wed Jan 25 19:56:14 2017 def: 613 attr: 3134
Ver 3 saved: Wed Jan 25 19:49:04 2017 def: 613 attr: 3130
-----------------------------------------------------------------
state: 15269 entries saved: Tue Feb  7 10:56:00 2017
-----------------------------------------------------------------
filesave: 18 files stored in database
-----------------------------------------------------------------

[Prof. Dr. Peter Henning]

Na sieh mal einer an. Wenn ich die meine dumpe, ist der (ungezippte) dump auch nur 2,5 MByte groß.

Scheint also ein SQLite-Problem zu sein, dass die Datei immer wieder überschrieben wird, aber nicht schrumpft, weil die ganzen gelöschten Entries darinnen behalten werden.

Muss man also manuell machen. In einer Kommandozeile eingeben:

Code Auswählen Erweitern


cd /opt/fhem
cp configDb.db configDB.bak
sqlite3 configDB.db
vacuum;
.quit


Neue configDB.db nur noch 1,8 MByte

LG

pah

Note added in Proof:
Betateilchen, wie wäre es denn, in Deinen Code eine Option zur Bereinigung der Datenbank einzubauen ? Sieht zwar für jede DB anders aus, wäre aber sehr nützlich.

[betateilchen]

Ich benutze nun schon seit langer Zeit die configDB, kann auch darüber nicht meckern.

Sehr vorbildlich 

Vorsicht mit dem Dump! In der configDB liegen ggf. auch Binärdateien, die sich nicht so einfach dumpen lassen.

Muss man also manuell machen. In einer Kommandozeile eingeben:

Man kann das Pragma auto_vacuum auch direkt in der Datenbank setzen, so wie es in der commandref beschrieben steht.

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 12120 2016-09-05 19:06:04Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/sqldb/configDBprodfhem.db
dbtype: SQLITE
-----------------------------------------------------------------
config: 7532 entries

Ver 0 saved: Sun Jan 29 19:22:49 2017 def: 251 attr: 1633
Ver 1 saved: Sun Jan 29 17:13:13 2017 def: 251 attr: 1633
Ver 2 saved: Sun Jan 29 16:28:43 2017 def: 251 attr: 1631
Ver 3 saved: Sun Jan 29 14:46:07 2017 def: 251 attr: 1627
-----------------------------------------------------------------
state: 1918 entries saved: Tue Feb  7 16:00:00 2017
-----------------------------------------------------------------
filesave: 82 files stored in database
-----------------------------------------------------------------


Code Auswählen Erweitern


-rw-r--r--  1 fhem dialout 7,0M Feb  7 16:00 configDBprodfhem.db


Note added in Proof:
Betateilchen, wie wäre es denn, in Deinen Code eine Option zur Bereinigung der Datenbank einzubauen ? Sieht zwar für jede DB anders aus, wäre aber sehr nützlich.

Erübrigt sich, wenn man auto_vacuum gesetzt hat - genau deshalb steht es ja in der Doku.

[betateilchen]

Das ist hier übrigens der falsche Forumbereich für die configDB - nur so am Rande angemerkt.

[Prof. Dr. Peter Henning]

Man kann das Pragma auto_vacuum auch direkt in der Datenbank setzen, so wie es in der commandref beschrieben steht.

Dazu sagt aber sqlite:

An alternative to using the VACUUM command to reclaim space after data has been deleted is auto-vacuum mode, enabled using the auto_vacuum pragma. When auto_vacuum is enabled for a database free pages may be reclaimed after deleting data, causing the file to shrink, without rebuilding the entire database using VACUUM. However, using auto_vacuum can lead to extra database file fragmentation. And auto_vacuum does not compact partially filled pages of the database as VACUUM does.

Das ist hier übrigens der falsche Forumbereich für die configDB - nur so am Rande angemerkt.

Mag sein - dann sollte das aber irgendwo vermerkt sein. Ich hatte nicht die Geduld, länger als 2 Minuten zu suchen, ich gebs ja zu.

LG

pah

[betateilchen]

Mag sein - dann sollte das aber irgendwo vermerkt sein. Ich hatte nicht die Geduld, länger als 2 Minuten zu suchen, ich gebs ja zu.

Das steht - wie für alle anderen (hoffentlich auch Deine) Module - in der MAINTAINER.txt und  muss nicht lange gesucht werden.

Die Diskussion zu auto_vacuum gab es vor einigen Monaten schon einmal mit Rudi. Die Doku zu SQLITE ist da etwas verwirrend und ungenau.
Wenn Du das Komprimieren unbedingt manuell machen willst, habe ich trotzdem noch einen Tipp für Dich:

Das hier:

Code Auswählen Erweitern


sqlite3 configDB.db
vacuum;
.quit


kannst Du auf Betriebssystemebene auch einfach so machen:

Code Auswählen Erweitern


sqlite3 configDB.db vacuum


und läßt sich damit auch völlig simpel per cronjob einplanen.

[Benni]

Und wenn man auto_vacuum verwenden will ist folgende Information wichtig:

auto-vacuuming must be turned on before any tables are created

siehe: https://www.sqlite.org/pragma.html#pragma_auto_vacuum

[n0bbi]

Was spricht eigentlich gegen Autovacuum? Könnte man das nicht im Wiki/Commandref beim Anlegen der DB mit berücksichtigen? (Lässt sich ja nachträglich leider nicht mehr ändern)
Ich habe ein ähnliches Problem bei meiner dblog und das jetzt erstmal mit einem Cronjob gelöst.

[Benni]

Was spricht eigentlich gegen Autovacuum? Könnte man das nicht im Wiki/Commandref beim Anlegen der DB mit berücksichtigen? (Lässt sich ja nachträglich leider nicht mehr ändern)
Ich habe ein ähnliches Problem bei meiner dblog und das jetzt erstmal mit einem Cronjob gelöst.

Doch das geht auch nachträglich, ist halt etwas aufwändiger:
Dump der Db machen -> Leere Db neu anlegen -> auto_vacuum aktivieren -> Dump wieder einspielen

[betateilchen]

Was spricht eigentlich gegen Autovacuum?

Nichts.

Könnte man das nicht im Wiki/Commandref beim Anlegen der DB mit berücksichtigen?

Es steht in der commandref, seit es eine commandref zu configDB gibt.

Create an empty database, e.g. with sqlite3:
   mba:fhem udo$ sqlite3 configDB.db

   SQLite version 3.7.13 2012-07-17 17:46:21
   Enter ".help" for instructions
   Enter SQL statements terminated with a ";"
   sqlite> pragma auto_vacuum=2;
   sqlite> .quit

   mba:fhem udo$
         
The database tables will be created automatically.

[n0bbi]

Ah sorry, nehme alles zurück und behaupte das Gegenteil

Gesendet von meinem Nexus 5X mit Tapatalk

[Amenophis86]

@Betateilchen: Macht es nicht vielleicht auch Sinn, dass du das mit auto_vaccum in deinem Workshop (https://forum.fhem.de/index.php/topic,54055.0.html) einbaust? Da kann ich es nicht sehen.