[SR-Users] mtree on db Berkeley DB?

Javier Gallart jgallartm at gmail.com
Tue Nov 15 15:04:19 CET 2011


Hi Daniel


sound like a good idea, thanks for the tip

Regards

Javi

On Tue, Nov 15, 2011 at 9:59 AM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:

>  Hello,
>
>
> On 11/14/11 3:24 PM, Javier Gallart wrote:
>
> Hello
>
>  very interesting issue actually...the mtree module fits perfectly well
> in a key-value model becaue basically is what the mtree table structure
> defines; that's why redis was the first thing that came to my mind when I
> saw the redis module. Two problems with redis:
> -no "native" mt_match function, up to the user to find the best option
> -replication. Until the cluster feature is ready, we need to change by
> hand the server ip address, which implies a kamailio restart. There is no
> mi command for changing the server in the fly, right..(not in the module
> documentation at least)?
>
> you cannot change the redis server attributes on the fly, but you can
> define many redis servers and based on the name attribute query a specific
> one. So if you define two, you can do round robin queries to both of them,
> by using a shared variable $shv(...) to know which one was used last time.
> In the same way, since $sht(...) can be changed via MI, you can query
> either first redis or second one, based on the value of $sht(). In this way
> you can build some failover solution just in config file of kamailio.
>
> Cheers,
> Daniel
>
>
>  Daniel, I agree that your suggestion about the mi/rpc method would be
> nice. I will also take a look at Mongo as Douglas suggests, and especially
> CouchDB, because you can talk to Couch DB via http...
>
>  Regards
>
>  Javi
>
> On Mon, Nov 14, 2011 at 1:32 PM, Douglas Hubler <douglas at hubler.us> wrote:
>
>> On Mon, Nov 14, 2011 at 5:10 AM, Daniel-Constantin Mierla
>> <miconda at gmail.com> wrote:
>> > are there any other no-sql database systems that have such mechanism?
>> Might
>> > not be hard to make a connector when the time will allow -- just to
>> know the
>> > best options here.
>>
>>  mongodb will auto promote.  Caveat, (like redis if i understand
>> correctly), is that all writes are directed to a single master (be it
>> chosen dynamically), but reads can happen anywhere to spread the load.
>>  Also, you need to accept the distaster scenario of a "network
>> partition"  where a minority set of servers find themselves w/o a
>> master.  Example: 5 servers in datacenter #1 and 4 servers in
>> datacenter #2.  If the link between datacenters is broken, then all
>> servers in datacenter #2 will not have a master and will be read-only
>> until link is restored.  Good part about single master is there's no
>> chance of inconsistent data.
>>
>> Turns out local fail-over v.s. consistent data is a well explored area.
>>
>>  http://blog.nahurst.com/visual-guide-to-nosql-systems
>>
>> I've worked w/the C++ driver to mongodb is anyone has questions.
>>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla -- http://www.asipto.com
> Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20111115/ba9881c6/attachment.htm>


More information about the sr-users mailing list