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.
