Thanks for your feedback. I gonna keep my data in my main RDBMS instead (which supports full-text searching as well). If it's too slow, i still have to option of setting up a database cluster or something.
On Apr 15, 1:41 pm, Simon Slavin <slav...@bigfraud.org> wrote: > 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-us...@sqlite.orghttp://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
