SSD's usually have poor write performance, because to do a write, they have to use read, erase, write sequences across large blocks like 64K. Most of the SSD benchmarks that quote good write performance are for sequential write performance. If you skip all over the disk doing small writes, like a database does, I suspect you'll see pretty bad performance with most SSD's. In most of the SSD benchmarks I've seen, random write performance is worse than rotating media. Actually, most of the SSD benchmarks I've seen completely skip over this point, perhaps not even testing random write performance, but only sequential writes.
Using a separate copy of the database on SSD for queries would probably work well, assuming the database doesn't fit into RAM. If the db does fit in RAM, SSD won't buy you anything. Companies are putting all kinds of smarts into SSD's to try to minimize the effects of the read, erase, write cycle, usually by some form of caching, but then you are also playing with losing the transaction guarantees of a commit. Can't really have it both ways. Jim On 6/11/09, Sam Carleton <scarle...@gmail.com> wrote: > Jim Wilcoxson wrote: >> Here's what I'd try: >> >> 1. Write a small server that accepts connections and writes to the >> SQLite database using prepared statements. If you need require 500 >> transaction per second, it's simply not possible with rotating media. > > I am a late comer to this discussion, so this might have already been > purposed... > > Ever consider having all the updates are done on none rotating media > (SSD) and then having 1 process that reads in blocks of the data and > puts it into it's final home? Purge the SSD SQLite db simply by rolling > to a new one from time to time and delete the old once once all the > connections have moved on to the new SQLite db. > > Sam > -- Software first. Software lasts! _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
