Hi, There is an out-of-tree implementation of func_redis: https://github.com/tic-ull/func_redis. I don't use it in production, but it worked fine for me on a test machine. With slight modifications it works with Asterisk 13+. Unfortunately, the project seems to be abandoned and the author did not try to merge the code upstream.
On 22 December 2017 at 16:54, Matt Fredrickson <[email protected]> wrote: > > > On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich < > [email protected]> wrote: > >> Abhay, >> >> Migrating astsb from SQLlite to redis isn't the topic here. I'm talking >> adding a new type of storage engine. For example, func_redis, that will >> implement the relevant key/value operations that are commonly used by >> people. >> > > I think doing it as func_redis instead of a sorcery backend is a good idea. > > I'm guessing there are a lot of people that can use it. It seems like > having access to a redis like backend is a modern requirement for most big > systems. > > Matthew Fredrickson > > Nir >> >> On Fri, Dec 22, 2017, 14:33 Abhay Gupta <[email protected]> wrote: >> >>> Hi All, >>> >>> I had a program where I have implemented a project using REDIS wherein >>> the client is made using a socket library and no other third party client >>> library in C . >>> >>> This REDIS database has 400 million records and performs extremely well >>> though the memory requirement for such a large dataset goes to 48GB . So I >>> strongly believe that for such key value pair REDIS will be the right >>> choice for ASTDB. >>> >>> Regards, >>> >>> Abhay >>> >>> On 22-Dec-2017, at 5:52 PM, Nir Simionovich <[email protected]> >>> wrote: >>> >>> Hi All, >>> >>> Following a discussion on JIRA [https://issues.asterisk.org/j >>> ira/browse/ASTERISK-27383], I truly believe that >>> adding a scaleable, robust and most importantly - accepted key/value >>> store mechanism to the Asterisk dialplan >>> is a worthwhile effort. >>> >>> Every, and I do mean every, Asterisk application requires a key/value >>> store of some form. Most developers will >>> basically butcher (would have used stronger words, but refraining from >>> doing so) AstDB in the process, which will >>> then result in a performance toll - specifically when dealing with a >>> high capacity systems. >>> >>> Initially, I was under the impression this should be done as a sorcery >>> module, but I'm not sure this is the >>> correct approach or the required use case. >>> >>> I would like to hear if others believe this is a worth while effort? >>> if others believe it is, I'll be ecstatic to >>> work with others on this one (adding Redis support isn't as simple as it >>> sounds). However, before I start >>> working on something, I'd like to see if others believe this as strongly >>> as I do. >>> >>> On the same note, I'll be in NYC second week of January - so if any of >>> you are around that area and would >>> like to combine forces to spear this - would love to do so. >>> >>> >>> -- >>> Kind Regards, >>> Nir Simionovich >>> GreenfieldTech >>> (schedule) http://nirsimionovich.appointy.com/ >>> (w) http://www.greenfieldtech.net >>> (p) +972-73-2557799 <+972%2073-255-7799> (MSN): >>> [email protected] >>> (m) +972-54-6982826 <+972%2054-698-2826> (GTALK): >>> [email protected] >>> (f) +972-73-2557202 <+972%2073-255-7202> (SKYPE): >>> greenfieldtech.nir >>> >>> ---------------------------------------------------------- >>> Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud >>> Servers <https://www.digitalocean.com/?refcode=97eeea09917a> >>> ---------------------------------------------------------- >>> >>> *Disclaimer:* >>> This e-mail is intended solely for the person to whom it is addressed >>> and may contain confidential or legally privileged information. Access to >>> this e-mail by anyone else is unauthorized. If an addressing or >>> transmission error has misdirected this e-mail, please notify the author by >>> replying to this e-mail and destroy this e-mail and any attachments. >>> E-mail may be susceptible to data corruption, interception, unauthorized >>> amendment, viruses and delays or the consequences thereof. If you are not >>> the intended recipient, be advised that you have received this email in >>> error and that any use, dissemination, forwarding, printing or copying of >>> this email is strictly prohibited. >>> >>> -- >>> _____________________________________________________________________ >>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>> >>> asterisk-dev mailing list >>> To UNSUBSCRIBE or update options visit: >>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>> >>> >>> -- >>> _____________________________________________________________________ >>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>> >>> asterisk-dev mailing list >>> To UNSUBSCRIBE or update options visit: >>> http://lists.digium.com/mailman/listinfo/asterisk-dev >> >> -- >> >> Kind Regards, >> >> Nir Simionovich >> >> GreenfieldTech >> >> (schedule) http://nirsimionovich.appointy.com/ >> >> (w) http://www.greenfieldtech.net >> >> (p) +972-73-2557799 <+972%2073-255-7799> (MSN): >> [email protected] >> >> (m) +972-54-6982826 <+972%2054-698-2826> (GTALK): >> [email protected] >> >> (f) +972-73-2557202 <+972%2073-255-7202> (SKYPE): >> greenfieldtech.nir >> >> >> ---------------------------------------------------------- >> >> Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud >> Servers <https://www.digitalocean.com/?refcode=97eeea09917a> >> >> ---------------------------------------------------------- >> >> *Disclaimer:* >> >> This e-mail is intended solely for the person to whom it is addressed and >> may contain confidential or legally privileged information. Access to this >> e-mail by anyone else is unauthorized. If an addressing or transmission >> error has misdirected this e-mail, please notify the author by replying to >> this e-mail and destroy this e-mail and any attachments. >> E-mail may be susceptible to data corruption, interception, unauthorized >> amendment, viruses and delays or the consequences thereof. If you are not >> the intended recipient, be advised that you have received this email in >> error and that any use, dissemination, forwarding, printing or copying of >> this email is strictly prohibited. >> >> -- >> _____________________________________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-dev >> > > > > -- > Matthew Fredrickson > Digium, Inc. | Engineering Manager > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
