<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
On 11/14/11 3:24 PM, Javier Gallart wrote:
<blockquote
cite="mid:CACviLGadJ1SQMJJUQ6KBUzuHeoTx61HHQyu-_AG5JWRqnaeFTg@mail.gmail.com"
type="cite">Hello
<div><br>
</div>
<div>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:</div>
<div>-no "native" mt_match function, up to the user to find the
best option</div>
<div>-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)?</div>
<div><br>
</div>
<div>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...</div>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Daniel<br>
<blockquote
cite="mid:CACviLGadJ1SQMJJUQ6KBUzuHeoTx61HHQyu-_AG5JWRqnaeFTg@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>Regards</div>
<div><br>
</div>
<div>Javi<br>
<br>
<div class="gmail_quote">On Mon, Nov 14, 2011 at 1:32 PM,
Douglas Hubler <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:douglas@hubler.us">douglas@hubler.us</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Nov 14, 2011 at 5:10 AM,
Daniel-Constantin Mierla<br>
<<a moz-do-not-send="true"
href="mailto:miconda@gmail.com">miconda@gmail.com</a>>
wrote:<br>
> are there any other no-sql database systems that have
such mechanism? Might<br>
> not be hard to make a connector when the time will
allow -- just to know the<br>
> best options here.<br>
<br>
</div>
mongodb will auto promote. Caveat, (like redis if i
understand<br>
correctly), is that all writes are directed to a single
master (be it<br>
chosen dynamically), but reads can happen anywhere to spread
the load.<br>
Also, you need to accept the distaster scenario of a
"network<br>
partition" where a minority set of servers find themselves
w/o a<br>
master. Example: 5 servers in datacenter #1 and 4 servers
in<br>
datacenter #2. If the link between datacenters is broken,
then all<br>
servers in datacenter #2 will not have a master and will be
read-only<br>
until link is restored. Good part about single master is
there's no<br>
chance of inconsistent data.<br>
<br>
Turns out local fail-over v.s. consistent data is a well
explored area.<br>
<br>
<a moz-do-not-send="true"
href="http://blog.nahurst.com/visual-guide-to-nosql-systems"
target="_blank">http://blog.nahurst.com/visual-guide-to-nosql-systems</a><br>
<br>
I've worked w/the C++ driver to mongodb is anyone has
questions.<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Kamailio Advanced Training, Dec 5-8, Berlin: <a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
<a class="moz-txt-link-freetext" href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a> -- <a class="moz-txt-link-freetext" href="http://twitter.com/miconda">http://twitter.com/miconda</a></pre>
</body>
</html>