Interesting. Didn't know that about sqlite. If I summarize:
Oracle: Locks only inserted row.
Mysql: Locks entire table.
sqlite: Locks entire DB. Also no network connectivity. Only for all-in-one
box installations.
I will be doing new installations to clients. My responsibility ends in
recommending a suitable DB and building the appropriate support in kannel.
The way I see it, it is between Postgres (for heavier traffic) and Mysql
(faster, lighter load). SQLBox is descent, too, but I try to avoid Windows
servers.
Thanx,
Nikos
----- Original Message -----
From: "Alejandro Guerrieri" <[email protected]>
To: "Nikos Balkanas" <[email protected]>
Cc: "sangprabv" <[email protected]>; "Jarek Guzik" <[email protected]>;
<[email protected]>
Sent: Thursday, January 22, 2009 4:15 PM
Subject: Re: DLR DB processing
Most of my experience is with MySQL. You have to keep in mind that DLR's
and also SqlBox use rather simple queries and no complex locking is
involved, so most DB perform decently well for this.
I wouldn't go sqlite for moderate/heavy traffic because each request
locks the whole DB, though.
I've used MySQL for years without a single problem. Others report the
same with Postgres. Oracle and others are less popular, but should
perform equally I think.
My advice: use whatever you're already supporting on your company. The
benefits of using a platform that you already now beats any performance
difference you may gain by switching to any other DB engine.
Regards,
--
Alejandro Guerrieri
[email protected]
On 19/01/2009, at 2:15, Nikos Balkanas wrote:
Hi,
Still counting votes.
For heavy traffic seems to be Postgress. SQLBox is pretty descent, but I
am not too thrilled about the OS. Windows has a documented 30% latency
on its TCP/IP stack over Linux.
For light traffic it is between MySQL and sqllite.
Note that this is *only* for the internal kannel DLR storage.
Alej, what do you say?
BR,
Nikos
----- Original Message ----- From: "sangprabv" <[email protected]>
To: "Jarek Guzik" <[email protected]>
Cc: "Nikos Balkanas" <[email protected]>; <[email protected]>
Sent: Friday, January 16, 2009 11:01 AM
Subject: Re: DLR DB processing
So what is the best DB for DLR then? Suggestion please. TIA
Willy
-----Original Message-----
From: Jarek Guzik <[email protected]>
To: Nikos Balkanas <[email protected]>
Cc: [email protected]
Subject: Re: DLR DB processing
Date: Fri, 16 Jan 2009 08:46:16 +0100
In this case you are right, use of oracle only for the storage of the
DLR queue is kind of abuse. In my case there is also big delivery
reporting database so at this point it make sense.
Regards,
Jaroslaw Guzik
2009/1/16 Nikos Balkanas <[email protected]>:
Thanx Jareed,
I find Oracle a bit overkill for just DLR storage. Mind you I didn't
mean
end point of the final DLR, just kannel's internal DLR storage.
I was kind of hoping to get some input from Alex about sqllite.
BR,
Nikos
----- Original Message ----- From: <[email protected]>
To: "'Nikos Balkanas'" <[email protected]>; <[email protected]>
Sent: Thursday, January 15, 2009 10:27 PM
Subject: RE: DLR DB processing
Hi Nikos,
I went poorly programming daemon which acquired DLR communicates in
PERL, on
the other hand, PHP script has been a bottleneck. Currently, with
access to
the oracle database and a bit of experience in the pl/sql I use oracle
and
mod_owa with apache, performance is suitable for me - I am able to
take
about 1000 DLRs within a few seconds. Also it is a convenient
solution - all
logic DLR of receiving can be drawn by oracle procedure.
Regards,
Jarek Guzik
________________________________________
From: Nikos Balkanas [mailto:[email protected]]
Sent: Thursday, January 15, 2009 7:03 PM
To: [email protected]
Subject: DLR DB processing
Hi,
I am considering using a DB for DLR storage. Up till now I was using
internal DLRs. Of the many options supported, (Mysql, PostgresSQL,
Oracle,
LibSdb, sqlbox, sqllite) which one would you consider best suited for
bulk
SMS, in terms of performance and reliability. If you could also give a
one
liner for your choice, it would be most appreciated. I thing it is
fair to
say, that internal is the fastest and least reliable of all.
Thanx
Nikos
