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
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
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
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
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
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
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
-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
Alexander Staubo wrote:
> On 5/23/07, PFC <[EMAIL PROTECTED]> wrote:
>> +---+---+--+-+
>> | Table | Op| Msg_type | Msg_text|
>> +---+---+--+-+
>> | for
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
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
On 5/23/07, PFC <[EMAIL PROTECTED]> wrote:
+---+---+--+-+
| Table | Op| Msg_type | Msg_text|
+---+---+--+-+
| forum_bench.posts | check | warning |
-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
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
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
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.
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
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
> "*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
"*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
- 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
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
-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
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
"*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/
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, say, optimistic loc
26 matches
Mail list logo