[Freeswitch-users] Nibblebill for NoSQL

Mathieu Rene mrene_lists at avgs.ca
Thu Apr 22 11:06:27 PDT 2010


I have mod_redis ready, it'll go in soon.

Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mrene at avgs.ca




On 2010-04-22, at 2:03 PM, Dome Charoenyost wrote:

> Hi Rupa,
> 
>   any update about NoSQL module. Now i'm modify mod_limit change sql
> to tokyo tyrant. it's work fine for me. now i can share limit data to
> other FS server. Now i'm thinking about all fs db. if use redis
> (sorted sets)  i think posible todo. but it's not easy to modify fs
> code.
> 
> So i need comment about aventage if change fs backend froom SQL to NoSQL.
> 
> BG
> 
> Dome C.
> 
> 
> 2010/3/4 Rupa Schomaker <rupa at rupa.com>:
>> On Wed, Mar 3, 2010 at 12:04 PM, Yossi Neiman
>> <freeswitch at cartissolutions.com> wrote:
>>> 
>>> 
>>> Maybe it would be even more useful to provide general functionality that
>>> can be shared amongst multiple components of freeswitch.  That would
>>> make it all the more useful.  However, seeing that I'm not a big fan of
>>> the NoSQL data engines, I don't know if this is possible.  In my
>>> opinion, most NoSQL is just key=>value pairs, and is basically a
>>> reinvention of the wheel that RDBMS's had taken care of years ago...
>>> Not meaning to open up a discussion about the virtues of NoSQL (and
>>> certainly not a flamewar)...
>>> 
>> 
>> I created a mod_memcache already and I intend to do a mod_redis at some
>> point.  I'm not a huge fan of NoSQL but there are definite uses for it.
>> 
>> General functionality:  I could be convinced to come up with a general api
>> for distributed key/value store with mod_memcache and mod_redis providing
>> implementation.  The problem is that the NoSQL stuff isn't very consistent
>> so even though both support key/value their behavior can significantly
>> differ.  eg: updating a value in memcached doesn't bump the expire time but
>> does in redis.  Also, redis has support for a much more robust set of value
>> types and operators.
>> Anyway, a generic distributed key/value api might look like:
>> dhash <backend> set key value [expire]
>> dhash <backend> setnx key value [expire]  # only set if it doesn't already
>> exist
>> dhash <backend> get key [...] # support multiple keys
>> dhash <backend> <increment|decrement> key [step]
>> dhash <backend> del key
>> where backend would be memcache or redis or some other implementation.
>> Notice I didn't even touch things like hashing to support sharding,
>> failover, etc.
>> 
>>> 
>>> Yossi Neiman
>>> Cartis Solutions, Inc. - http://www.cartissolutions.com
>>> 
>> 
>> --
>> -Rupa
>> 
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>> 
>> 
> 
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org




More information about the FreeSWITCH-users mailing list