PS. Kamailio gives you lots of low-level building blocks that can be used to stitch together a custom location service, if you want to rewrite usrloc/registrar. There are quite a few ways to replicate data out of Kamailio at little to no cost to an external consumer.
But if you want to use the tools in the Kamailio toolbox -- and I would argue that in your use-case, a rational actor would -- then you really have two choices:
1) db_mode 3 for the database-backed approach;
2) dmq/dmq_usrloc for the distributed, in-memory approach.
That's about it. There may be an honourable mention here for nonrelational DBs that can be coerced into acting like RDBMs, e.g. `db_redis`, but that's really in the weeds.
-- Alex
On 20 Oct 2023, at 11:41, Alex Balashov abalashov@evaristesys.com wrote:
On 20 Oct 2023, at 11:34, Jawaid Bazyar bazyar@gmail.com wrote:
Would a DMQ cluster with RAM-based store and a relatively small number of nodes (say, 5 for example) be able to handle a location table measured in the scale of 1 million nodes?
A million rows isn't really that much in contemporary computing scales.
Has anyone done this before?
Yes.
I assume DMQ has some provision to prevent loops / etc ?
Wondering about scaling a location service vertically and separating into a different layer from the stuff that needs to scale horizontally.
I think you might be overthinking it for a million contacts. I wouldn't split these hairs. DMQ is either fundamentally viable for something within that order of magnitude (it is), or it's not. It doesn't magically cave in at 1.2 million.
In thinking of reasons not to do DMQ, I would think about it from an even higher-level perspective: you know that data consistency and consensus are pretty difficult problems, and it's unlikely that a module developed by more or less one person and without significant resources and focus invested in these problems is going to rival a widely-used database (of one sort or another).
In thinking of reasons to do DMQ: if it's fundamentally reliable, edge-cases and failure modes may not be important enough to outweigh the cost savings, simplicity and performance boost of not having to synchronise blocking lookups over a remote database, deal with the problems of making that database highly available, operate and care for and feed the database, etc. Plus, there's a generally correct sense in software engineering that using database as an inter-process communication mechanism for ephemeral, short-term data streams is an antipattern[1][2]. There is room for lively debate about whether is the correct framing of what a SIP location service does.
-- Alex
[1] https://en.wikipedia.org/wiki/Database-as-IPC
[2] https://stackoverflow.com/questions/3815941/database-as-ipc-antipattern
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800