On Mon, 2006-05-01 at 12:08, Philip Hallstrom wrote: > > On Sun, 2006-04-30 at 14:32, Tony Lausin wrote: > >>> [ rotfl... ] MySQL will fall over under any heavy concurrent-write > >>> scenario. It's conceivable that PG won't do what you need either, > >>> but if not I'm afraid you're going to be forced into Oracle or one > >>> of the other serious-money DBs. > >>> > >>> regards, tom lane > >> > >> Hi Tom, > >> > >> That's a scary idea - being forced into Oracle or Sybase. Isn't > >> Slashdot.org still running strongly off of MySQL? > > > > Depends on how you define strongly. Slashdot has a LOT of code in place > > to cache the content so it never has to hit the database directly. > > Basically, every X seconds, the data creating the site is ripped outta > > the database and produced as static content so that the writes and reads > > don't clobber each other. And it still takes a pretty big and fast > > machine to handle the load. > > I think slashdot uses memcache... > > http://www.danga.com/memcached/users.bml I was under the impression that they also created a lot of static text for pages that are older than x number minutes or days, with updates to those pages becoming further apart as the page for older. > I would also read this about mysql's table locking: > > http://dev.mysql.com/doc/refman/4.1/en/table-locking.html > > Specifically, regarding myisam tables: > > "Table locking enables many threads to read from a table at the same time, > but if a thread wants to write to a table, it must first get exclusive > access. During the update, all other threads that want to access this > particular table must wait until the update is done." > > It doesn't take very many writes before this *really* becomes a problem. > We're implementing memcache at work to help with this issue... Yeah, table level locking doesn't really scale well.
