[Kde-pim] Akonadi: single database design mistake?

[Dmitry Torokhov]

Hi,

So I have upgraded from very usable setup with Fedota 15/KDE 4.6.x to
Fedora 16 with shiny new KDE 4.7.3 and brand new KDE PIM suite and as
many users found that the new version Akonadi/Kmail2 is pretty much
unusable. The conversion of my archive mailbox (mixed maildir) and 2
IMAP accounts ran for over 8 hours and I am not quite sure what state it
is in the moment as Kontact is trying to open my work mailbox for over
10 minutes now (ever since I got to my desk and woke up my laptop).

Looking at the Akonadi mysql database I see that I have 3 large tables:
- parttable:			587230 rows;
- pimitemflagrelation:		241688 rows;
- pimitemtable:			294840 rows;

So akonadi data takes about 700Mb on my hard drive (compared to 283 Mb
of actual local mail), and this is with disabled "Full index" option on
all mailboxes:
[dtor at dtor-d630 ~]$ du -hc .local/share/akonadi/
5.3M    .local/share/akonadi/file_db_data
4.0K    .local/share/akonadi/db_data/test
212K    .local/share/akonadi/db_data/performance_schema
1008K   .local/share/akonadi/db_data/mysql
570M    .local/share/akonadi/db_data/akonadi
681M    .local/share/akonadi/db_data
4.0K    .local/share/akonadi/db_misc
686M    .local/share/akonadi/
686M    total

The mysql took so far:

[dtor at dtor-d630 ~]$ ps -f -C mysqld
UID        PID  PPID  C STIME TTY          TIME CMD
dtor     14230 14227 84 Nov27 ?        09:43:05 /usr/libexec/mysqld --defaults-file=/home/dtor/.local/share/akonadi//mysql.conf --datadir=/home/d

CPU is pegged by mysqld/akonadi_imap_resource and other "agents" and
everything is _slow_. I hate to think what the experience would be if I
had  standard hard drive and not an SSD.

And this brings me to the question: is stuffing everything into a single
database such a good idea?

Previous version of Kmail and other MUAs use per-mailbox/per-folder
indices which are significantly smaller and thus take significantly less
resources to populate, read and update. If a mailbox grows too big (for
example my LKML folder is at ~100K mails at the moment) then user pays
penalty only if he needs to actually open that mailbox (adding new guids
to indices is fairly inexpensive so regular fetches are not really
noticeable), otherwise entire index is most likely still in buffer cache
and stays there while it is needed.  Re-fetching index is reading just a
couple of MB from disk. Compare this with single database of akonadi
where we need to parse entire index to select all mails for given
folder. For decent performance mysqld needs to have indices in its
memory, thus taking resorces away from other applications.  This setup I
guess would work well for a dedicated server (like Zimbra install) but
not for individual desktop/laptop case.

So, while unified API to access various kinds of data is a nice thing to
have, do all provides actually have to share single storage? Would they
not be better off using dedicated storage in certain cases?

Thanks.

-- 
Dmitry

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/