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)?

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...

coming back to the topic related to mtree, to be able to set values via mi/rpc -- it won't be that difficult to add such functionality. Usually with a tree is mainly reading, due to fast matching on tree indexing. The question is how many times/often do you need to change values and how many of them at the same time (more or less).

I assume many times the changes will be somewhere down the tree, since the first part of the number is usually the same (e.g., country code and operator prefix). To update the tree at runtime, while there are reads on it, there must be used a lock to be safe an consistent. If you do lot of writes and very often, then you keep the tree structure locked a lot, slowing the search.

Can you estimate the number of writes and how often they would be on a daily basis? There might be other solutions to look at, if writes are very often.

Cheers,
Daniel

Regards

Javi

On Mon, Nov 14, 2011 at 1:32 PM, Douglas Hubler <douglas@hubler.us> wrote:
On Mon, Nov 14, 2011 at 5:10 AM, Daniel-Constantin Mierla
<miconda@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 list
sr-users@lists.sip-router.org
http://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/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda