23 Jun
2009
23 Jun
'09
2:41 p.m.
Добрый день, Raúl.
On Tuesday 23 June 2009 10:53:07 Konstantin Cherkasov
wrote:
> Hello, Raúl!
>
> >> It would provide access to database (internal database API) not
> >> management API. I want alias_db, auth_db, domain, group, usrloc etc. to
> >> work directly with HTTP/REST layer.
> >
> > This is a very, very, very, very, very bad idea from performance point of
> > view
>
> Do you realy think that LDAP or ODBC layers is better than HTTP?
Yes, are better, because are protocols with direct
access/map to data, HTTP
it's a transport protocol, and you are requesting to use REST on top, so ...
Kamailio <-> REST client <-> XML <->
HTTP <-> XML <-> REST server <-> DB
Kamailio is a "REST
client" and REST is not requires XML.
I think it will be like this:
Kamailio <-> (TXT/CSV) <-> HTTP <-> REST server <-> ANY EXTERNAL
DB
So, which part is _realy_ slow in this setup?
HTTP-server can be very fast. HTTP-server can be load-balanced and distributed.
REST layer can be fast and use something like memcached for caching and call distributed
database.
I think the database is the real bottleneck in any setup.
Can Kamailio connect to several databases? No.
So, we use distributed database cluster (postgres + pl/proxy) and solve this bottleneck in
our
applications.
Now I have headache and have to replicate data from fast distributed cluster to plain
tables and
FROM(!!!) plain tables to cluster.
instead of:
Kamailio <-> LDAP <-> DB
or
Kamailio <-> ODBC <-> DB
Yes, but what if I don't have plain DB?
OK, do you ever hear about AUTH_RADIUS ? :-)
I just don't want make another stupid auth_SOME, alias_SOME and so on.
I think it's better to make db_SOME and use database abstraction layer instead.
Yes, I realize performance challenges. Yes, we must pay for any abstraction.
--
Konstantin Cherkasov