>>>> 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.
They very well could. I don't know anything beyond what that page says...
>> 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.
Which is ironic since the top of that page says: "For large tables, table
locking is much better than row locking for most applications..."
Which, just right off the bat, doesn't make much sense... oh well.