[Kde-pim] Re: Architecture: Akonadi, Nepomuk, SPARQL

[Michael Schuerig]

On Monday 25 April 2011, Volker Krause wrote:
> On Friday 22 April 2011 23:41:13 Michael Schuerig wrote:

Volker,

thanks for your illuminating response.

[...]
> > There are a few things about this picture that I don't understand,
> > assuming I've got the picture correctly. The first thing is why
> > there need to be two separate database servers when Virtuoso
> > itself is a quite capable relational/SQL database? Storing related
> > data consistently in two databases instead of just one surely
> > doesn't make things easier.
> 
> It started this way due to historical reasons, Nepomuk wasn't using
> Virtuoso back then for example. During Akademy last year we tried to
> get Akonadi working with Virtuoso as its database backend. It turned
> out though that it's not that easy, the SQL dialects are too
> different. We got to the point where Akonadi was able to connect to
> Virtuoso and with some hacks even create its tables but still failed
> when trying to write its data. Nothing really hard, but probably a
> week or two of work that needs to be done.

I'm surprised by this, as I didn't expect that Akonadi needs anything 
beyond basic SQL, but I'll take your word for it. Is the code resulting 
from this experiment somewhere in the repos?

> However, just using Virtuoso this way will not magically solve
> anything, we need both ways, bit-perfect retrieval of the payload
> and (full text/semantic) indexing. Inherently, this will roughly
> duplicate the amount of stored data, no matter if you use one or two
> databases (in theory, in practice using the same database can of
> course have some synergies in resource usage etc, that's why we
> tried it).

I agree that the "blob" (opaque Akonadi payload data) is necessary. What 
concerns me about MySQL + Virtuoso is not the on-disk footprint. Even 
the memory consumption for the MySQL process isn't that bad. Having two 
separate servers leads to new failure modes: e.g. when only one of them 
is running, when data becomes inconsistent. On a single server you can 
have guaranteed foreign-key relationships, between servers its much more 
effort to follow associations.

Michael

-- 
Michael Schuerig
mailto:michael at schuerig.de
http://www.schuerig.de/michael/
_______________________________________________
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/