<div dir="ltr"><div><div><div>Hello all,<br><br></div>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><br></div>BR,<br></div>George<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 April 2018 at 21:23, Charles Chance <span dir="ltr"><<a href="mailto:charles.chance@sipcentric.com" target="_blank">charles.chance@sipcentric.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div dir="auto">Hello Joel,</div><div dir="auto"><br></div><div dir="auto">+1 to everything Alex has said. Using DMQ simplifies/flattens the stack and allows for a truly decoupled cluster with fewer points of failure.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div>Disclaimer: I am possibly very slightly biased!</div><div><br></div><div>Cheers,</div><div><br></div><div>Charles</div><div><div class="h5"><div><br></div><br><div class="gmail_quote"><div>On Fri, 27 Apr 2018 at 16:45, Alex Balashov <<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Joel,<br>
<br>
Our experience with using DMQ for dialog and usrloc replication has been<br>
very positive, and we recommend it wholeheartedly over the crusty<br>
database sync-based methods. <br>
<br>
The primary appeal comes from the fact that the replication is done at a<br>
higher level, so there is no need to contend with issues surrounding the<br>
degree of two-way coupling that DB-backed modules have. For instance,<br>
the dialog module has both "runtime" and "persistent" components to its<br>
backing, so while the dialog module can store dialog info in a DB table,<br>
it can't store profile info. Replicating dialogs via DMQ allows one to<br>
share profile state. <br>
<br>
And in general, it's a lot more efficient. If you have 3 or 4<br>
registrars, you have a reasonable degree of persistence if you use in<br>
memory-only storage for usrloc with DMQ replication. That takes an<br>
enormous workload off the database. <br>
<br>
Databases are for storage; they aren't great for highly ephemeral,<br>
short-lived, real-time data, though they're often (mis)used for that<br>
purpose:<br>
<br>
<a href="https://en.wikipedia.org/wiki/Database-as-IPC" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>Database-as-IPC</a><br>
<br>
DMQ solves a much-needed gap here in Kamailio, and I hope it is extended<br>
to provide transport for other components too.<br>
<br>
-- Alex<br>
<br>
On Fri, Apr 27, 2018 at 08:31:56AM -0700, Joel Serrano wrote:<br>
<br>
> Hi all,<br>
> <br>
> Just wanted to know what your opinions were on using DMQ modules over<br>
> database for things like dialog replication, registrations, etc...<br>
> <br>
> Is DMQ the "new way to go"? I know that there lots of ways of doing things<br>
> with each having pros/cons... But I was wondering...<br>
> <br>
> What does the community think on this topic?<br>
> <br>
> Are you guys taking advantage of the DMQ modules or are you still relying<br>
> on database as much as possible? Maybe a combination of both?<br>
> <br>
> Cheers,<br>
> Joel.<br>
<br>
> ______________________________<wbr>_________________<br>
> Kamailio (SER) - Users Mailing List<br>
> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi<wbr>-bin/mailman/listinfo/sr-users</a><br>
<br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
<br>
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
<br>
______________________________<wbr>_________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi<wbr>-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div></div></div></div></div>

<br>
<div><font style="font-size:10pt;font-family:Helvetica,Arial,sans-serif" color="gray">Sipcentric Ltd.
                Company registered in England & Wales no. 7365592.</font><span style="font-size:10pt;font-family:Helvetica,Arial,sans-serif"> </span><font style="font-size:10pt;font-family:Helvetica,Arial,sans-serif" color="gray">Registered
                office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.</font></div><br>______________________________<wbr>_________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><br>
<br></blockquote></div><br></div>