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

Fri Dec 22 10:23:15 CST 2017

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 <creslin at digium.com> wrote:

>
>
> On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich <
> 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> 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>
>>> 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):
>>> nirs at greenfieldtech.net
>>>   (m) +972-54-6982826 <+972%2054-698-2826>      (GTALK):
>>> nir.simionovich at gmail.com
>>>   (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):
>> nirs at greenfieldtech.net
>>
>>   (m) +972-54-6982826 <+972%2054-698-2826>      (GTALK):
>> nir.simionovich at gmail.com
>>
>>   (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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171222/3a0a7aa9/attachment-0001.html>