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 <[email protected]> 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 ><[email protected]> >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 ><[email protected]> >> 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 >>> > [email protected] >>> > 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 >>> [email protected] >>> 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 >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> -- Alex -- Sent via mobile, please forgive typos and brevity. _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
