Re^4: OT: Scalable web application architecture

Aren't there applications that simultaniously reading and writing to a table? How about applications in banks or airline reservation system works? What's the difference between their application and my application? What makes them tick?

Anyway, I agree with your idea of separating dynamic and static data. Thanks for your suggestion.

badaiaqrandista

Comment on Re^4: OT: Scalable web application architecture

Replies are listed 'Best First'.
Re^5: OT: Scalable web application architecture by pajout (Curate) on Dec 08, 2005 at 10:05 UTC
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]
Re^5: OT: Scalable web application architecture by dokkeldepper (Friar) on Dec 15, 2005 at 11:52 UTC
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]