Re: Is PostgreSQL an easy choice for a large CMS?
От | Philip Hallstrom |
---|---|
Тема | Re: Is PostgreSQL an easy choice for a large CMS? |
Дата | |
Msg-id | 20060501133617.G15162@bravo.pjkh.com обсуждение исходный текст |
Ответ на | Re: Is PostgreSQL an easy choice for a large CMS? (Scott Marlowe <smarlowe@g2switchworks.com>) |
Ответы |
Re: Is PostgreSQL an easy choice for a large CMS?
|
Список | pgsql-general |
>>>> 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.
В списке pgsql-general по дате отправления: