The DMQ advantage still holds due to flattening of the stack/seamlessness, and lack of mediation/marshaling through DB APIs or manual Redis interactions.
On May 2, 2018 10:56:41 AM EDT, George Diamantopoulos georgediam@gmail.com wrote:
Hello all,
Do you expect the DMQ vs database advantages to still hold true even when considering REDIS as a database (new backend in devel should make this possible)? Or are these points mainly relevant when it comes to traditional, persistent storage databases like mySQL? Thanks!
BR, George
On 27 April 2018 at 21:23, Charles Chance charles.chance@sipcentric.com wrote:
Hello Joel,
+1 to everything Alex has said. Using DMQ simplifies/flattens the
stack
and allows for a truly decoupled cluster with fewer points of
failure.
In production we use DMQ for htable, usrloc, dialog and presence,
where
previously we were using MySQL with Percona - now, performance is
vastly
improved and the admin overhead is greatly reduced.
Disclaimer: I am possibly very slightly biased!
Cheers,
Charles
On Fri, 27 Apr 2018 at 16:45, Alex Balashov
wrote:
Hello Joel,
Our experience with using DMQ for dialog and usrloc replication has
been
very positive, and we recommend it wholeheartedly over the crusty database sync-based methods.
The primary appeal comes from the fact that the replication is done
at a
higher level, so there is no need to contend with issues surrounding
the
degree of two-way coupling that DB-backed modules have. For
instance,
the dialog module has both "runtime" and "persistent" components to
its
backing, so while the dialog module can store dialog info in a DB
table,
it can't store profile info. Replicating dialogs via DMQ allows one
to
share profile state.
And in general, it's a lot more efficient. If you have 3 or 4 registrars, you have a reasonable degree of persistence if you use
in
memory-only storage for usrloc with DMQ replication. That takes an enormous workload off the database.
Databases are for storage; they aren't great for highly ephemeral, short-lived, real-time data, though they're often (mis)used for that purpose:
https://en.wikipedia.org/wiki/Database-as-IPC
DMQ solves a much-needed gap here in Kamailio, and I hope it is
extended
to provide transport for other components too.
-- Alex
On Fri, Apr 27, 2018 at 08:31:56AM -0700, Joel Serrano wrote:
Hi all,
Just wanted to know what your opinions were on using DMQ modules
over
database for things like dialog replication, registrations, etc...
Is DMQ the "new way to go"? I know that there lots of ways of
doing
things
with each having pros/cons... But I was wondering...
What does the community think on this topic?
Are you guys taking advantage of the DMQ modules or are you still
relying
on database as much as possible? Maybe a combination of both?
Cheers, Joel.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Sipcentric Ltd. Company registered in England & Wales no. 7365592.
Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Sent via mobile, please forgive typos and brevity.