> > Beware: once you read thru the MySQL code you'll never want to use MySQL > again ;) The apparent robustness of MySQL has little to do with the quality > of the code and everything to do with the millions of people banging on it > every day.
> particular scenario. YMMV. Also, I'm not familiar with prepared statements > in MySQL. They're new, and based on the quality of the MySQL code I wouldn't > imagine they bring has much benefit as on, say, Oracle. I highly doubt MySQL > does speculative read-aheads, etc, based on prepared statements. Parsing > cost is negligble anyhow, and there wouldn't be much latency to gain back by > using prepared statements because you still need the back-and-forth during > execution. You know, I kind of doubted whether to use MySQL or not for my project. I was a MySQL fan for about 10 years, never thinking about why I picked it. Now that I have to implement a scalable and optimized for speed web application, after reading your comments, I understand that there is no reason to use SQL for a specialized website at all. And more after discovering that mysql's prepared statements won't give me any benefit .... I have searched quickly what database engine supports asynchronous io and found quite a lot of good projects, one of them called Redis, it is a sort of replacement for memcachedb. Nice stuff! Check it out: http://redis.io/ I think I am going to discard MySQL and go for using Berkeley DB, I can design specialized data fetches (sort if implementing my own database server optimized for my app) completely in-memory with occasional replication to disk. Like Redis. Even though Berkeley DB still doesn't support non-blocking read/write it makes sense to spend some time on writing thread functions for it than coding the same on top of SQL, would it be MySQL, PostgreSQL or whatever. I didn't test it yet, but seems like I could get about 2x to 3x speed up this way on all data fetches. Regards -- ================================== The power of zero is infinite *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
