Anfang
Über
Dortmund
Australien
Fotos
Verweise
Rechner
Geld
Krieg
Gästebuch
Menü verstecken ⇒
⇐ Menü zeigen
This page in English
Letzte Aktualisierung: 2018-12-31

digiKam

di­gi­Kam benutze ich seit 2009 zur Verwaltung meines wachsenden Foto-Schatzes – ein bes­se­res Pro­gramm zu diesem Zweck habe ich noch nicht ge­se­hen! di­gi­Kam ist, ein ech­tes „Open-Sour­ce-Ge­wächs“ und war, als ich es ken­nen­lern­te, noch nicht für Win­dows oder Mac OS (oh­ne X Win­dow Sys­tem) ver­füg­bar. Seit einigen Jah­ren neh­men aber die Mög­lich­kei­ten, viel­leicht auch die Be­reit­schaft, zu, freie Pro­gram­me auch für die­se kom­mer­zi­el­len Sys­te­men an­zu­bie­ten.


digiKam 1.0 unter MacOS 10.5 & KDE 4.3 (2009)

Das Hand­buch mit den Hin­wei­sen zu Di­gi­tal As­set Ma­nage­ment ist eben­falls sehr gut. Die An­wen­dung selbst ist kom­plett auf Deutsch (und an­de­ren Spra­chen) ver­füg­bar, das Hand­buch mo­men­tan lei­der nur auf Eng­lisch.


digiKam 5.9 unter KDE Frameworks 5.50 (2018)

Fotos auf Netzwerkspeichern

Intern verwendet digiKam schon lange MySQL-Datenbanken, um schnelles Suchen und Filtern zu ermöglichen. Spätestens seit 2016, mit digiKam 5.0, kann man recht komfortabel normale/ externe MySQL-Datenbanken verwenden und ungefähr seit der Zeit habe ich auch damit zu experimentieren begonnen. Der Hauptnutzen für mich liegt darin, dass ich damit die Bilder auf einer Netzwerk-Festplatte ablegen und abwechselnd vom Schreibtischrechner (schneller, größerer Monitor) und vom Klapprechner (sofa-tauglich) aus darauf zugreifen kann. Im Dezember 2018 steht vorne auf der digiKam-Homepage selbst eine ausführliche Anleitung Use digiKam with a NAS and MariaDB, die bei der Einrichtung einer solchen Lösung hilft.

Mir war aufgefallen, dass der Zugriff auf Datenbanken im (lokalen) Netz digiKam deutlich ausbremst, vor allem auf meinem lüfterlosen, mit Arch Linux betriebenen ARM-Chromebook, dessen WLAN-Hardware unter „Mainline“-Linux eine deutlich schlechtere Datenrate liefert, als unter ChromeOS (wo aber kein digiKam läuft). Mit etwas Überlegung fand ich allerdings eine zwar etwas komplizierte, aber praktikable Lösung für dieses Problem: digiKam verwendet im Wesentlichen zwei Datenbanken, eine für alle Metadaten zu den Bildern (Bewertungen, Beschriftungen, Stichworte usw.) und eine als Speicher für verkleinerte Vorschaubilder (es gibt noch eine dritte, für Gesichtserkennung, aber diese Funktion verwende ich bisher nicht). Große Datenmengen fallen nur bei den Vorschaubildern an (bei mir ca 500M), nicht bei den Metadaten (mein Datenbank-Dump hat nur 13M). Leider lassen sich die Datenbanken aber nicht unabhängig konfigurieren, sondern es gibt nur eine Einstellung für Benutzer, Passwort und Host (also den Rechner, auf dem die Datenbanken liegen). Zunächst schaute ich mir den digiKam-Quelltext an, um eventuell selbst die Datenbank-Konfiguration aufzuteilen. Dies erwies sich aber als nicht ganz trivial und so werde ich zunächst eine andere Lösung beschreiben, um dann einen Verbesserungsvorschlag an die digiKam-Entwickler zu formulieren, der meine Zwischenlösung überflüssig machen würde. Da sie nur provisorisch ist und ohnehin erweiterte Computer-Kenntnisse sowie vermutlich auch die Lektüre von weiterer englischsprachiger Dokumentation voraussetzt, beschreibe ich meine Lösung nur auf Englisch:

Split digiKam database queries between localhost (thumbnails) and network (metadata)

