[SR-Users] mtree on db Berkeley DB?

Daniel-Constantin Mierla miconda at gmail.com
Wed Nov 16 08:07:19 CET 2011


Hello,

On 11/15/11 12:59 PM, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> 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.
> daniel,
>
> could the lock be from the node that requires modification downwards,
> which would leave all other branches unlocked?

for large trees it would be not possible to have a lock for each node, 
there will be too many and different operating systems have limits. On a 
hash table there is a lock per slot, no matter how many items are in the 
table. In a tree is hard to define a set of locks and just going with 
one per node is not that feasible. For eaxample one record with prefix 
0123456789 creates 10 nodes, then some nodes are reused, but still there 
are a greater or equal number of nodes than the number of records loaded.

>
>> 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.
> i was thinking that perhaps mtree would be used to store numbers that
> are ported to other operators instead of the current carrier route pdb
> server, where the whole mmap file needs to be reloaded.  in that
> application i would imagine a few hundred updates per hour, but many of
> them would only affect the value associated with the node, not the
> structure of the three.
Adding a record (i.e., prefix/value) in a tree should be fast if 
building the missing sub-tree part of it and then just linking it to the 
main tree. Removing might need more time, a solution for it can be just 
setting the value to NULL and keep the tree structure..
Cheers,
Daniel

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




More information about the sr-users mailing list