Tue, Sep 07, 2004 at 12:59:37PM +0100: Christian Smith wrote: > On Tue, 7 Sep 2004, Guillaume Fougnies wrote: > > >Mon, Sep 06, 2004 at 11:56:21PM -0700: Darren Duncan wrote: > >> > >> What you probably saw with the 3ms is the time between when you > >> issued the insert command and when control was returned to your app, > >> but the new record was simply in RAM and not on disk. The operating > >> system would have written it to the disk some time later. So in > >> other words, the time is so much faster because the slower action > >> actually did something but the faster action did nothing during the > >> time. The main risk is that your app is thinking the data is saved > >> at a certain point in time, but it actually isn't. -- Darren Duncan > > > >Using synchronous=OFF is a design choice, not a risk. > >For non-mission critical databases, you can easily have a "good" > >data reliability after a crash using a journaling FS and incremental > >backups. > > So long as data is slow changing. I wouldn't like to trust my data to > software with that attitude. > > And what's a few milliseconds between friends if it results in more > reliable data. If changes are that frequent that performance is vital, > then batching updates makes sense. If updates are so infrequent as to make > batching unfeasible, then single insert performance should not be a > problem in the grand scheme of things.
Difference between 5ms and 100ms is not a few milliseconds on heavily loaded systems. I'm currently using this kind of approach in a grid computing software; Data is replicated synchronously among 6 servers. If one fails, data is surely consistent on others. Batch update is not the right choice in a threaded or over multi proc environment if one process needs to read some data. This results of completely async storage... This is not the case if you use the synchronous=OFF. The kernel (like linux) manages like an expert the fs cache and sync... After all, that's its job. Proning synchronous off is stupid... in most cases, the default 'full' is smartest; it's always a question of design. -- Guillaume FOUGNIES