ProxySQL allows you to redirect a user's SQL queries to different SQL servers, by defining rules that match query patterns. In my digiKam usecase the rules are fairly simple, since all commands involving the thumbnails database dk_thumbnails should be redirected to a local MySQL server, and all calls to the digikam database redirected to the network server.

Still, the setup is time-consuming, and the complexity of at least two databases in two MySQL instances, in addition to the ProxySQL instance, can lead to confusion. I'm using MariaDB from the respective Linux distribution both an the network server (Debian), and on the clients (Ubuntu and Arch). A user for ProxySQL has to be created on all these databases, and given the correct access rights. On the local server:

CREATE USER 'dkproxy'@'localhost' IDENTIFIED BY 'secret_password';
CREATE DATABASE dk_thumbnails;

And on the network server:

CREATE USER 'dkproxy'@'%' IDENTIFIED BY 'secret_password';
CREATE DATABASE digikam;

I then filled the new databases with data I already had from my previous digiKam MySQL setup:

# mysql -p -u root dk_thumbnails < dk_thumbnails.sql
# mysql -p -u root digikam < digikam.sql

Now the dkproxy user needs access rights:

GRANT ALL ON dk_thumbnails.* TO 'dkproxy'@'localhost';
GRANT ALL ON digikam.* TO 'dkproxy'@'%';

I also created my dk_face database on the network server, since I'm not really using it, and it might be worth sharing it.

When configuring ProxySQL I sometimes accidentially logged in to MariaDB instead, or had trouble connecting to ProxySQL. Watch for the correct ports, and use 127.0.0.1 if localhost or hostnames don't work for you (as I experienced).

# mysql -u admin -p -h 127.0.0.1 -P6032 --prompt='Admin> '

Now create the user dkproxy, and the rules for redirecting queries (192.168.1.180 stands for the network server):

INSERT INTO mysql_users(username,password,default_hostgroup) VALUES ('dkproxy','secret_password', 1);
SAVE MYSQL USERS TO DISK; LOAD MYSQL USERS TO RUNTIME;

INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (0,'127.0.0.1',3306);
INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (1,'192.168.1.180',3306);
SAVE MYSQL SERVERS TO DISK; LOAD MYSQL SERVERS TO RUNTIME;

INSERT INTO mysql_query_rules (rule_id,active,username,schemaname,destination_hostgroup,apply) values (10,1,'dkproxy','dk_thumbnails',0,1);
INSERT INTO mysql_query_rules (rule_id,active,username,schemaname,destination_hostgroup,apply) values (20,1,'dkproxy','digikam',1,1);
INSERT INTO mysql_query_rules (rule_id,active,username,schemaname,destination_hostgroup,apply) values (21,1,'dkproxy','dk_face',1,1);

SAVE MYSQL QUERY RULES TO DISK; LOAD MYSQL QUERY RULES TO RUNTIME;

That should be all, if I did not forget anything. Again connecting to the ProxySQL admin interface you can easily see how well the rules are working:

Admin> SELECT hostgroup,srv_host,status,ConnFree,ConnOK,Queries,Bytes_data_sent,Bytes_data_recv,Latency_us FROM stats_mysql_connection_pool;
+-----------+-----------------+----------+--------+----------+--------+---------+-----------------+-----------------+------------+
| hostgroup | srv_host        | srv_port | status | ConnFree | ConnOK | Queries | Bytes_data_sent | Bytes_data_recv | Latency_us |
+-----------+-----------------+----------+--------+----------+--------+---------+-----------------+-----------------+------------+
| 0         | 127.0.0.1       | 3306     | ONLINE | 1        | 1      | 34767   | 2128098         | 595568549       | 0          |
| 1         | 192.168.1.180   | 3306     | ONLINE | 2        | 2      | 121759  | 3399218         | 5250558         | 380        |
+-----------+-----------------+----------+--------+----------+--------+---------+-----------------+-----------------+------------+
2 rows in set (0.00 sec)

From our local thumbnail host we got about 100 times as much data as from the general digiKam database, which is on the network. But most importantly: digiKam feels much faster again! Next if I have time I might look into why digiKam sent so many queries to the remote server after all, when I just clicked around and filtered for a few minutes! ;-) In my previous job I could reduce the number of SQL queries in a database application drastically by using more JOIN statements...