22 Feb
2018
22 Feb
'18
3:06 a.m.
Opinion of a Kamailio novice, take with a grain of salt:
Would it be appropriate to think about this general problem more akin to
how some modules support either a file or a db backend? Imagine this world:
- To be called a DB in Kamailio parlance, a backend needs to conform to
the DB API, be generically usable, etc – all the good stuff we have now.
- Some module (foo) has 3 modes of operation:
- file – the module uses a file on disk
- db – the module uses the DB api
- redis – a very foo-specialized application of Redis and its features
In my mind, having a specialized Redis backend for a module is no different
than having a file backend in addition to a DB backend (see the dispatcher
module for example).
Just because something (redis) is database-like, doesn't necessarily mean
that it can/should only be accessed as a DB (above definition), especially
if the tool supports features that shouldn't be in the DB API, and those
features are very valuable to a specific module.
This would imply that there is a db_redis module which allows Redis to
participate in anything demanding a DB (as defined above), as well as a
foo_redis (name not important) module, which leverages Redis in a very
foo-specific way.
It would of course be the responsibility of module owners to decide when it
is truly appropriate to have this sort of specialized support, or when the
DB api is sufficient (including the potential additional maintenance
burden, attractiveness to clients, etc).
On Wed, Feb 21, 2018 at 1:35 AM Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
Hello,
(cross-posting being something I want to get developers and users
express their opinions).
We were recently in a (lucky) situation to have two new modules
submissions targeting more or less the same purpose: allowing to use
Kamailio with a Redis backend via database API.
One was submitted by Andreas Granig (Sipwise) and already merged with
the name db_redis, because it was designed from the beginning as a
generic DB connector, so the module can be used with auth_db, acc,
usrloc, ...
* https://www.kamailio.org/docs/modules/devel/modules/db_redis.html
The second one was submitted by Surendra Tiwari (Plivo), initially
having a naming conflict with db_redis, but renamed to db_redisusrloc,
see the pull request at:
* https://github.com/kamailio/kamailio/pull/1446
Now, this email is about deciding the way to go forward with the second
module.
It was designed to be used only for usrloc in the first phase, with many
specific usrloc attributes hard coded inside db_redisusrloc. Surendra
said (in a private chat) that the long term plan is to make it work for
other modules. Anyhow, at this moment is very tied to usrloc, therefore
the name of the module.
Given that the backend (Redis) is not an SQL engine, mapping over
Kamailio's DB API needs some schema definition (see the readme of
db_redis) in order to make it generic and work for all our modules that
use a DB backend.
On the other hand, to squeeze the best of the backend, specially in
no-SQL cases, having a dedicated DB connector module optimized for a
specific module might help to get more
performances/high-availability/scalability from the backend itself.
In this case, for example the expires value for a contact record can be
set inside redis, so kamailio module doesn't have to run a timer routine
to clean up (it doesn't mean db_redisusrloc does it right now, I didn't
have time for a proper review, just giving an example). Surendra said
they use it in production for couple of months now and it is several
times faster than using usrloc with db_postgres (iirc, not db_mysql) for
db_mode=3 (database only mode).
But of course, the reverse of the medal with a dedicated db connector
for a module: it adds overhead to code maintenance (besides generic
updates due to external library changes, I expect changing something
relevant in usrloc, like adding new columns, would require updates in
this module as well).
So, there are few things I want feedback on:
1) how do you fill about splitting from a generic-only DB connectors to
have also some dedicated ones? This is more from confusion point of
view, as a general rule so far, we do not deny contributions if there
are other options for same kind of feature (e.g., many lcr or nat
traversal options). As long as the contributor is willing to maintain
the code, we were fine.
2) I guess usrloc, presence and dialog modules would be the main
suspects that would benefit for such dedicated connectors, in other
cases might not worth adding dedicated connectors. Missing any other
module one would like to squeeze more performances with a dedicated
connector?
3) should we set a different naming policy for such modules, for
example: use *dbs_* prefix instead *db_*, to suggest better it is a
DataBase Specific connector?
4) Andreas said he plans to do some performance testing of usrloc module
with the two modules and see the differences. Anyone else that wants to
do it? It can be a good metric to see if it worth going one way or another?
5) Helping to review the pull request, specially if you use Redis, is
appreciated. Personally I am very short in available time these days,
next week I plan do to new Kamailio stable releases, so the schedule is
not getting lighter in my side.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users