[SR-Users] mtree on db Berkeley DB?

Daniel-Constantin Mierla miconda at gmail.com
Tue Nov 15 12:23:23 CET 2011


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 at hubler.us 
> <mailto:douglas at hubler.us>> wrote:
>
>     On Mon, Nov 14, 2011 at 5:10 AM, Daniel-Constantin Mierla
>     <miconda at gmail.com <mailto: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 list
> sr-users at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20111115/24b539a7/attachment.htm>


More information about the sr-users mailing list