20 Oct
2023
20 Oct
'23
11:52 a.m.
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(a)evaristesys.com> wrote:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On 20 Oct 2023, at 11:34, Jawaid Bazyar
<bazyar(a)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