I can't speak for Oracle, but MySQL's replication strategy is very robust, but not without limitations.
With MySQL replication one DB serves as the master and others as children. Updates, inserts, and deletes should only be done on the Master (which pushes the changes down to the children), but selects can be done on any of the DBs. This works well because for many tasks because in many instances DB access is much more read-oriented than write-oriented.
You can even do something similar with the DBD::Multiplex. It allows you to have a single database handle (from your program's point of view) that connects to multiple DB's on the back end. It'll use any of the DB's when doing a select, but any updates/inserts/deletes will be performed on all teh DB's.
| [reply] |
MySQL and Postgres both have "replication" facilities,
which probably do what you want to do, only they've been
written and tested already, and are supported in a
commercial capacity should you require it.
Further, if you're using BerkleyDB, you could very easily
switch to an RDBMS by tying your data to SQL instead of
a flat file. Your program will hardly notice the difference.
There are several examples of this sort of thing floating
around, one of which is in the MySQL and mSQL
book from O'Reilly.
You won't be able to use any of the fancy SQL features
without rewriting parts, of course, but at least this
is optional.
| [reply] |
Im quite happy with RDBMS as a solution, and in fact have hardly ever worked with BerkeleyDB, but the current application has:
- Simple data i.e. key / value
- Requirement for fast access
- Ratio of about 8 reads to 1 update / insert
That's why i was veering towards DB files,
But thats an interesting point about the conversion from DB...
| [reply] |
