[SR-Users] DMQ and/or Database for dialogs, registrations, etc..

[Alex Balashov]

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 at 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 at 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
><abalashov at evaristesys.com>
>> 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 at 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 at 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 at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>


-- Alex

--
Sent via mobile, please forgive typos and brevity.