Subject | architecture advice needed |
---|---|
Author | Thekla Damaschke |
Post date | 2006-03-28T06:16:22Z |
Hello,
I need some advice about which firebird to use and how to set it up.
The following is what I want to achieve:
There is a couple of main databases that are accessed the "normal" way on a
database server (oracle), but then we have "scenarios" of this, which are
copies or extracts of a main database used for heavy evaluations.
To do a scenario does involve creating several copies or extracts of a
main database,
and for each of them start an evaluation job on some machine in the
network. An evaluation job will
consist of several processes that interact and work against the same
database
(all of them running on a single machine).
After a while, some of the evaluations will have achieved
some results and write a report to file/web which a human user will
compare and decide
which of the results he wants to put into the main database (if any).
All the scenario databases are thrown away after this.
We had first an implementation using oracle, but this was not scalable
enough,
oracle has obviously problems when you create and drop users amass all
the time :-)
I thought that firebird might be a good solution, since each scenario
would just be a file,
we could distribute them on the net and then run each evaluation in
complete isolation.
I really like that firebird support so broad SQL syntax compared to other
filebased or embedded databases that I looked at.
I have implemented the access layer against firebird (using embedded as
starting point)
and it was really smooth. Great !
But now, to set it live, I need some help on the alternatives:
If I got it right, superserver needs something running continuously
on each machine I want a distributed database to end up on,
while classic server should be integrated with inetd and will start up
on request
(one process per database connection).
Both of them should cope with new databases turning up on the fly
and shouldn't care if a database vanishes once it is not longer
accessed, right ?
What is this about local connections,
what is the actual difference to connections to localhost?
In which environment are they supported and what need to be running
already on the box?
I got a bit confused by the different statements in the documentation.
From the Whitepaper that is linked from firebird website, I get:
"*Local Access Method *
The Classic architecture permits application processes to perform I/O on
database files directly, whereas the SuperServer architecture requires
applications to request the *ibserver* I/O operations by proxy, using a
network method. The local access method is faster than the network
access method, but is only usable by applications which run on the same
host as the database."
while in the support mailinglist, Adam writes:
box ?
Optimally I would like to have an NFS mounted (or tarball) installation
of firebird
and no local preparation. I could run some script to set up something
for each
scenario (or the first one) that I copy on the box, but that should not
require root access!
Any advice is appriciated.
Thekla Damaschke
I need some advice about which firebird to use and how to set it up.
The following is what I want to achieve:
There is a couple of main databases that are accessed the "normal" way on a
database server (oracle), but then we have "scenarios" of this, which are
copies or extracts of a main database used for heavy evaluations.
To do a scenario does involve creating several copies or extracts of a
main database,
and for each of them start an evaluation job on some machine in the
network. An evaluation job will
consist of several processes that interact and work against the same
database
(all of them running on a single machine).
After a while, some of the evaluations will have achieved
some results and write a report to file/web which a human user will
compare and decide
which of the results he wants to put into the main database (if any).
All the scenario databases are thrown away after this.
We had first an implementation using oracle, but this was not scalable
enough,
oracle has obviously problems when you create and drop users amass all
the time :-)
I thought that firebird might be a good solution, since each scenario
would just be a file,
we could distribute them on the net and then run each evaluation in
complete isolation.
I really like that firebird support so broad SQL syntax compared to other
filebased or embedded databases that I looked at.
I have implemented the access layer against firebird (using embedded as
starting point)
and it was really smooth. Great !
But now, to set it live, I need some help on the alternatives:
If I got it right, superserver needs something running continuously
on each machine I want a distributed database to end up on,
while classic server should be integrated with inetd and will start up
on request
(one process per database connection).
Both of them should cope with new databases turning up on the fly
and shouldn't care if a database vanishes once it is not longer
accessed, right ?
What is this about local connections,
what is the actual difference to connections to localhost?
In which environment are they supported and what need to be running
already on the box?
I got a bit confused by the different statements in the documentation.
From the Whitepaper that is linked from firebird website, I get:
"*Local Access Method *
The Classic architecture permits application processes to perform I/O on
database files directly, whereas the SuperServer architecture requires
applications to request the *ibserver* I/O operations by proxy, using a
network method. The local access method is faster than the network
access method, but is only usable by applications which run on the same
host as the database."
while in the support mailinglist, Adam writes:
>* Classic ServerWhat architecture requires least effort and rights to set it up on a new
>
>There is no local connection support. Use TCP loopback to localhost to
>resolve.
>
>
box ?
Optimally I would like to have an NFS mounted (or tarball) installation
of firebird
and no local preparation. I could run some script to set up something
for each
scenario (or the first one) that I copy on the box, but that should not
require root access!
Any advice is appriciated.
Thekla Damaschke