competition

[Jeroen van Meeuwen (Kolab Systems)]

"Andy Bennett" <andyjpb at ashurst.eu.org> wrote:

>Hi,
>
>> Kolab Systems is thinking of such SQL databases for integration purposes,
> > where the performance penalty now lies within having to use the IMAP
> > protocol to gain access to the underlying metadata (seen status, message
> > indexes) in distributed groupware environments where Cyrus itself is not
> > the only component that needs access to such information (but would still
> > remain authoritative, of course, and would be the only component with 
>write
> > access to most tables).
>> 
>> While not necessarily the best approach, it seems worth exploring.
>
>What makes you think the query parsing and other overheads of SQL will 
>be faster than IMAP?
>I'd be interested in any numbers that you might have to support the effort.
>

The scenario is integration, not extension of Cyrus -which in and of itself works perfecly fine and reliable for us. We're not seeking to improve Cyrus' performance with *SQL db backends.

Imagine the following scenario; a client polls 3rd party application for a list of mailboxes and the content's status very regularly -basically what it's interested in knowing is whether anything changed. Each 3rd party app will seek to cache the results somehow, for improved performance interacting with its clients and as to not continuously put load on the Cyrus server.

Our idea is to prevent that caching from needing to happen, and needlessly be duplicated technology across 3rd party apps, by using what Cyrus would consider it's live data in SQL as the 3rd party app's cache.

Now, I don't have any numbers to compare while there is no Cyrus SQL db backend for the relevant databases. I'm just thinking that a single database query -if it could provide accurate status info- can be more efficient -to the Cyrus server(s) itself as well as the 3rd party app- then folderlist, iterate, request status info, parse, only to ultimately throw back at the client there's no changes -which is the result most of the time. It'd also eliminate duplicating attempts to cache folderlist and status results somehow, and would ultimately improve the scalability of such 3rd party apps as part of the infra they require to be shared..., since its "cache" is in SQL, etc. etc.

>The big downside to using an SQL database is the enormous temptation to 
>point all the Cyrus servers at the same Database server and lose the 
>redundancy and scalability inherent in a multi node or Murder setup.
>

One would set up the database backend server infrastructure just as much conform to H/A and L/B requirements as the rest of the Cyrus/groupware infrastructure, not unlike how you would set up a sustainable database backend server infrastructure in any other type of critical environment.

-- Jeroen