[asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

Corey Farrell git at cfware.com
Fri Dec 22 11:43:27 CST 2017


I hope we consider creating a res_redis first, then base everything off 
that.  If a redis library can be used directly by any module that would 
fine but I'd like to see us avoid following the example of curl where 
everything uses a dialplan function to perform requests.  Dialplan 
functions should be for dialplan, in general I think they should not be 
used as internal API's.


On 12/22/2017 12:23 PM, Nir Simionovich wrote:
>
> Well,
>
> We can start with that implementation as a base for learning, and go 
> from there. Looks like I have some homework for tonight.
>
> Nir
>
>
> On Fri, Dec 22, 2017, 18:44 Matt Fredrickson <creslin at digium.com 
> <mailto:creslin at digium.com>> wrote:
>
>     On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny
>     <ivan.poddubny at gmail.com <mailto:ivan.poddubny at gmail.com>> wrote:
>
>         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.
>
>
>     Yeah, unless he submits it and goes through that process himself,
>     we can't do a lot with it in the mainline Asterisk codebase.
>
>     Matthew Fredrickson
>
>
>         On 22 December 2017 at 16:54, Matt Fredrickson
>         <creslin at digium.com <mailto:creslin at digium.com>> wrote:
>
>
>
>             On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich
>             <nir.simionovich at gmail.com
>             <mailto:nir.simionovich at gmail.com>> 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
>                 <abhay at avissol.com <mailto:abhay at avissol.com>> 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
>>                     <nir.simionovich at gmail.com
>>                     <mailto:nir.simionovich at gmail.com>> wrote:
>>
>>                     Hi All,
>>
>>                     Following a discussion on JIRA
>>                     [https://issues.asterisk.org/jira/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
>>                     <http://www.greenfieldtech.net/>
>>                       (p) +972-73-2557799 <tel:+972%2073-255-7799>
>>                     (MSN):nirs at greenfieldtech.net
>>                     <mailto:nirs at greenfieldtech.net>
>>                       (m) +972-54-6982826 <tel:+972%2054-698-2826>
>>                     (GTALK):nir.simionovich at gmail.com
>>                     <mailto:nir.simionovich at gmail.com>
>>                       (f) +972-73-2557202 <tel:+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
>                 <http://www.greenfieldtech.net/>
>
>                   (p) +972-73-2557799 <tel:+972%2073-255-7799>
>                 (MSN):nirs at greenfieldtech.net
>                 <mailto:nirs at greenfieldtech.net>
>
>                   (m) +972-54-6982826 <tel:+972%2054-698-2826>
>                 (GTALK):nir.simionovich at gmail.com
>                 <mailto:nir.simionovich at gmail.com>
>
>                   (f) +972-73-2557202 <tel:+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
>
>
>
>
>     -- 
>     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
>
> -- 
>
> Kind Regards,
>
>   Nir Simionovich
>
> GreenfieldTech
>
> (schedule) http://nirsimionovich.appointy.com/
>
>   (w)http://www.greenfieldtech.net <http://www.greenfieldtech.net/>
>
>   (p) +972-73-2557799 (MSN):nirs at greenfieldtech.net 
> <mailto:nirs at greenfieldtech.net>
>
>   (m) +972-54-6982826 (GTALK):nir.simionovich at gmail.com 
> <mailto:nir.simionovich at gmail.com>
>
>   (f) +972-73-2557202 (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.
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171222/30d25dc6/attachment-0001.html>


More information about the asterisk-dev mailing list