On 15 Apr 2010, at 8:21am, Jens wrote: > I'd appreciate any feedback you might have one this. Also, does anyone > have experience with sqlite+ft3 and high-availability solutions? Has > anyone done any benchmarking of fts3?
For a start, FTS3 is a very specific solution to a very specific problem. Your search may be perfectly acceptable using LIKE or GLOB, which lead to far simpler searches and far better optimization. Do your own benchmarking for each solution. Second, if you have more than one heavy user of a database system like this, and especially if the databases have to be updated at the same time as they're being searched, SQLite is probably not a good solution for you. I would probably recommend MySQL, or whatever other database engine your favourite web-facing programming language makes easy for you. There are a few reasons for this. Under SQLite, each connection to the database is one process with one memory allocation and one set of caching. If you have 20 independent HTTPd threads trying to access the data at once, that's 20 chunks of memory, and 20 /independent/ caches, and a file locking/semaphor system to coordinate them all. If instead you use a multi-user persistent database engine like MySQL, you run one process which handles the database files, and maintains its own caching system the whole time it's running. Since it knows what the common types of enquiry are (because all enquiries pass through the same service) it can use the cache from one query for another query. It takes up only one chunk of memory and because only one process actually manipulates the files on disk it can handle locking and simultaneous access internally rather than having to use file locking. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
