Unless I am missing something, it sounds like you might be able to do this with an nfs export shared to each workstation. But I am not sure if I understood what you were describing either.
On Fri, Aug 24, 2018 at 2:22 PM Edson Carlos Ericksson Richter < rich...@simkorp.com.br> wrote: > Em 24/08/2018 16:07, David Gauthier escreveu: > > I tried to convince him of the wisdom of one central DB. I'll try again. > > > > >>So are the 58 database(stores) on the workstation going to be working > > with data independent to each or is the data shared/synced between > > instances? > > > > No, 58 workstations, each with its own DB. There's a concept of a > > "workarea" (really a dir with a lot of stuff in it) where the script > > runs. He wants to tie all the runs for any one workarea together and > > is stuck on the idea that there should be a separate DB per workarea. > > I told him you could just stick all the data in the same table just > > with a "workarea" column to distinguish between the workareas. He > > likes the idea of a separate DB per workarea. He just doesn't gt it. > > > > >>I'm no expert, but I've dozens of PostgreSQL databases running mostly > > without manual maintenance for years. > > > > Ya, I've sort of had the same experience with PG DBs. Like the > > everready bunny, they just keep on running. But these workstations > > are pretty volatile as they keep overloading them and crash them. Of > > course any DB running would die too and have to be > > restarted/recovered. So the place for the DB is really elsewhere, on > > an external server that wouldn't be subject to this volatility and > > crashing. I told him about transactions and how you could prevent > > partial writing of data sets. > > > > So far, I'm not hearing of anything that looks like a solution given > > the constraints he's put on this. Don't get me wrong, he's a very > > smart and sharp software engineer. Very smart. But for some reason, > > he doesn't like the client/server DB model which would work so nicely > > here. I'm just trying to make sure I didn't miss some sort of > > solution, PG or not, that would work here. > > > > Thanks for your interest and input everyone ! > > > > > > > > > > On Fri, Aug 24, 2018 at 2:39 PM Edson Carlos Ericksson Richter > > <rich...@simkorp.com.br <mailto:rich...@simkorp.com.br>> wrote: > > > > 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 > > > > > I think its worth to add, PG or not PG, if the workstation crash, you > will be in trouble with ANY database or file solution you choose - but > with PG you can minimize the risk by fine tunning the flush to disk > (either in PG and in OS). When correctly tuned, it works like a tank, > and is hard to defeat. > > Regards, > > Edson. > > -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.'
