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 <abalas...@evaristesys.com> wrote: > > >> On 20 Oct 2023, at 11:34, Jawaid Bazyar <baz...@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 > -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
