<div dir="ltr"><span style="color:rgb(0,0,255)">Hi, just sharing my experience from last year while adding some features to db_postgres and db_sqlite</span><br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 21, 2018 at 1:33 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
(cross-posting being something I want to get developers and users<br>
express their opinions).<br>
<br>
We were recently in a (lucky) situation to have two new modules<br>
submissions targeting more or less the same purpose: allowing to use<br>
Kamailio with a Redis backend via database API.<br>
<br>
One was submitted by Andreas Granig (Sipwise) and already merged with<br>
the name db_redis, because it was designed from the beginning as a<br>
generic DB connector, so the module can be used with auth_db, acc,<br>
usrloc, ...<br>
<br>
  * <a href="https://www.kamailio.org/docs/modules/devel/modules/db_redis.html" rel="noreferrer" target="_blank">https://www.kamailio.org/docs/<wbr>modules/devel/modules/db_<wbr>redis.html</a><br>
<br>
The second one was submitted by Surendra Tiwari (Plivo), initially<br>
having a naming conflict with db_redis, but renamed to db_redisusrloc,<br>
see the pull request at:<br>
<br>
  * <a href="https://github.com/kamailio/kamailio/pull/1446" rel="noreferrer" target="_blank">https://github.com/kamailio/<wbr>kamailio/pull/1446</a><br>
<br>
Now, this email is about deciding the way to go forward with the second<br>
module.<br>
<br>
It was designed to be used only for usrloc in the first phase, with many<br>
specific usrloc attributes hard coded inside db_redisusrloc. Surendra<br>
said (in a private chat) that the long term plan is to make it work for<br>
other modules. Anyhow, at this moment is very tied to usrloc, therefore<br>
the name of the module.<br>
<br>
Given that the backend (Redis) is not an SQL engine, mapping over<br>
Kamailio's DB API needs some schema definition (see the readme of<br>
db_redis) in order to make it generic and work for all our modules that<br>
use a DB backend.<br>
<br>
On the other hand, to squeeze the best of the backend, specially in<br>
no-SQL cases, having a dedicated DB connector module optimized for a<br>
specific module might help to get more<br>
performances/high-<wbr>availability/scalability from the backend itself.<br>
<br>
In this case, for example the expires value for a contact record can be<br>
set inside redis, so kamailio module doesn't have to run a timer routine<br>
to clean up (it doesn't mean db_redisusrloc does it right now, I didn't<br>
have time for a proper review, just giving an example). Surendra said<br>
they use it in production for couple of months now and it is several<br>
times faster than using usrloc with db_postgres (iirc, not db_mysql) for<br>
db_mode=3 (database only mode).<br>
<br>
But of course, the reverse of the medal with a dedicated db connector<br>
for a module: it adds overhead to code maintenance (besides generic<br>
updates due to external library changes, I expect changing something<br>
relevant in usrloc, like adding new columns, would require updates in<br>
this module as well).<br>
<br>
So, there are few things I want feedback on:<br>
<br>
1) how do you fill about splitting from a generic-only DB connectors to<br>
have also some dedicated ones? This is more from confusion point of<br>
view, as a general rule so far, we do not deny contributions if there<br>
are other options for same kind of feature (e.g., many lcr or nat<br>
traversal options). As long as the contributor is willing to maintain<br>
the code, we were fine.<br></blockquote><div><br><br><span style="color:rgb(0,0,255)">Generic is adding a lot of value in reusability but dedicated ones may also be needed, especialy with NoSQL.<br><br>Even with SQL DB abstraction we are sometimes facing limitations.<br>Since the db abstraction is generic it may prevent the use of some back-end specific features, even with real SQL back-end when something is <b>statement specific</b>, one example :<br>when adding the postgres upsert last year, introduced in Postgres 9.5 the postgres team decided that the conflict/constraints must be specified explicitely in the statement, in this case I decided to do automatic constraint detections so that db_postgres could automaticaly always do upsert when insert_update is used, this was working fine with  mysql because insert for update is generic.<br><br>In such case may still have several options like extendeding the DB abstraction or bypassing it by presseting specific values/decisions in the db_x module (per connection, table, statement type) but if it is per statement I beleive the only option is to extend the db abstraction.<br></span><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2) I guess usrloc, presence and dialog modules would be the main<br>
suspects that would benefit for such dedicated connectors, in other<br>
cases might not worth adding dedicated connectors. Missing any other<br>
module one would like to squeeze more performances with a dedicated<br>
connector?<br></blockquote><div><br><span style="color:rgb(0,0,255)"> I agree, dedicated ones may be valuable, Kamailio is able to do many things but it seems valuable to also be specialised in doing some tasks extremely well.<br><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
3) should we set a different naming policy for such modules, for<br>
example: use *dbs_* prefix instead *db_*, to suggest better it is a<br>
DataBase Specific connector?<br>
<br>
4) Andreas said he plans to do some performance testing of usrloc module<br>
with the two modules and see the differences. Anyone else that wants to<br>
do it? It can be a good metric to see if it worth going one way or another?<br>
<br>
5) Helping to review the pull request, specially if you use Redis, is<br>
appreciated. Personally I am very short in available time these days,<br>
next week I plan do to new Kamailio stable releases, so the schedule is<br>
not getting lighter in my side.<br>
<br>
Cheers,<br>
Daniel<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
Daniel-Constantin Mierla<br>
<a href="http://www.twitter.com/miconda" rel="noreferrer" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer" target="_blank">www.linkedin.com/in/miconda</a><br>
Kamailio Advanced Training - March 5-7, 2018, Berlin - <a href="http://www.asipto.com" rel="noreferrer" target="_blank">www.asipto.com</a><br>
Kamailio World Conference - May 14-16, 2018 - <a href="http://www.kamailioworld.com" rel="noreferrer" target="_blank">www.kamailioworld.com</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><br>
</font></span></blockquote></div><br></div></div></div></div>