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