I partially agree, SQL databases are typically used if 1 write event per 10 or more read events happens... I don't want flame...
But I agree with dokkeldepper too. Though I have no real experience with MySQL, the principles are universal: When you need quick search (which is really possible, your search query is simple), you should not write nothing into the db in this transaction, only read. I guess that your caching system is the bottleneck, imho. And I think you should try to realize search query without caching, directly from smartly indexed table(s), and, potentially, tune this query... But I have not any advice, how to establish the indexes on MySQL - I don't know how to realize index scan finding free rooms in MySQL efficiently.
Update: added 'partially' and the second paragraph :) | [reply] |
I would propose that you implement a "per point of sale" perl based cache. The tracking of changes outside this point of sales should be done by triggers on the reservation table by the backend database.
Simultaneity issues should be handled definitely by the backend database, because databases are made to support the ACID requirements. Transactions are your friend. Although these measures come with a performance penalty they insure a consistent system. This is the "conditio sine qua non" (not-without-it-condition) for your kind of application.
| [reply] |
