Is it possible to use mysql for HLR. I can see some notes within the source.
Rgds Nik
Nik Pakar wrote:
Is it possible to use mysql for HLR. I can see some notes within the source.
The database access uses libdbi, which means that MySQL or MariaDB may actually already be supported. The code however doesn't support specifying which database to use, so you will have to make some trivial changes to libmsc/db.c.
I'm also interested in this topic, so if you try it out please share results.
//Peter
On Fri, Mar 02, 2012 at 01:43:44AM +0100, Holger Hans Peter Freyther wrote:
On 03/02/2012 01:33 AM, Peter Stuge wrote:
Nik Pakar wrote:
I'm also interested in this topic, so if you try it out please share results.
another topic is to make looking up a subscriber async and writing... just write through.
this is the much more important topic. Without that change, it is completely useless to switch to another database. In fact, it may make things worse due to higher latency caused by inter-process communication between DB client (openbsc) and DB server.
This tight integration of a db back end will have lot more limitation when it comes to scalable deployment. i.e. 100s of BTS connecting to more than one BSCs which will need a common database backend as the the HLR. We might not need BSCs to talk to HLR in proper MAP interface, but atleast they can do talk directly to HLR DB using db driver for now.
Is there anyway we can get into mysql integration. I will give it a try if some one can put bit more light on that way.
Rgds Nik
On Sat, Mar 3, 2012 at 10:47 AM, Harald Welte laforge@gnumonks.org wrote:
On Fri, Mar 02, 2012 at 01:43:44AM +0100, Holger Hans Peter Freyther wrote:
On 03/02/2012 01:33 AM, Peter Stuge wrote:
Nik Pakar wrote:
I'm also interested in this topic, so if you try it out please share results.
another topic is to make looking up a subscriber async and writing...
just
write through.
this is the much more important topic. Without that change, it is completely useless to switch to another database. In fact, it may make things worse due to higher latency caused by inter-process communication between DB client (openbsc) and DB server.
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 03/03/2012 01:52 PM, Nik Pakar wrote:
Is there anyway we can get into mysql integration. I will give it a try if some one can put bit more light on that way.
Hi,
it is as easy as writing the code, or find someone to write the code for you. We will be happy to integrate the code if it matches the quality criteria and is split up in a way one can review the contribution.
h.
Nik,
On Sat, Mar 03, 2012 at 12:52:25PM +0000, Nik Pakar wrote:
This tight integration of a db back end will have lot more limitation when it comes to scalable deployment. i.e. 100s of BTS connecting to more than one BSCs which will need a common database backend as the the HLR.
I have made it _very_ clear that the bottleneck is not the sqlite3 integration. Trust me, the problem is an architectural problem with the lack of asynchronous processing of subscriber lookups. You are looking at a symptom, not the cause.
The people involved in OpenBSC have a very good understanding of what needs to be done. It is a volunteer project driven by poeple who want to contribute. If you want a scalable database backend, I suggest you contribute code to first make the subscriber lookups asynchronous, and then generalize it away from sqlite3.
Regards, Harald
Harald Welte wrote:
If you want a scalable database backend, I suggest you contribute code to first make the subscriber lookups asynchronous, and then generalize it away from sqlite3.
I think it's fine to do it the other way around as well, and may be an easier entry to the codebase. Better database abstraction is desirable also on it's own, even if it isn't sufficient to make a leap in scalability.
//Peter
Hi Nik,
On Fri, Mar 02, 2012 at 12:22:45AM +0000, Nik Pakar wrote:
Is it possible to use mysql for HLR. I can see some notes within the source.
some thoughts:
AFAIR there was a patch on the ML quite a long time ago that added mysql support. I have no idea if it worked or still applies or anything.
Are you sure you want to use mysql and not something like postgres?
I remember that somebody stumbled over a weirdness in the way the data is actually stored in the DB (sqlite), which was caused by the DBI layer.
Maybe you want to have a look at the ML archive.
Kind regards, -Alexander Huemer
On 2012/3/2, at 下午4:50, Alexander Huemer wrote:
I remember that somebody stumbled over a weirdness in the way the data is actually stored in the DB (sqlite), which was caused by the DBI layer.
That would be me. To recap: libdbi (c lib) store binary value in its own way.
It escapes the value to make it fit in a SQL string, instead of sqlite3_bind_blob function to store the actual raw value. It bugged me because I was trying to read the db from a perl program. I ended up porting the escaping/unescaping subroutine to perl in order to read/write the SMS table.
Sincerely, Kang-min Liu
Kang-min Liu wrote:
To recap: libdbi (c lib) store binary value in its own way.
Ahh. Thanks for this hint.
It escapes the value to make it fit in a SQL string, instead of sqlite3_bind_blob function to store the actual raw value. It bugged me because I was trying to read the db from a perl program. I ended up porting the escaping/unescaping subroutine to perl in order to read/write the SMS table.
We'll have to change this to a more powerful solution soon. (Maybe both some database bits but in particular SMSes.)
Kind regards
//Peter
-
Alexander Huemer -
Harald Welte -
Holger Hans Peter Freyther -
Kang-min Liu -
Nik Pakar -
Peter Stuge