Re: [GENERAL] Integrity on large sites

2007-05-30 Thread Ron Mayer
Tom Lane wrote: > Dave Page <[EMAIL PROTECTED]> writes: >> I can't imagine Flickr or Slashdot ... > > I'm pretty sure I remember reading that Slashdot had to put enormous > amounts of cacheing in front of their DB to keep it from falling over > on a regular basis. Yes, slashdot and flickr both us

Re: [GENERAL] Integrity on large sites

2007-05-28 Thread Lew
PFC wrote: "*Really* big sites don't ever have referential integrity. Or if the few spots they do (like with financial transactions) it's implemented on the application level (via, say, optimistic locking), never the database level." Sure, but in the forum benchmark I just did, when using

Re: [GENERAL] Integrity on large sites

2007-05-24 Thread Alexander Staubo
On 5/24/07, PFC <[EMAIL PROTECTED]> wrote: Flickr uses InnoDB, by the way. The master does. The slaves use MyISAM, according to Cal Henderson: http://www.slideshare.net/coolpics/flickr-44054 Alexander. ---(end of broadcast)--- TIP 6: e

Re: [GENERAL] Integrity on large sites

2007-05-24 Thread Dave Page
Joshua D. Drake wrote: > Dave Page wrote: > >>> problem with your setup. Granted, MySQL is a pretty bad database, but >>> it's not *that* bad -- your example implies that heavily MyISAM-based >>> (you don't say whether this is MyISAM or InnoDB) sites such as >>> Slashdot and Flickr should be falli

Re: [GENERAL] Integrity on large sites

2007-05-24 Thread PFC
Flickr uses InnoDB, by the way. On Thu, 24 May 2007 18:07:21 +0200, Joshua D. Drake <[EMAIL PROTECTED]> wrote: Dave Page wrote: problem with your setup. Granted, MySQL is a pretty bad database, but it's not *that* bad -- your example implies that heavily MyISAM-based (you don't

Re: [GENERAL] Integrity on large sites

2007-05-24 Thread Joshua D. Drake
Dave Page wrote: problem with your setup. Granted, MySQL is a pretty bad database, but it's not *that* bad -- your example implies that heavily MyISAM-based (you don't say whether this is MyISAM or InnoDB) sites such as Slashdot and Flickr should be falling over every hour. I'm not going to co

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Tom Lane
Dave Page <[EMAIL PROTECTED]> writes: > I'm not going to comment on who's fault it is, but the OP quoted 100 > updates and 600 selects per *second*. I can't imagine Flickr or Slashdot > (which is heavily csched for reading) are under anything like that sort > of constant load. I'm pretty sure I re

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Ron Johnson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/07 20:29, Tom Allison wrote: [snip] > Bottom line, if the DBA or anyone says we can't support RI or UNIQUE > because of the performance overhead... I would be inclined to look for > another DBA. > But I have to admit. I am extremely opiniona

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Dave Page
Alexander Staubo wrote: > On 5/23/07, PFC <[EMAIL PROTECTED]> wrote: >> +---+---+--+-+ >> | Table | Op| Msg_type | Msg_text| >> +---+---+--+-+ >> | for

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Tom Allison
On May 23, 2007, at 12:54 PM, Scott Ribe wrote: "*Really* big sites don't ever have referential integrity. Or if the few spots they do (like with financial transactions) it's implemented on the application level (via, say, optimistic locking), never the database level." Pure, utter, unad

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread PFC
What version of that pathetic RDBMS is this? MySQL 5.0.40, on gentoo Linux, Core 2 Duo. The table in question takes about 100 inserts/deletes and 600 selects per second. MyISAM isn't able to finish the benchmark. Actually, I have to run REPAIR TABLE every 20 minutes, since it c

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Alexander Staubo
On 5/23/07, PFC <[EMAIL PROTECTED]> wrote: +---+---+--+-+ | Table | Op| Msg_type | Msg_text| +---+---+--+-+ | forum_bench.posts | check | warning |

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Ron Johnson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/07 12:48, PFC wrote: > >> Some big sites do of course juggle performance vs in-database run-time >> checks, but the statements as typically presented by MySQL partisans, > > Live from the front : > > This freshly created database ha

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Andrew Sullivan
On Wed, May 23, 2007 at 12:12:52PM +1000, Naz Gassiep wrote: > give me nightmares. Is it really true that large sites turn RI off to > improve performance, You can't "turn it off", but you can "not use it". And I suppose there are shops where they don't use it; after all, you can make any comput

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Richard P. Welty
Scott Marlowe wrote: 2: Handling RI in the application doesn't scale. If everything you do requires you to check in the app, lock the whole table to prevent race conditions, and then commit, you'll never scale to any real number of users. You can have reliability and performance if you do RI

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread PFC
Some big sites do of course juggle performance vs in-database run-time checks, but the statements as typically presented by MySQL partisans, Live from the front : This freshly created database has had to endure a multithreaded query assault for about 2 hours. It gave up.

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Alexander Staubo
On 5/23/07, Naz Gassiep <[EMAIL PROTECTED]> wrote: "*Really* big sites don't ever have referential integrity. Or if the few spots they do (like with financial transactions) it's implemented on the application level (via, say, optimistic locking), never the database level." It's not just the big

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Scott Marlowe
Naz Gassiep wrote: I'm working in a project at the moment that is using MySQL, and people keep making assertions like this one: "*Really* big sites don't ever have referential integrity. Or if the few spots they do (like with financial transactions) it's implemented on the application level (via

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread Scott Ribe
> "*Really* big sites don't ever have referential integrity. Or if the few > spots they do (like with financial transactions) it's implemented on the > application level (via, say, optimistic locking), never the database level." Pure, utter, unadulterated bullshit. Speaking as someone who had year

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread PFC
"*Really* big sites don't ever have referential integrity. Or if the few spots they do (like with financial transactions) it's implemented on the application level (via, say, optimistic locking), never the database level." Sure, but in the forum benchmark I just did, when using MyISAM, with

Re: [GENERAL] Integrity on large sites

2007-05-23 Thread btober
- Original Message Follows - From: "Stuart Cooper" <[EMAIL PROTECTED]> >> "*Really* big sites don't ever have referential >> integrity. Or if the few spots they do (like with >> financial transactions) it's implemented on the >application level (via, say, optimistic locking), never the >da

Re: [GENERAL] Integrity on large sites

2007-05-22 Thread Ben
Not using foreign keys makes sense for some applications. WORM applications where you know you are loading accurate data, for example. Or times when it doesn't matter if an application bug corrupts your data. But if you care about your data and if you can't trust your client to edit it co

Re: [GENERAL] Integrity on large sites

2007-05-22 Thread Ron Johnson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/22/07 21:12, Naz Gassiep wrote: > I'm working in a project at the moment that is using MySQL, and people > keep making assertions like this one: > > "*Really* big sites don't ever have referential integrity. Or if the few > spots they do (like w

Re: [GENERAL] Integrity on large sites

2007-05-22 Thread Richard P. Welty
Naz Gassiep wrote: I'm working in a project at the moment that is using MySQL, and people keep making assertions like this one: "*Really* big sites don't ever have referential integrity. Or if the few spots they do (like with financial transactions) it's implemented on the application level (via

Re: [GENERAL] Integrity on large sites

2007-05-22 Thread Stuart Cooper
"*Really* big sites don't ever have referential integrity. Or if the few spots they do (like with financial transactions) it's implemented on the application level (via, say, optimistic locking), never the database level." Some large sites don't even use data types! http://www.thestar.com/News/