If you're already willing to use a ram drive, you should benchmark SQLite against a disk-backed file, with 'PRAGMA synchronous = off;'. For most modern operating systems, this shouldn't provide significantly different performance than using a RAM disk.
Note that you said 'Data persistence is not required.' My suggestion would be to treat such a database as described above exactly as you'd treat a database on a RAM disk. With synchronous off, the OS is free to reorder things pretty arbitrarily, and data may not be written out for a surprisingly long period, and it may not be written in any internally-consistent order. -scott On 8/21/07, Lee Crain <[EMAIL PROTECTED]> wrote: > Rich, > > We're going to delete and rewrite ~109,369 records in 5 tables every week. > > > Hard drives are a minimum of 10,000 times slower than RAM. I'll let you > know if this process is not a lot faster than writing the records, > individually, to a hard drive. > > Lee Crain > > _________________________________________________ > > > -----Original Message----- > From: Rich Shepard [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 21, 2007 11:15 AM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] A Question About Creating and Accessing a SQLite > Database in a RAM Drive > > On Tue, 21 Aug 2007, Lee Crain wrote: > > > The approach I planned was a little different than what you proposed. > > That's fine, Lee. > > > This technique for performing database updates offline and then updating > > the original database via a file copy operation has worked very well on > > hard drives. I am only considering using the RAM drive to improve the > > speed of the database updates. > > This was common in the early 1980s when drives and other hardware were > slow. I've not seen a situation any time recently when this was necessary > with modern hardware and fast memory. When I was capturing real-time data > (lat/lon from the GPS receiver and depth from the sonar), I'd write both > to > memory buffers, then write to disk on a regular basis. This let me use > slower hardware (compared to the data flow) while writing to disk in > chunks > and ensuring that no data were lost. > > I'm confident that you can tune your database for speed in other ways, > but > -- of course -- it's your choice. > > Good luck with it, > > Rich > > -- > Richard B. Shepard, Ph.D. | The Environmental Permitting > Applied Ecosystem Services, Inc. | Accelerator(TM) > <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: > 503-667-8863 > > -------------------------------------------------------------------------- > --- > To unsubscribe, send email to [EMAIL PROTECTED] > -------------------------------------------------------------------------- > --- > > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > ----------------------------------------------------------------------------- > > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
