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

Matt Fredrickson creslin at digium.com
Fri Dec 22 09:54:37 CST 2017


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        (MSN): nirs at greenfieldtech.net
>>   (m) +972-54-6982826      (GTALK): 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.
>>
>> --
>> _____________________________________________________________________
>> -- 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        (MSN): nirs at greenfieldtech.net
>
>   (m) +972-54-6982826      (GTALK): 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.
>
> --
> _____________________________________________________________________
> -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171222/3314a4d1/attachment-0001.html>


More information about the asterisk-dev mailing list