[asterisk-dev] Adding a Key/Value Store mechanism to Asterisk
Alan Graham
ag at zerohalo.com
Fri Dec 22 12:06:23 CST 2017
Regarding the func_redis module linked here - I contributed a couple of
patches to it and I spoke to Sergio (the original author) and he is no
longer associated with the IT Departament of the University of La Laguna
Tenerife Spain, who currently owns this repository. He says that the
current person in charge was tasked to push this upstream, and he'll send a
message to direct them to this list.
However, as he notes, this implementation opens a new connection to redis
for each channel that uses it.
You might want to also check out this project, which includes a res_redis,
though also apparently abandoned, for some inspiration:
https://github.com/dkgroot/ast_redis
-Alan Graham
On Fri, Dec 22, 2017 at 12:43 PM, Corey Farrell <git at cfware.com> wrote:
> 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> wrote:
>
>> On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny <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>
>>> 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/
>>>>>> 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
>>>>>> (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
>>>>
>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- 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
>
> (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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171222/f4fa481c/attachment-0001.html>
More information about the asterisk-dev
mailing list