On 08/09/15 12:00, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
However, even in this case, when the subscriber base is really huge, single mysql system can become slow, so there needs to be some partitioning of the users, relying on several mysql systems.
In that case partitioning could be done also based on userid or phone number pattern rather than complicating the server setup.
Are you referring to the hierarchical architecture I plugged in as example for usrloc, or about the topic of limiting the concurrent calls using a backend system?
The later is nothing that complex to be added and is more or less what you are saying.
For the former, it depends on the topology of the service and distribution of subscribers.
For example, if you have the sip server nodes close to each other, then you can do partitioning directly to few backends and access them/do queries from all sip nodes.
But if you have the nodes across the world, replicating to all nodes or querying the other site is adding a lot of overhead and latency. For example, if you have 1 000 000 subscribers on each of 4 nodes (say Dallas, Frankfurt, Singapore and Sidney), then accessing from one site the backend of each other site can be costly (time) and replication of location records will generate a lot of traffic (no matter is mysql layer or sip layer). Being expected that most of the subscribers have contacts in their region, having all records locally makes less sense as well.
The hierarchical model is not the only one, for 4 nodes over all, one can do parallel forking to the other 3 if the target is not online in the respective node.
From my point of view, the architecture to deploy is really a matter of
different metrics, such as subscribers base and geographical distribution as well as calling patterns. It is not a single best solution.
Cheers, Daniel