[Freeswitch-users] Nibblebill for NoSQL

[Rupa Schomaker]

Dome,

I personally don't have any plans to add NoSQL to nibblebill.  If you have a
patch or a bounty maybe that could change,  But for now, SQL works for me.

On Thu, Apr 22, 2010 at 1:03 PM, Dome Charoenyost <dome at tel.co.th> 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
>



-- 
-Rupa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100422/e343d352/attachment-0001.html