Re: [SR-Users] mtree on db Berkeley DB?

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(a)gmail.com > 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(a)hubler.us> >> On Mon, Nov 14, 2011 at 5:10 AM, Daniel-Constantin Mierla >> <miconda(a)gmail.com>> > 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@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 > >