Actually, I think you'll find that it's easier to manage and plan for database usage than it is to recover from unexpected database load. It really doesn't matter what database you're using; even the most heavy-duty mainframe will underperform if you get unexpected traffic.
On Wednesday 05 March 2003 10:29, Chris Albertson wrote: > Would it just be easier to use a database system that managed > concurent access better? Most all of them don't have trouble > with this and don't require work-arounds like hot copies and > so on. > > --- [EMAIL PROTECTED] wrote: > > I am always wary of allowing ad-hoc queries that may lock > > tables on a production system. One > > relatively easy way to avoid this issue is to use hotcopy to > > make a read-only reporting database > > that gets updated every x minutes. The other is to use > > replication if you need an up to the second > > copy. > > > > Bill > > > > Chris Albertson wrote: > > > I tested both MySQL and PostgreSQL under various loads, > > > Actually got paid to do it. In the simple case where one > > > process just stuffs data into the database with INSERT > > > MySQL was about 4x faster in terms of INSERT/second > > > > > > However if you have five or six processes that are doing > > > lots of transactions, mixed INSERT and SELECT, MySQL > > > grinds to a halt The trouble is locking. MySQL only lets > > > one process at a table at > > > > a > > > > > time so everyone else is shut out waiting. > > > > > > On a large PBX with high call volume you can't afford to > > > have a table locked for 10 or 30 seconds while some guy > > > does an ad-hoc join. > > > > > > PostgreSQL is more stable but can "only" do a few hundred > > > INSERT per second on PC hardware vs. well over 1000/sec > > > for MySQL. > > > _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
