Em 24/08/2018 15:18, David Gauthier escreveu:
Hi Everyone:
I'm going to throw this internal customer request out for ideas, even
though I think it's a bit crazy. I'm on the brink of telling him it's
impractical and/or inadvisable. But maybe someone has a solution.
He's writing a script/program that runs on a workstation and needs to
write data to a DB. This process also sends work to a batch system on
a server farm external to the workstation that will create multiple,
parallel jobs/processes that also have to write to the DB as well. The
workstation may have many of these jobs running at the same time. And
there are 58 workstation which all have/use locally mounted disks for
this work.
At first blush, this is easy. Just create a DB on a server and have
all those clients work with it. But he's also adamant about having
the DB on the same server(s) that ran the script AND on the locally
mounted disk. He said he doesn't want the overhead, dependencies and
worries of anything like an external DB with a DBA, etc... . He also
wants this to be fast.
My first thought was SQLite. Apparently, they now have some sort of
multiple, concurrent write ability. But there's no way those batch
jobs on remote machines are going to be able to get at the locally
mounted disk on the workstation. So I dismissed that idea. Then I
thought about having 58 PG installs, one per workstation, each serving
all the jobs pertaining to that workstation. That could work. But 58
DB instances ? If he didn't like the ideal of one DBA, 58 can't be
good. Still, the DB would be on the workstation which seems to be
what he wants.
I can't think of anything better. Does anyone have any ideas?
Thanks in Advance !
I'm no expert, but I've dozens of PostgreSQL databases running mostly
without manual maintenance for years, just do the backups, and you are fine.
In any way, if you need any kind of maintenance, you can program it in
your app (even backup, restore and vacuum) - it is easy to throw
administrative commands thru the available interfaces.
And if the database get out of access, no matter if it is centralized or
remote: you will need someone phisically there to fix it.
AFAIK, you don't even PostgreSQL installer - you can run it embed if you
wish.
Just my2c,
Edson
